IterInject : quand un LLM optimise lui-même ses injections de prompt indirectes

De quoi parle-t-on ?

Le 23 mai 2026, des chercheurs de Shanghai Jiao Tong University et de l’Université de Hong Kong ont publié sur arXiv IterInject: Indirect Prompt Injection Against LLM Agents via Feedback-Guided Iterative Optimization. Le papier ne revendique pas un nouveau motif de payload. Il revendique quelque chose de plus inconfortable : que le problème de recherche au cœur de l’injection de prompt indirecte (IPI) peut être automatisé, et que l’optimiseur ainsi obtenu pousse les taux de succès d’attaque bien au-delà de ce que les payloads statiques ou faits à la main parvenaient à atteindre sur les benchmarks AgentDojo et InjecAgent.

Les chiffres saillants, repris de l’évaluation du papier : sur les 510 instances d’attaque d’AgentDojo réparties en quatre suites de tâches, IterInject obtient le meilleur ASR global sur chacun des quatre modèles victimes testés, avec le plus gros écart sur DeepSeek (47,8 % contre 32,9 % pour la meilleure baseline statique). Sur InjecAgent, l’ASR total passe de presque zéro avec des prompts statiques à 33–90 % selon la victime. Les auteurs lancent aussi une expérience d’extension contre Claude Code, un agent de codage de niveau production aux défenses superposées, et rapportent 5 cibles sur 9 compromises avec des payloads optimisés.

Comment ça marche

