ASPI : demander une clarification élargit la surface d'injection

De quoi s’agit-il ?

Le 17 mai 2026, une équipe de Scale AI (Udari Madhushani Sehwag, Zhengyang Shan, Heming Liu, Dileepa Lakshan, Joseph Brandifino et Max Fenkell) a publié ASPI: Seeking Ambiguity Clarification Amplifies Prompt Injection Vulnerability in LLM Agents sur arXiv (2605.17324, cs.CR). Le résultat dérange parce qu’il met en cause un comportement que tout le secteur considère comme une bonne pratique : face à une tâche sous-spécifiée, un agent bien conçu doit s’arrêter et demander à l’utilisateur ce qu’il voulait dire avant d’agir.

ASPI — Ambiguous-State Prompt Injection — est un benchmark de 728 scénarios tâche-attaque qui isole l’état « demander une clarification » comme un état distinct de l’agent et mesure si l’entrée dans cet état change la facilité avec laquelle l’agent est détourné. La réponse, sur dix modèles de pointe, est oui, et nettement. Les données et le harnais sont publics sur github.com/scaleapi/aspi.

Comment ça marche

Le benchmark compare le même scénario dans deux configurations appariées. Dans la configuration d’exécution, l’agent reçoit une instruction entièrement spécifiée et ne rencontre du contenu adverse qu’indirectement, via les données renvoyées par un outil. Dans la configuration de clarification, l’instruction est sous-spécifiée : l’agent doit d’abord poser une question à l’utilisateur et réintégrer la réponse à son plan avant d’agir. Tout le reste est maintenu constant — même tâche, même contenu injecté, mêmes outils — de sorte que toute différence de réussite est attribuable à la transition d’état elle-même.

Setting          Agent flow                                    Adversarial entry point
---------------  --------------------------------------------  -----------------------------
Execution        instruction -> act -> tool data               tool-returned content
Clarification    instruction -> ASK USER -> incorporate -> act  clarification interface + data

L’écart mesuré est important. Le taux de réussite passe de 1,8 % à 34,0 % sur o3 et de 2,2 % à 35,7 % sur Gemini-3-Flash, avec le même sens d’effet sur le reste des dix modèles testés. Une analyse de décomposition scinde la cause en deux. Il y a un glissement dépendant de l’état : une fois en mode « je lève une ambiguïté », le modèle traite le contenu entrant avec plus de crédulité, considérant un texte ressemblant à des instructions comme quelque chose à exécuter plutôt qu’à examiner. Et il y a un effet propre au canal : la réponse de clarification est un second chemin d’entrée, sollicité par l’agent, qui arrive pré-validé comme « l’utilisateur répondant à ma question » — une frontière plus faible que la sortie d’outil dont l’agent se méfie déjà. Le papier s’arrête volontairement à la caractérisation de la surface ; il livre un benchmark, pas un payload armé.

Pourquoi c’est important

La plupart des évaluations de sécurité d’agents sont menées en configuration d’exécution — tâche entièrement spécifiée, canal adverse unique — et la thèse centrale d’ASPI est que cela sous-estime systématiquement la surface d’attaque réelle des agents interactifs. La robustesse sur une tâche propre et entièrement spécifiée ne se transfère pas à la robustesse une fois que l’agent engage un va-et-vient avec l’utilisateur, ce qui est précisément le mode dans lequel les assistants en production passent une grande partie de leur temps.

Cela rejoint un thème qui traverse la littérature de sécurité des agents de juin 2026 : les agents sont fragiles précisément au niveau de leurs coutures d’interaction. Le panorama d’Adversa AI du 1er juin 2026 classe ASPI aux côtés de travaux soutenant que la séparation données/instructions est peut-être fondamentalement difficile. La lecture pratique : les tours de clarification sont un canal privilégié — et tout canal privilégié qu’un attaquant peut influencer devient une cible. Si du contenu injecté peut façonner la question posée à l’utilisateur, ou se glisser dans ce que l’utilisateur recolle, l’agent le rencontre dans son état le plus suggestible.

Défenses

Quatre mesures découlent directement du cadrage du papier, même si ASPI n’en prescrit aucune.

1. Évaluez les agents en état de clarification, pas seulement en exécution. Ajoutez des variantes de tâches sous-spécifiées à votre suite de red team. Un modèle qui passe un benchmark d’injection entièrement spécifié peut échouer une fois en plein dialogue, et vous ne le verrez pas sur un classement « exécution seule ».
2. Traitez la réponse de clarification comme une entrée non fiable. La réponse de l’utilisateur n’est pas un canal de contrôle fiable du simple fait que l’agent l’a sollicitée. Soumettez-la au même nettoyage des instructions, au même marquage de provenance et aux mêmes contrôles de politique que la sortie d’outil.
3. Gardez la politique d’action fixe à travers les transitions d’état. Les décisions de portée, d’accès aux outils et d’irréversibilité ne doivent pas se relâcher parce que l’agent est passé en mode « levée d’ambiguïté ». Re-confirmez les actions à fort impact au regard de l’objectif initial, antérieur à la clarification.
4. Préférez une clarification contrainte au texte libre. Quand c’est possible, levez l’ambiguïté par des choix bornés (sélectionner l’un de N) plutôt que par une réponse ouverte susceptible de véhiculer des instructions, rétrécissant le canal identifié par le papier.

Statut

Élément	Référence	Date	Notes
Papier ASPI	arXiv:2605.17324 (cs.CR, cs.AI)	2026-05-17	728 scénarios, 10 modèles de pointe, exécution vs. clarification appariées
Résultat phare	o3 1,8 % → 34,0 % ; Gemini-3-Flash 2,2 % → 35,7 %	2026-05-17	L’état de clarification amplifie la réussite des attaques
Données + harnais	github.com/scaleapi/aspi	2026-05	Benchmark public reproductible
Contexte	Panorama sécurité agentique Adversa AI	2026-06-01	Classe ASPI parmi les vulnérabilités d’agents

ASPI ne décrit pas un bug corrigeable dans un produit ; il décrit une propriété de la façon dont les agents actuels gèrent un état qu’ils sont conçus pour adopter souvent. L’enseignement utile est étroit et actionnable : si votre agent demande un jour à un utilisateur « que vouliez-vous dire ? », vos tests de sécurité doivent lui retourner la même question.