La sécurité des agents se joue dans les transitions, pas dans les composants

De quoi s’agit-il ?

Toward Secure LLM Agents: Threat Surfaces, Attacks, Defenses, and Evaluation (arXiv:2606.10749, publié en juin 2026) est une systématisation de 247 articles sur la sécurité des agents, organisée autour d’une seule idée de niveau système : un agent LLM n’est pas un chatbot qui appelle parfois un outil, c’est une boucle qui relie flux d’information, autorité déléguée et état persistant. Dès que le modèle s’inscrit dans cette boucle, les défaillances cessent d’être « le modèle a dit quelque chose de dangereux » pour devenir des workflows détournés, des appels d’outils non autorisés, une mémoire corrompue et des actions externes nuisibles.

Le corpus lui-même illustre la vitesse du phénomène : 3 articles en 2023, 42 en 2024, puis 121 en 2025, et 81 de plus collectés avant fin avril 2026 — soit environ un tiers du domaine apparu en une seule année partielle. L’essentiel (environ 68 %) reste des préprints arXiv, ce que les auteurs signalent comme le signe d’un champ réel mais pas encore normalisé.

Comment ça marche

La contribution centrale de l’étude est un recadrage, pas un exploit. Elle soutient que la sécurité des agents doit s’analyser en termes de transitions d’état plutôt que de composants isolés. Le moment dangereux n’est pas celui où l’agent lit un texte non fiable — c’est celui où ce texte est autorisé à changer de catégorie sans médiation :

• un contenu non fiable est réinterprété comme une contrainte de planification ;
• un plan provisoire se durcit en décision exécutable ;
• une trace stockée est ensuite réutilisée comme contexte de confiance.

Cette perspective explique pourquoi la sécurité des agents diffère à la fois de la sécurité applicative classique et de la sûreté limitée au prompt. La question n’est pas seulement ce que le système a vu, mais ce qu’il est désormais autorisé à faire parce qu’il l’a vu.

La cartographie empirique des surfaces le confirme. En comptant les surfaces de menace dans le corpus, les prompts utilisateur arrivent en tête avec 82 articles — mais ce n’est qu’un point d’entrée parmi d’autres. Le contenu web apparaît dans 55 articles, les sorties d’outils dans 54, le contenu récupéré dans 37, et les fichiers/code, la boucle de planification, la mémoire/les brouillons et les canaux inter-agents dans au moins 25 chacun. Le prompt direct est minoritaire ; ce sont les chemins de contrôle médiés et internalisés qui dominent. Trois principes de modélisation en découlent : l’ambiguïté données–contrôle (l’agent consomme un texte pertinent pour la tâche mais non fiable), l’autorité déléguée (l’agent agit avec des permissions que l’attaquant ne possède pas) et la persistance et propagation (le préjudice est différé, ressurgissant plus tard via la mémoire ou les messages entre agents).

Surtout, ce n’est pas la théorie d’une seule équipe. L’AI Red Team de Microsoft, forte de douze mois d’engagements contre des agents déployés, a publié le 4 juin 2026 une taxonomie révisée des modes de défaillance qui nomme indépendamment la même frontière : contamination du contexte de session, empoisonnement de mémoire par injection inter-domaines, escalade de confiance inter-agents et divulgation de capacités transformant le sondage boîte noire en chemin d’exploitation boîte blanche. Deux méthodes très différentes — une synthèse de littérature et du red teaming opérationnel — convergent vers la même conclusion.

Pourquoi c’est important

Le constat principal est inconfortable : l’injection de prompt et le détournement de flux de contrôle médié par les outils dominent toujours, tandis que la corruption d’état persistant et la propagation multi-agents montent — et les défenses actuelles sont faiblement composables. Les mitigations fonctionnent isolément mais ne s’empilent pas proprement en une garantie de bout en bout. Les données de terrain de Microsoft renforcent le point : le contournement du contrôle humain (human-in-the-loop) a été le mode de défaillance le plus systématiquement exploité, parfois sous forme de chaînes sans clic où aucune étape ne paraît anormale mais où le résultat composé est une exfiltration ou un déplacement latéral.

L’étude met aussi en cause notre façon de mesurer les progrès. Les benchmarks existants sous-représentent les risques à long horizon, à état et sensibles au déploiement — précisément les transitions qui comptent le plus. Une défense qui obtient de bons scores sur des tests d’injection mono-tour peut échouer quand la contamination est semée tôt et se déclenche bien plus tard, à travers une session ou une chaîne de délégation.

Défenses

La prescription de l’étude est architecturale, et se traduit directement en contrôles adoptables dès maintenant :

• Rendez les frontières de confiance explicites. Étiquetez chaque canal par son autorité. Le contenu web, les documents récupérés et les sorties d’outils sont des observations à faible autorité et ne doivent jamais être promus silencieusement en instructions. Séparez structurellement le contexte système de confiance du contenu récupéré non fiable.
• Contrôlez le privilège au niveau de l’action, pas du prompt. Placez les vérifications de capacité à la transition d’exécution d’outil, au moindre privilège. Le fait que le modèle décide d’agir n’est pas une autorisation d’agir.
• Gérez l’état avec sa provenance. Tracez l’origine des entrées de mémoire ; traitez la mémoire écrite par l’agent comme non fiable à la relecture. Une seule injection réussie qui ensemence la mémoire peut se propager à toutes les sessions ultérieures — donc assainissez et bornez ce qui est persisté.
• Durcissez le human-in-the-loop comme contrôle de sécurité. Décomposez les actions composées avant approbation, résumez les approbations à partir des appels d’outils sous-jacents plutôt que de la description de l’agent, hiérarchisez les approbations selon la réversibilité et le rayon d’impact, et surveillez les schémas de fatigue de consentement.
• Vérifiez l’identité des agents, ne la déduisez pas. Dans les systèmes multi-agents, exigez des justificatifs attestables au passage de relais ; rejetez les rôles auto-déclarés. Cela ferme le chemin du « député confus » de l’escalade de confiance inter-agents.
• Évaluez sur des trajectoires complètes. Testez des scénarios à long horizon et à état — semez la contamination tôt et mesurez en aval — et pas seulement l’injection mono-tour. (OWASP LLM01 reste la référence de base pour la classe d’injection.)

Statut

Élément	Détail
Source principale	Toward Secure LLM Agents (arXiv:2606.10749), juin 2026, 247 articles
Corroboration	Taxonomie des modes de défaillance v2.0, AI Red Team Microsoft, 4 juin 2026
Menaces dominantes	Injection de prompt, détournement de flux de contrôle médié par les outils
Frontière émergente	Corruption d’état persistant, propagation multi-agents
Lacune clé	Défenses faiblement composables ; benchmarks ignorant le risque à long horizon/à état
Nature	Systématisation défensive — aucun code d’exploitation, aucune attaque inédite

La leçon pratique est un modèle mental, pas un correctif. Cessez de vous demander seulement si votre agent peut être amené à dire quelque chose, et commencez à cartographier les transitions de votre système — entrée vers plan, plan vers décision, décision vers action, action vers mémoire stockée, mémoire vers l’agent suivant. Chacune de ces flèches est un endroit où des données non fiables peuvent franchir le seuil de l’autorité. Les laboratoires et la littérature s’accordent désormais : c’est en sécurisant ces flèches, et non en durcissant le seul modèle, que se gagne ou se perd la sécurité des agents.