IterInject traite la fabrication de payloads comme une boucle fermée à trois composants, tous décrits dans le papier au niveau du mécanisme — pas au niveau d’un exploit prêt à coller.

                +-------------------------+
                |   agent LLM victime     |
                |   (exécute la tâche     |
                |    du benchmark)        |
                +-----------+-------------+
                            |
                            v
                +-------------------------+
                |  diagnostiqueur à règles|
                |  -> label structuré +   |
                |     description du      |
                |     comportement        |
                +-----------+-------------+
                            |
                            v
                +-------------------------+
                |  optimiseur LLM         |
                |  conditionné sur le     |
                |  journal complet        |
                |  -> payload suivant     |
                +-----------+-------------+
                            |
                            v
                  (boucle, avec synthèse
                   de graines pour élargir
                   l'espace des stratégies)

Trois propriétés comptent pour les défenseurs.

Premièrement, le diagnostiqueur est structuré, pas en texte libre. Chaque tentative reçoit un label comportemental (outil invoqué, paramètre exfiltré, refus, sans effet, déviation partielle), ce qui évite à l’optimiseur de patauger sur un seul signal binaire de succès. C’est ce qui permet à la boucle d’échapper aux optima locaux dans lesquels les prompts IPI faits à la main ont tendance à se coincer.

Deuxièmement, l’optimiseur est lui-même un LLM conditionné sur le journal d’exécution. Il n’a pas besoin d’accès au gradient du modèle victime, ce qui rend l’attaque opérante sur des agents de production fermés. C’est la même observation que celle qui a porté les travaux de jailbreak adaptatif sur les dix-huit derniers mois (voir The Attacker Moves Second) — appliquée ici spécifiquement à la surface IPI.

Troisièmement, les auteurs ajoutent par-dessus les résultats empiriques une analyse mécaniste. Ils signalent un seuil médié par l’attention : les payloads réussissent quand le contenu injecté capte assez de l’attention du modèle pour la détourner du prompt système initial et franchir une frontière propre au modèle. Des interventions causales sur les têtes d’attention concernées modifient le résultat. L’implication est que les défenses fondées sur la “séparation données/instructions” — paradigme dominant des garde-fous IPI actuels — se battent sur le mauvais axe : elles assainissent le texte sans changer la façon dont l’attention est allouée une fois ce texte placé dans la fenêtre de contexte.

Pourquoi c’est important

Le cadrage “nouvelle attaque” n’est pas le bon. La technique généralise une procédure de recherche déjà présente dans la littérature pour les jailbreaks (PAIR, TAP, optimisation automatique de prompts) et la transpose proprement au cadre IPI. Ce qui est nouveau, c’est le plancher que la recherche en boucle fermée fixe désormais à l’attaquant.

Trois enseignements pour les équipes qui déploient des agents.

L’écart entre les benchmarks de recherche et les agents de production est faible. Cinq cibles Claude Code compromises sur neuf sous boucle adaptative reste du même ordre de grandeur que les benchmarks en labo. Si vous faites tourner un agent de codage contre du code, des pull requests ou de la documentation externes non fiables, le modèle de menace n’est plus “un humain déterminé écrit le prompt parfait” — c’est “un LLM en écrit quelques centaines pendant la nuit et garde ceux qui ont fonctionné”.

Le résultat mécaniste sape des familles entières de défenses. Si le succès est gouverné par l’allocation d’attention plutôt que par une distinction de forme entre données et instructions, alors le balisage de préfixes, le balisage de rôles et l’assainissement des entrées continueront à produire les mêmes chiffres décevants sur AgentDojo — les défenses qui réduisent l’ASR réduisent aussi l’utilité, et les résultats IterInject élargissent cet écart, ils ne le referment pas.

L’évaluation doit supposer l’adaptativité. Un garde-fou qui résiste à un corpus fixe de chaînes d’injection ne dit presque rien sur son comportement sous un optimiseur guidé par feedback. C’est désormais une troisième source de preuve indépendante — Carlini et al. sur les jailbreaks, Abdelnabi & Bagdasarian sur l’intégrité contextuelle, et maintenant IterInject sur l’IPI spécifiquement — qui dit la même chose.

Défenses

Le papier lui-même termine sur des implications défensives. Ce qui suit est concret et actionnable dès aujourd’hui :

1. Cessez de mesurer les défenses IPI avec des seuls benchmarks statiques. Si l’éval de votre garde-fou est une liste fixe de chaînes d’attaque, reproduisez la boucle IterInject (ou son prédécesseur public AgentVigil) contre votre pile avant de livrer. Les chiffres d’ASR d’une éval statique seront inférieurs de 20 à 60 points à ce qu’un attaquant adaptatif atteint.

2. Contraignez la surface d’attention au niveau de l’agent, pas seulement du prompt. Réduisez la taille du bloc non fiable injecté dans le contexte (découpage, résumé via un modèle propre, ingestion en extraction structurée uniquement), maintenez les définitions d’outils et le prompt système dans un segment ou rôle séparé, et limitez la capacité par outil au strict nécessaire pour la tâche en cours. L’objectif est d’empêcher le contenu injecté d’accumuler assez de masse attentionnelle pour franchir le seuil identifié dans le papier.

3. Détectez au niveau de l’action. Des pots de miel sur les appels d’outils — faux outils, faux identifiants, paramètres en liste blanche — fournissent un signal de compromission propre, indépendant de l’analyse de l’intention en langue naturelle. Voir AgentShield (10 mai 2026) pour une instanciation publiée, et notre article sur les défenses par analyse des résultats d’outils pour des techniques complémentaires.

4. Considérez Claude Code (et équivalents) comme partie intégrante de votre surface d’attaque. Le résultat d’extension du papier n’est pas un bug spécifique à Claude Code ; c’est un optimiseur IPI générique appliqué à une cible aux défenses superposées avec un succès non négligeable. Traitez par défaut comme non fiables les contenus externes lus par votre agent de codage — issues, PR, README de dépendances, sorties d’outils — et conditionnez les actions destructrices à une confirmation humaine explicite.

5. Limitez le débit et journalisez la boucle de recherche. Un optimiseur IPI adaptatif est bruyant côté API : il génère de nombreux appels similaires sur une courte fenêtre, avec des signaux de succès monotones croissants. Une détection d’anomalies côté API sur la similarité des prompts, la diversité des appels d’outils et les motifs de relance par session est un contrôle secondaire bon marché, avant même de toucher au design de l’agent.

Statut

Élément	Référence	Date	Notes
Papier IterInject	arXiv 2605.24659	2026-05-23	Auteurs SJTU + HKU
Benchmark AgentDojo	spylab.ai / GitHub	en ligne	510 instances d’attaque, quatre suites ; utilisé par US/UK AISI
Benchmark InjecAgent	arXiv 2403.02691	2024-03	ASR total IterInject : 33–90 % sur quatre victimes
Expérience d’extension Claude Code	Même papier, §extension	2026-05-23	5 cibles sur 9 compromises
Travaux compagnons d’évaluation adversariale	The Attacker Moves Second, arXiv 2510.09023	2025-10	Même conclusion sur 12 défenses, côté jailbreak
Résultat sur l’Intégrité Contextuelle	arXiv 2605.17634	2026-05-17	Compagnon théorique : la séparation est le mauvais cadre

Le bon cadrage pour les équipes qui construisent n’est pas “encore un papier IPI”. C’est “une procédure de recherche automatisée se loge désormais entre votre garde-fou et un attaquant, et le plancher que cette recherche atteint monte chaque trimestre”. Ré-étalonnez vos évals IPI contre un optimiseur adaptatif, ou lisez la prochaine vague de chiffres de benchmark comme une description de votre propre agent de production.