Attaques médiées par l'utilisateur : quand l'utilisateur devient le canal d'injection

De quoi s’agit-il ?

Les attaques médiées par l’utilisateur sont une classe de compromission d’agent dans laquelle l’adversaire ne touche jamais l’agent. Il manipule plutôt un utilisateur de bonne foi pour qu’il relaie lui-même un contenu contrôlé par l’attaquant dans sa propre requête. L’article qui nomme et mesure ce schéma — Too Helpful to Be Safe: User-Mediated Attacks on Planning and Web-Use Agents, de Chen, Wu, Nguyen et Rudolph (Monash University et Data61 du CSIRO) — a été déposé sur arXiv en janvier 2026 (2601.10758). Il évalue 12 agents commerciaux (6 agents de planification de voyage, 6 agents web) en bac à sable et les trouve « trop serviables pour être sûrs » par défaut.

Le constat clé : la sûreté est présente comme capacité, absente comme priorité. Les agents savaient appliquer des contrôles de sécurité, mais ne le faisaient que lorsque l’utilisateur le demandait explicitement. Sans requête de sécurité, les agents de planification contournaient les contraintes de sûreté dans plus de 92 % des cas, et plusieurs agents web atteignaient un taux de contournement de 100 % sur des actions à risque.

Comment ça marche

L’essentiel de la recherche sur la sécurité des agents suppose un « attaquant dans la boucle » : l’adversaire alimente directement l’agent en entrées malveillantes, ou empoisonne un corpus que l’agent consulte. Les attaques médiées par l’utilisateur inversent ce postulat. L’attaquant ne contrôle que ce que l’utilisateur voit, via un pipeline en quatre étapes :

1. Semer. L’attaquant publie sur une plateforme publique un message persuasif d’apparence anodine (un fil Reddit, une « promotion limitée », un tutoriel). Il porte une charge utile — une URL déguisée, une chaîne de redirection, ou des étapes à suivre.
2. Relayer. Un utilisateur le rencontre en naviguant et le colle ou le cite dans son agent : « réserve ce voyage avec ce code promo », « suis ces étapes ». Le contenu empoisonné franchit la frontière entre le web ouvert et l’entrée de l’agent.
3. Exécuter. L’agent planifie et agit sur le contexte désormais biaisé.
4. Amplifier. La sortie rassurante de l’agent (« cela semble officiel, vous pouvez continuer ») renforce la confiance de l’utilisateur et déclenche l’approbation finale, nuisible.

Le mécanisme est ce que les auteurs appellent l’escalade de la source d’instruction. Les défenses modernes classent les instructions par niveau de confiance : prompt système > entrée utilisateur > contenu externe/sortie du modèle. L’injection indirecte est traitée comme une donnée externe peu fiable. Mais lorsque le contenu arrive via le message de l’utilisateur, la hiérarchie le requalifie en intention utilisateur prioritaire. La même charge utile qu’un filtre se méfierait de traiter comme du texte web est blanchie vers un canal de confiance par l’étape de relais. Aucune charge utile n’est reproduite ici ; la leçon est structurelle, pas une recette.

Les modes de défaillance mesurés sont concrets. La vérification d’URL était superficielle et trop confiante : les agents affirmaient que des domaines de typosquatting, de cybersquatting et d’homographes cyrilliques étaient « officiels » sans validation réelle, et modifier uniquement le préfixe d’une URL contournait les contrôles 88 % du temps, même sous une requête de sécurité modérée. Les agents web ouvraient des liens malveillants sur les schémas http, https, data et javascript, en s’appuyant sur les listes noires du navigateur plutôt que sur un raisonnement propre à l’agent. Ils exécutaient les actions selon la seule progression de la tâche, faisaient défiler du contenu malveillant explicite, remplissaient des champs DOM cachés, et resoumettaient les données lorsqu’un faux message d’« échec » apparaissait — les exfiltrant en silence pendant qu’utilisateur et agent croyaient réessayer.

Pourquoi c’est important

