AgentShield : démasquer les agents compromis avec des honeytokens et des outils-leurres

De quoi s’agit-il ?

AgentShield est un cadre de détection par déception destiné aux agents LLM outillés, publié sur arXiv en mai 2026 (2605.11026). Plutôt que de tenter de filtrer l’instruction malveillante en entrée — approche dont un nombre croissant de travaux soutient qu’elle ne pourra jamais pleinement réussir — il admet qu’une injection indirecte de prompt (IPI) finira parfois par passer, et se concentre sur la détection de l’agent en flagrant délit, une fois détourné. Le pari est emprunté à la détection d’intrusion classique : un acteur compromis se comporte différemment d’un acteur légitime, et l’on peut planter des fils-pièges que seul un attaquant a une raison de toucher.

Le travail a été repris dans la revue de juin 2026 d’Adversa AI sur la sécurité des agents et s’inscrit dans un glissement plus large, en 2026, du « bloquer l’injection » vers le « détecter la compromission ».

Comment ça marche

AgentShield place trois couches de pièges dans l’interface outillée et l’environnement de l’agent, puis observe ce que l’agent en fait.

Couche               Leurre place                          Se declenche quand…
-------------------  ------------------------------------  --------------------------------
Honeytools           Faux outils aux descriptions          L'agent invoque un outil qu'aucune
(faux outils)        tentantes / ouvertement malveillantes tache benigne n'appellerait
                     (ex. export_all_user_data,
                     exfiltrate_data_to_[REDACTED])
Honeytokens          Fausses identifiants places la ou un  Une fausse cle API / un faux mot de
(faux identifiants)  agent normal ne lit jamais — fausses  passe admin / un faux chemin SSH
                     cles API, chaines BDD, chemins SSH    apparait dans un parametre sortant
Liste blanche params Forme attendue des arguments par      Un outil est appele avec des valeurs
                     outil                                 hors de son enveloppe legitime

Les honeytools n’effectuent jamais d’action nuisible — en invoquer un est, par construction, un signal et non une capacité. Les honeytokens sont la pièce la plus astucieuse : ils sont placés dans des régions du contexte qu’un agent légitime n’a aucune raison de lire ; donc si l’une de ces fausses valeurs apparaît dans un appel d’outil sortant, c’est que quelque chose a orienté l’agent vers l’exfiltration. Un moniteur inspecte chaque appel sortant à la recherche de ces signatures, et un classifieur auto-supervisé transforme les signaux bruts en verdict de compromission.

Point essentiel : il s’agit d’une couche de détection, pas d’une attaque. Elle ne rend pas l’agent sous-jacent plus capable ; elle rend un agent détourné plus bruyant. Aucune charge d’exploitation n’est reproduite ici — la référence canonique est le texte intégral arXiv.

Pourquoi c’est important

La plupart des défenses d’agents se situent côté entrée : classifieurs, entraînement à la hiérarchie d’instructions, analyse des résultats d’outils, spotlighting. Elles réduisent la fréquence des injections réussies, mais aucune n’atteint zéro, et plusieurs résultats récents soutiennent qu’un séparateur parfait données/instructions est inatteignable par principe. Reste donc une faille : lorsqu’une injection passe malgré tout, qu’est-ce qui vous prévient ?

La déception comble cette faille avec un mode de défaillance différent. Un faux négatif sur un classifieur d’entrée est silencieux ; un honeytoken qui atterrit dans une requête sortante est une alarme à forte confiance, précisément *parce qu’*aucun flux honnête ne le produit. Selon le papier, sur plus de 6 800 essais répartis sur quatre LLM de trois fournisseurs, AgentShield a détecté 90,7 à 100 % des attaques réussies sur les modèles commerciaux, avec zéro fausse alerte sur 485 essais d’usage normal, et a résisté à une évaluation systématique par attaque adaptative avec zéro évasion sur les modèles commerciaux. Le classifieur auto-supervisé se transférerait d’un modèle et d’une langue à l’autre sans réentraînement — il a été vérifié au-delà de l’anglais, y compris sur des langues moins dotées comme le kurde et l’arabe. Traitez les chiffres d’un papier isolé comme un plafond dans les conditions des auteurs, non comme une garantie de terrain ; mais la direction est ce qui compte : les défenses côté détection se dégradent en douceur là où les filtres d’entrée échouent, ouverts ou fermés.

