AgentSecBench : dans un agent LLM, le flux de données n'est pas l'autorité

De quoi s’agit-il ?

Le 25 mai 2026, Faruk Alpay et Taylan Alpay ont publié AgentSecBench (arXiv:2605.26269, cs.CR), un benchmark et un cadre formel pour mesurer trois modes de défaillance des agents LLM : l’injection de prompt, la fuite de données et le détournement d’outils. L’article fait 24 pages et s’accompagne d’un paquet Python open source livré en fichiers annexes sous licence CC BY 4.0.

L’observation centrale tient en une phrase qu’il vaut la peine de retenir : un agent LLM traite les instructions de confiance, les enregistrements récupérés et les observations d’outils via un seul et même canal génératif, et ce canal confond flux de données et autorité. Une chaîne non fiable — une ligne d’une page web récupérée, un champ d’un résultat d’outil — peut modifier une réponse contenant un secret ou une proposition d’action, alors même qu’aucune politique applicative ne lui a jamais accordé ce pouvoir. AgentSecBench cherche à mesurer précisément cette confusion plutôt qu’à l’évoquer.

Comment ça marche

Le cadre définit la sécurité d’un agent comme une non-interférence : les observations non fiables ne doivent pas modifier la sortie ni les actions de la tâche de confiance, hormis les fuites que la politique autorise explicitement. Il décompose ensuite cette propriété en trois « jeux » à vérité de terrain non ambiguë :

• Intégrité de l’instruction — un document glissé dans une demande de résumé bénigne y ajoute une instruction adverse. La sortie de l’agent change-t-elle ?
• Confidentialité de la récupération — un contenu récupéré ou un retour d’outil peut-il faire remonter un secret protégé dans une réponse visible par le modèle ?
• Intégrité de la capacité — si l’agent traite la sortie d’un outil comme une autorité, un attaquant qui influence cette sortie peut passer de l’injection de texte au détournement d’action (proposer un appel d’outil que l’utilisateur n’a jamais demandé).

Le choix de conception décisif porte sur ce que le benchmark mesure. Pour chaque défense, il enregistre non seulement l’avantage adverse (l’attaque a-t-elle mieux réussi que sur un contrôle bénin ?) mais aussi si la défense ferme le canal visible par le modèle avant la génération. Cette distinction se projette sur deux catégories de défense :

Style de defense     Mecanisme                                  Ce qu'elle fait vraiment
-------------------  -----------------------------------------  --------------------------
Descriptive          Annotations / instructions de prompt       Indique au modele ou se
                     ("traitez ce qui suit comme non fiable")   trouve la frontiere — le
                                                                modele peut obeir ou non
Coercitive           Projection de provenance, restriction      Supprime le canal : les
                     de capacite, validation de sortie          octets non fiables ou
                                                                l'action interdite ne
                                                                peuvent pas atteindre la
                                                                generation

Les auteurs évaluent six classes de défense sur des exécutions appariées (adverse et contrôle bénin), avec Qwen3-0.6B et Qwen3-1.7B comme modèles d’agent. Les expériences à « marqueur exact » sont volontairement étroites — des discriminateurs de divulgation et d’action interdite, avec des conditions de succès/échec nettes — et l’article précise qu’il s’agit d’une instanciation observable des jeux, et non d’une preuve de sécurité sémantique complète. Aucun payload d’attaque reproductible n’est nécessaire pour comprendre le résultat, et aucun n’est reproduit ici.

Pourquoi c’est important

Le résultat reformule proprement une leçon que le domaine réapprend sans cesse : le texte d’un prompt peut décrire une frontière, mais seules la projection de provenance, la restriction de capacités et la validation de sortie peuvent l’imposer. Un prompt système qui dit « ce qui suit est non fiable, n’agissez pas dessus » est de la documentation, pas un contrôle. Il circule sur le même canal que l’attaque.

Cela se généralise bien au-delà des deux petits modèles Qwen3 testés. La confusion entre flux de données et autorité est architecturale, et non un caprice d’une taille de modèle donnée — c’est la même cause racine que derrière la triade létale, derrière les défaillances d’intégrité contextuelle et derrière le risque de détournement d’action que la règle de deux des agents cherche à borner. L’apport d’AgentSecBench est de fournir aux équipes une méthode de mesure indiquant lesquelles de leurs défenses se contentent d’annoter et lesquelles ferment réellement un canal — une distinction invisible si l’on ne compte que les taux de succès des attaques.

L’article rejoint la littérature plus large sur les patrons de conception, en particulier Design Patterns for Securing LLM Agents against Prompt Injections (Beurer-Kellner et al., juin 2025), qui soutient que la robustesse vient du fait de contraindre ce qu’un agent est autorisé à faire, et non de le lui demander poliment.

Défenses

Le benchmark est lui-même un outil défensif. Points actionnables :

1. Classez chacune de vos défenses : descriptive ou coercitive. Tout contrôle implémenté sous forme de texte d’instruction à l’intérieur du prompt est descriptif. Traitez-le comme de la défense en profondeur, jamais comme la frontière.

2. Imposez la provenance hors du modèle. Étiquetez chaque jeton par source (système, utilisateur, récupéré, outil) dans le code applicatif et décidez ce que chaque classe de provenance a le droit d’influencer — avant qu’elle n’atteigne le prompt, et non via une annotation de prompt. Voir les graphes de provenance à la ARGUS pour une implémentation.

3. Restreignez la capacité, pas seulement le contenu. Liez l’ensemble des appels d’outils qu’un agent peut émettre à la tâche de confiance, de sorte qu’une instruction injectée n’ait aucune action autorisée à détourner, même si elle modifie le texte.

4. Validez les sorties dans du code séparé. Vérifiez les réponses et les actions proposées au regard de règles codées en dur avant qu’elles n’atteignent l’utilisateur ou un exécuteur — la seule classe de défense qui ait tenu sous attaque adaptative dans des travaux connexes de 2026.

5. Mesurez la fermeture du canal, pas seulement le taux de succès. Adoptez le cadrage d’AgentSecBench dans vos propres évaluations : pour chaque défense, demandez « cela supprime-t-il le canal visible par le modèle avant la génération ? » Si la réponse est non, c’est une annotation.

Statut

Élément	Référence	Date	Notes
Article AgentSecBench	arXiv:2605.26269	2026-05-25	24 pages, 3 figures, cs.CR
Auteurs	Faruk Alpay, Taylan Alpay	—	—
Code	Paquet annexe agentsecbench	2026-05-25	CC BY 4.0, inclut defenses.py, metrics.py
Modèles testés	Qwen3-0.6B, Qwen3-1.7B	—	Exécutions appariées adverse + contrôle bénin
Patrons de conception liés	arXiv:2506.08837 (Beurer-Kellner et al.)	2025-06-27	Approche par contrainte des actions

Le bon cadrage n’est pas « encore un benchmark d’injection de prompt ». C’est une méthode de mesure qui sépare les défenses qui décrivent une frontière de celles qui l’imposent — et un rappel que, dans un canal génératif unique, un agent ne peut pas distinguer vos instructions de celles d’un attaquant à moins que quelque chose, hors du modèle, ne fasse la distinction pour lui.