Injection par le canal d'erreur : quand les messages d'erreur des outils font autorité

De quoi s’agit-il ?

En juin 2026, le papier VATS: Exploiting Implicit Authority in Error-Path Injection via Systematic Mutation (arXiv:2606.07992) a décrit un angle mort de la sécurité des agents : la boucle de gestion des erreurs des agents à outils. À mesure que le Model Context Protocol (MCP) standardise la façon dont les agents autonomes appellent leurs outils, il standardise aussi la façon dont ces outils signalent leurs échecs — et un appel d’outil en échec renvoie un message d’erreur qui revient directement dans le contexte du modèle.

L’hypothèse du papier est simple et dérangeante : un message d’erreur d’outil porte une autorité implicite. Lorsqu’un modèle voit Error: ..., il bascule dans un mode de raisonnement correctif (« je dois réparer »), et ce mode est plus docile que sa posture habituelle. Un attaquant qui contrôle le contenu d’une chaîne d’erreur peut exploiter cette docilité. C’est une variante de l’injection de prompt indirecte : l’instruction malveillante ne vient jamais de l’utilisateur, elle arrive déguisée en retour système.

Comment ça marche

VATS — Vulnerability Analysis of Tool Streams — est un cadre de test piloté par mutation. Plutôt que de forger une charge unique à la main, il fait évoluer systématiquement des chaînes adverses selon sept dimensions structurelles et linguistiques, en cherchant la formulation et le placement qui maximisent la conformité. Le vecteur le plus efficace identifié est le positionnement structurel : intercaler l’instruction injectée au sein du contexte d’erreur environnant, de sorte qu’elle se lise comme une partie du diagnostic que le modèle cherche à traiter.

La raison pour laquelle cela surpasse l’injection ordinaire tient au raisonnement même de l’agent. Le texte d’un document non fiable rivalise avec la tâche de l’utilisateur pour capter l’attention ; un message d’erreur, lui, est la tâche du moment — l’agent est entraîné et incité à récupérer des échecs, il traite donc le canal d’erreur comme une entrée procédurale digne de confiance plutôt que comme une donnée à examiner avec méfiance. La distinction compte : la même phrase est plus dangereuse étiquetée comme erreur qu’enfouie dans une page web récupérée. Une dynamique voisine a été documentée dans Causality Laundering: Denial-Feedback Leakage in Tool-Calling LLM Agents (arXiv:2604.04035), où les chemins de refus et de retour fuient une influence non prévue par le concepteur.

Aucune charge utile n’est reproduite ici. Le mécanisme — un texte d’erreur contrôlé par l’attaquant est lu comme une instruction faisant autorité — constitue toute la leçon, et la forme structurelle (placer l’instruction là où le modèle attend une correction) suffit à comprendre le risque sans exploit fonctionnel.

Pourquoi c’est important

Le chiffre clé est l’écart, pas la valeur absolue. Sur quatre modèles de pointe — Gemini 3.1 Pro, GPT-5.5, GLM-5.1 et Qwen3-Coder — l’injection par le canal d’erreur a environ triplé le taux de réussite de l’injection de prompt indirecte standard, atteignant jusqu’à 100 % de conformité en évaluation contrôlée. Tous les modèles testés étaient vulnérables, ce qui pointe vers une faiblesse de classe dans la gestion des échecs plutôt que vers une particularité d’un éditeur.

Deux conséquences pour quiconque exploite des agents à outils. D’abord, votre frontière d’assainissement des entrées est probablement incomplète. Les équipes qui filtrent les documents récupérés et les entrées utilisateur laissent souvent passer la sortie des outils — surtout la sortie d’erreur — en supposant que c’est le runtime, et non un attaquant, qui l’a écrite. Tout outil qui renvoie du contenu contrôlable par l’attaquant dans une chaîne d’erreur (une requête de recherche réfléchie, un nom de fichier, un corps HTTP, un message de parseur) devient un canal d’injection. Ensuite, cela se cumule avec le triumvirat létal : un agent disposant d’un accès à des données privées, d’une exposition à du contenu non fiable et d’un canal d’exfiltration gagne un moyen supplémentaire et très efficace de se faire détourner.

Défenses

Le canal d’erreur doit être traité comme une donnée non fiable, pas comme une instruction privilégiée.

• Étiquetez la provenance et conservez-la. Marquez la sortie des outils — erreurs comprises — comme un canal distinct, de moindre confiance, et préservez cette étiquette tout au long du contexte, conformément à une hiérarchie d’instructions où l’intention du développeur et de l’utilisateur prime sur tout retour d’outil.
• Assainissez et gabaritez les chaînes d’erreur. Faites remplacer par le runtime le texte brut d’outil/d’exception par un objet d’erreur fixe et structuré (code + message sûr). N’insérez pas verbatim, dans l’erreur visible par le modèle, des sous-chaînes accessibles à l’attaquant (requêtes, noms de fichiers, corps de réponse).
• Retirez les impératifs du canal d’erreur. Une erreur doit décrire un état, jamais demander une action. Détectez et neutralisez le contenu en forme d’instruction qui arrive via la sortie d’outil avant qu’il ne réintègre le contexte.
• N’autorisez pas une erreur à élever les privilèges automatiquement. Un échec doit déclencher réessai / abandon / demande à un humain, pas un nouvel appel d’outil plus large. Maintenez la vérification avant validation sur le chemin de récupération d’erreur, pas seulement sur le chemin de succès.
• Testez les modes d’échec. Faites du red team délibéré sur la boucle d’erreur — la plupart des évaluations d’agents n’injectent que via les documents et les tours utilisateur, laissant non testé le canal d’erreur, là où VATS a trouvé 100 % de conformité.

État des lieux

Élément	Détail
Divulgation	arXiv:2606.07992, juin 2026
Vecteur	Injection indirecte via les messages d’erreur des outils (boucle d’erreur MCP)
Modèles évalués	Gemini 3.1 Pro, GPT-5.5, GLM-5.1, Qwen3-Coder
Effet	~3× le succès de l’IPI standard ; jusqu’à 100 % de conformité en tests contrôlés
Technique la plus efficace	Positionnement structurel (instruction intercalée dans le contexte d’erreur)
Prérequis	Influence de l’attaquant sur la sortie d’erreur de l’outil