Défenses

Vous pouvez appliquer l’idée sous-jacente dès aujourd’hui sans attendre la publication d’un cadre. La déception est peu coûteuse à déployer et, contrairement au réentraînement de modèle, ne touche pas à la performance de votre agent sur sa tâche.

1. Semez des honeytokens que votre agent ne devrait jamais émettre. Placez quelques fausses identifiants — une fausse clé API, une fausse chaîne de connexion BDD, une fausse URL d’admin — dans des régions du contexte qu’un déroulé légitime ne fait jamais remonter. Puis surveillez chaque appel d’outil sortant, requête réseau et message à la recherche de ces chaînes exactes. Une correspondance est une tentative d’exfiltration quasi certaine. C’est l’étape au plus fort rendement.

2. Ajoutez des honeytools à la liste d’outils. Enregistrez un ou deux outils aux descriptions manifestement sensibles (export_all_user_data, disable_safety_filters) qui ne font rien d’autre que lever une alerte lorsqu’ils sont appelés. Un agent bénin n’a aucune raison de les choisir ; un agent détourné poursuivant l’objectif injecté le fera souvent.

3. Mettez en liste blanche l’enveloppe des paramètres par outil. Définissez la forme et les plages de valeurs attendues pour les arguments de chaque outil réel, et signalez les appels qui en sortent. Cela attrape les cas de dérive d’objectif où le bon outil est appelé avec des entrées inadaptées à la tâche.

4. Surveillez les appels sortants, pas seulement le texte entrant. L’observation décisive de ces travaux est que la couche d’action est l’endroit où la compromission devient visible. Journalisez et inspectez chaque invocation d’outil et ses paramètres ; c’est aussi là que se consomme la triade létale.

5. Superposez la déception aux défenses d’entrée, sans les remplacer. La détection suppose que l’injection a déjà fonctionné. Conservez vos contrôles côté entrée (privilèges minimaux, bac à sable, humain dans la boucle pour les actions à fort rayon d’impact) et traitez les honeytokens comme le filet qui vous prévient quand ces contrôles ont été contournés.

6. Faites tourner et variez vos leurres. Des pièges statiques invitent l’attaquant adaptatif à les apprendre puis à les éviter. Variez les formats de tokens, les noms de honeytools et leur emplacement, pour qu’un attaquant ne puisse pas distinguer fiablement l’appât de l’état réel.

Statut

Élément	Référence	Date	Notes
Papier AgentShield	arXiv 2605.11026	2026-05	Déception à trois couches : honeytools, honeytokens, liste blanche de paramètres
Détection annoncée	Texte intégral arXiv	2026-05	90,7–100 % des attaques réussies sur modèles commerciaux ; 0 fausse alerte / 485 essais
Périmètre d’évaluation	Texte intégral arXiv	2026-05	6 800+ essais, 4 LLM / 3 fournisseurs ; multilingue, dont kurde et arabe
Couverture communautaire	Adversa AI	2026-06-01	Cité parmi les défenses d’agents pour juin 2026

L’idée à retenir : la déception ne remplace pas les défenses contre l’injection de prompt — elle suppose qu’elles échoueront parfois et vous donne un signal bruyant, à faible taux de faux positifs, quand c’est le cas. Pour quiconque exploite des agents outillés exposés à du contenu non fiable, quelques honeytokens bien placés figurent parmi les contrôles de détection les moins coûteux disponibles.