Où l'on injecte compte : les agents font plus confiance à certaines zones de leur environnement

What is this?

Le 28 octobre 2026, une équipe comprenant Chengquan Guo, Bo Li et Jianfeng Gao a publié « Where You Inject Matters: The Trust Region Effect in LLM Agents » (arXiv:2610.38867, cs.AI, avec références croisées cs.CR et cs.LG). La plupart des travaux sur l’injection de prompt indirecte étudient ce que dit le texte malveillant. Cet article fixe le texte et ne fait varier que l’endroit où il apparaît dans l’environnement de l’agent. La sensibilité change nettement selon l’emplacement. Les auteurs parlent d’un effet de région de confiance : les agents accordent implicitement des niveaux de confiance différents aux différentes parties de leur environnement.

Résultat principal en codage : avec GPT-5.4, une instruction dangereuse placée dans un fichier de documentation (README ou TODO) a été suivie en moyenne environ 2,6 fois plus souvent que la même instruction dans un fichier de code ou de données. Il s’agit d’une étude de mesure sur un angle mort défensif, pas d’un exploit.

How it works

Les auteurs ont construit trois bancs d’essai agentiques : codage (basé sur Terminal-Bench-2), usage d’outils (basé sur AgentDojo) et flux de travail quotidiens (basé sur DecodingTrust-Agent). Ensemble : 30 tâches bénignes, 24 risques d’injection et 36 surfaces d’environnement. Chaque injection est placée à un niveau grossier (quelle surface : type de fichier, e-mail, message Slack, avis) et à un niveau fin (début, milieu ou fin du contenu). Le succès est jugé par des vérificateurs déterministes et non par un LLM, et la métrique ne compte que les injections réellement lues par l’agent.

Tendances rapportées (chiffres tels que donnés dans l’article, qui teste des modèles de plusieurs éditeurs) :

• La surface compte. Dans le banc de codage avec GPT-5.4, un risque de type reconnaissance a réussi dans 86 % des cas depuis un README et 61 % depuis un fichier TODO, contre 19 % depuis des fichiers de code et 30 % depuis des fichiers de données. Dans le banc « workflow », un risque de type hameçonnage a atteint 23 % via GitHub, 17 % via Slack, 9 % via Confluence et 0 % via Jira.
• La position compte moins, mais de façon constante. Le contenu placé en fin de document était le plus efficace dans les trois domaines.
• Les modèles diffèrent fortement. Les taux de succès conditionnels globaux en codage allaient de presque zéro pour certains modèles de pointe à 67,0 % pour Gemini-3.1-Pro, avec 12,2 % pour GPT-5.4.
• Un attaquant peut apprendre l’emplacement. Un petit attaquant entraîné à optimiser conjointement contenu et emplacement a atteint 59,1 % de succès contre 37,0 % pour l’optimisation du seul contenu, et s’est transféré à un autre modèle victime là où les modèles de référence par gabarit obtenaient 0 %.

Aucune charge utile n’est reproduite ici. L’enseignement est structurel : la confiance d’un agent est inégale et apprenable.

Why it matters

On considère souvent la documentation d’un projet comme inerte. L’article montre que, pour les agents, les fichiers de documentation figurent parmi les entrées les plus influentes, ce qui rejoint des travaux pratiques publiés quelques jours plus tôt. Le 22 octobre 2026, Forever Security a décrit comment une page web peut déposer discrètement un fichier AGENTS.md ou CLAUDE.md dans le dossier Téléchargements d’un utilisateur ; un agent de code lancé ensuite dans ce dossier le traite comme des instructions de projet fiables. Selon les auteurs, cela repose sur la confiance de l’agent envers son dossier de travail, non sur un bogue produit. Voir aussi l’injection AGENTS.md dans la chaîne d’approvisionnement et la hiérarchie d’instructions.

Les limites comptent aussi. L’article décrit un comportement, pas un mécanisme interne ; il couvre trois bancs d’essai et seulement l’injection indirecte ; et son attaquant a été entraîné contre un seul modèle victime. Les pourcentages indiquent un risque relatif, pas des taux de production.

Defenses

L’article ne propose pas de défense précise ; il soutient que les défenses doivent tenir compte de l’emplacement pour limiter l’influence du contenu non fiable. Mesures pratiques qui en découlent :

1. Traiter la documentation comme une entrée non fiable. Les README, TODO, CONTRIBUTING et fichiers d’instructions d’agent issus de dépôts ou de dossiers que vous n’avez pas rédigés ne doivent pas avoir l’autorité d’un opérateur.
2. Ne pas lancer d’agents dans des dossiers où le web peut écrire, comme Téléchargements, et relire les fichiers d’instructions que vous n’avez pas écrits avant qu’un agent ne les charge.
3. Protéger la configuration de l’agent. Alerter sur les modifications inattendues des serveurs MCP, des URL de base d’API et des proxys, et exiger une validation pour toute modification de la configuration de l’agent.
4. Pondérer la confiance par surface. Lorsque votre framework le permet, marquer la provenance par source et limiter les actions que peut déclencher un texte issu de surfaces peu fiables.
5. Tester en variant l’emplacement. En red teaming de vos agents, faites varier l’emplacement et la position des injections, pas seulement la formulation ; un seul emplacement peut sous-estimer le risque.
6. Garder les validations et le sandboxing activés, et appliquer le moindre privilège aux outils et aux identifiants.

Status

Élément	Référence	Date	Notes
Article « trust region »	arXiv:2610.38867	2026-10-28	Trois bancs d’essai, modèles de plusieurs éditeurs
Fichiers d’instructions dans Téléchargements	Forever Security	2026-10-22	Codex et Claude Code testés ; les auteurs ne rapportent aucune déclaration des éditeurs
Digest citant les deux	Adversa AI	2026-11-02	Synthèse secondaire
État des correctifs	n/a	n/a	Constat comportemental ; pas de correctif unique