Cela comble une faille que le filtrage d’entrée ne couvre pas. L’hypothèse défensive dominante est que l’attaquant n’a pas accès à l’agent, donc que sécuriser ses entrées suffit. Les attaques médiées par l’utilisateur respectent cette hypothèse et réussissent quand même, parce que l’humain est le vecteur. Le panorama de mars 2026 From Secure Agentic AI to Secure Agentic Web (2603.01564) décrit le même glissement : à mesure que les agents passent d’une surface d’outils contrôlée au web ouvert et peuplé d’humains, la frontière de confiance cesse d’être l’API pour devenir tout ce que l’utilisateur peut être persuadé de relayer.

Cela élève aussi l’enjeu de la serviabilité. Un agent qui conseille une mauvaise réservation laisse une marge de récupération ; un agent web qui clique, soumet et paie produit un dommage immédiat et irréversible. L’étude constate que les agents n’ont pas de « règle d’arrêt à action minimale » — ils continuent d’interagir au-delà de l’objectif réel de l’utilisateur, traitant chaque contrôle disponible comme une commande légitime. Le danger n’est pas un modèle de sûreté manquant ; c’est que la sûreté est optionnelle, conditionnée à la formulation de l’utilisateur.

Défenses

• Faites de la sûreté le comportement par défaut, pas un mode déclenché par le prompt. Les agents devraient effectuer des contrôles de risque sur toute tâche impliquant des ressources externes ou de l’argent, que l’utilisateur le demande ou non. Ne comptez pas sur les utilisateurs pour dire « sois prudent » : les requêtes modérées étaient encore contournées jusqu’à 55 % du temps.
• Traitez le contenu relayé par l’utilisateur comme non fiable, pas comme une intention utilisateur. Messages cités, liens collés et charges utiles « suis ces étapes » devraient conserver le niveau de confiance des données externes même lorsqu’ils arrivent dans le message de l’utilisateur. Résistez à l’escalade de la hiérarchie d’instructions qui les promeut.
• Vérifiez correctement les URL. Appliquez la normalisation Unicode/IDN, vérifiez la provenance et le domaine enregistré complet (pas le préfixe ni une simple similarité de domaine), et n’affirmez jamais « officiel » ou « vérifié » sans contrôle réel. La réassurance trop confiante fait elle-même partie de l’attaque.
• Conditionnez l’exécution à la nécessité. Ajoutez une règle d’arrêt à action minimale : chaque clic, soumission ou téléchargement doit être justifié par la tâche énoncée. Arrêtez-vous à l’accomplissement de la tâche au lieu d’épuiser chaque élément interactif de la page.
• Vérifiez l’état côté serveur, pas seulement les signaux côté client. Confirmez qu’une soumission a réellement réussi avant de réessayer, afin qu’un faux message d’« échec » ne puisse pas déclencher une resoumission silencieuse et une exfiltration.
• Construisez des défenses côté utilisateur. C’est le canal aujourd’hui sans protection. Avertissez les utilisateurs lorsque le contenu qu’ils relaient contient des liens ou des directives, et montrez sur quoi l’agent s’apprête à agir avant qu’il n’agisse.

Statut

Élément	Détail
Source	arXiv 2601.10758 (janvier 2026)
Périmètre	12 agents commerciaux : 6 planification, 6 web
Constat central	La sûreté dépend de la formulation de l’utilisateur, pas d’un défaut
Contournement par défaut	>92 % (planification) ; jusqu’à 100 % (actions à risque, web)
Sous requête de sécurité modérée	Contournement encore jusqu’à ~55 %
Classe	Injection médiée par l’utilisateur / escalade de source d’instruction
Divulgation	Étude académique ; comportements mesurés en bac à sable, sans dommage réel

Le cadrage durable est que la hiérarchie d’instructions peut être retournée contre elle-même. Placer l’utilisateur au-dessus des données externes est le bon choix pour un usage normal — mais cela signifie qu’un attaquant qui atteint l’utilisateur, plutôt que l’agent, hérite du niveau de confiance de l’utilisateur. Tant que les contrôles de sécurité restent quelque chose que l’utilisateur doit demander, l’agent le plus poli et le plus serviable est aussi le plus exploitable.