ChatInject : forger les balises de rôle du chat template pour contourner la hiérarchie d'instructions

De quoi s’agit-il ?

ChatInject est une technique d’injection de prompt indirecte qui détourne le chat template — les tokens de rôle spéciaux (<|system|>, <|user|>, <|assistant|>) avec lesquels les modèles segmentent un prompt en rôles. Au lieu de dissimuler une instruction en clair dans une sortie d’outil, l’attaquant y insère les balises de rôle du modèle, forgeant un rôle de priorité supérieure et amenant l’agent à traiter une donnée contrôlée par l’attaquant comme une instruction faisant autorité.

La méthode provient de « ChatInject: Abusing Chat Templates for Prompt Injection in LLM Agents », par Hwan Chang, Yonghyun Jun et Hwanhee Lee (Chung-Ang University), publié à la conférence ICLR 2026. La révision actuelle (arXiv:2509.22830v3) est datée du 13 avril 2026, avec le code sur la page projet et GitHub. Le sujet concerne directement quiconque déploie des agents outillés, car il vise le mécanisme même — la hiérarchie d’instructions — que les éditeurs ont conçu pour empêcher l’injection indirecte.

Comment ça marche

Les agents modernes sont entraînés à faire respecter un ordre de priorité par rôle : système > utilisateur > assistant > sortie d’outil. Cet ordre s’implémente via des tokens spéciaux qui marquent le début et la fin de chaque rôle. L’observation centrale de l’article : cette segmentation ne vaut que ce que vaut le canal qui la transporte — et la sortie d’outil est le canal le moins fiable de tous.

Lorsqu’un attaquant qui contrôle la valeur de retour d’un outil (page web, e-mail, fichier, réponse d’API) écrit les tokens de rôle du modèle dans cette valeur, le modèle peut relire les balises forgées et promouvoir le contenu encapsulé à un rôle de priorité supérieure. Une ligne banale du type « ignore les instructions précédentes », que l’agent écarterait normalement, devient — une fois enveloppée dans de fausses balises system/user — quelque chose que le modèle lit comme émanant de son opérateur.

Sortie d'outil (contrôlée par l'attaquant), schématiquement :

   <forged_system_tag> [préambule à l'air autoritaire]
   <forged_user_tag>   [INSTRUCTION DE L'ATTAQUANT — CAVIARDÉE]

L'agent interprète les balises forgées, attribue à tort le texte encapsulé
à un rôle privilégié, et l'exécute au lieu de le filtrer comme une donnée.

L’article définit quatre variantes de charge — texte brut, texte brut + enveloppe ChatInject, dialogue multi-tour brut, et multi-tour + ChatInject — ainsi que des « hooks » agentiques qui imitent les tokens de raisonnement <think> et d’appel d’outil <tool> d’un modèle. La variante la plus puissante fabrique une conversation multi-tour entière dans une seule sortie d’outil : un dialogue synthétique de 7 tours utilisateur/assistant (généré avec GPT-4.1) qui « justifie » progressivement l’action malveillante, de sorte que l’agent rencontre ce qui ressemble à un échange antérieur et consenti. Aucune interaction réelle n’est nécessaire ; la persuasion est forgée de toutes pièces. C’est l’équivalent en un seul coup d’un jailbreak multi-tour, passé clandestinement par un unique point d’injection.

Mesurée sur deux benchmarks standards (AgentDojo et InjecAgent) avec neuf modèles de pointe, l’enveloppe fait passer le taux de succès moyen (ASR) de 5,18 % à 32,05 % sur AgentDojo et de 15,13 % à 45,90 % sur InjecAgent ; la variante multi-tour + ChatInject atteint 52,33 % sur InjecAgent. Les charges sont aussi transférables : une enveloppe construite à partir du template d’un modèle fonctionne souvent sur un autre, y compris des modèles propriétaires (GPT-4o, Grok-3, Gemini-2.5-Pro) dont les templates ne sont pas publics, car beaucoup sont structurellement proches des templates open source répandus. Une charge « mixture-of-templates » qui regroupe plusieurs conventions de balises augmente les chances de tomber sur un backbone inconnu. Les modèles aux délimiteurs de rôle faibles (Grok-2) se sont révélés nettement plus résistants.

Pourquoi c’est important

ChatInject n’invente pas tant une capacité nouvelle qu’il n’expose une hypothèse porteuse. La hiérarchie d’instructions est la défense phare contre l’injection indirecte, et elle est appliquée dans la bande — avec des tokens qui vivent dans le même flux d’octets que les données non fiables. Toute frontière qu’un attaquant peut aussi écrire n’est pas une frontière.

Trois conséquences se détachent. D’abord, la transférabilité signifie qu’un attaquant n’a pas besoin de connaître votre modèle : une enveloppe générique ou un mélange de templates suffit à obtenir un ASR significatif contre des endpoints propriétaires. Ensuite, la variante multi-tour transforme l’injection de prompt — historiquement un problème en un seul coup — en problème de persuasion, important l’efficacité des jailbreaks conversationnels dans le canal des sorties d’outil. Enfin, et c’est le plus important pour les défenseurs : l’article montre que les défenses fondées sur le prompt sur lesquelles beaucoup d’équipes s’appuient ne tiennent pas, et que le correctif évident (retirer les balises de rôle) est mis en échec par de simples perturbations.

Défenses

L’enseignement impératif : aucun contrôle isolé « dans le contexte » n’est suffisant. Superposez les mesures suivantes.

1. Nettoyez et normalisez les tokens de rôle des sorties d’outil — mais n’en restez pas là. Supprimez ou échappez les tokens spéciaux de rôle/template dans toute donnée ingérée par l’agent, à la frontière parseur/tokenizer, et normalisez espaces et Unicode pour qu’une édition au niveau du caractère ne fasse pas passer une balise au travers d’un filtre littéral. L’article montre qu’altérer ~10 % des caractères met en échec un retrait par règles naïf : à traiter comme nécessaire, pas suffisant.

2. Séparez données et instructions au niveau de l’architecture. La cause racine est que le contenu d’outil partage un canal avec les instructions privilégiées. Privilégiez les conceptions qui maintiennent les données récupérées/d’outil dans une position structurellement distincte et non promouvable, plutôt que de se fier à des balises in-prompt que le modèle est entraîné à croire. Les modèles et harnais qui ne promeuvent jamais le contenu d’outil sont le correctif durable.

3. Verrouillez l’action, pas seulement le texte — moindre privilège. ChatInject ne compte que si l’agent compromis peut faire quelque chose de nuisible. Exigez des contrôles de politique explicites ou une confirmation humaine avant les appels d’outil à fort impact (envoyer de l’argent, publier, supprimer, exfiltrer), et restreignez les droits des outils. C’est la même logique que le lethal trifecta et la règle de deux des agents : si entrée non fiable, capacité sensible et exfiltration ne peuvent coexister, un ASR élevé au niveau du texte ne devient pas une compromission.

4. Ne comptez pas sur les seules mitigations par prompt. La répétition d’instruction utilisateur (sandwich), les prompts de prévention par instruction et le délimitage naïf se sont révélés largement inefficaces dans l’article — et ont parfois augmenté l’ASR. Gardez-les comme hygiène, jamais comme contrôle principal.

5. Utilisez les détecteurs en défense en profondeur, avec prudence. Des détecteurs externes (un détecteur PI DeBERTa, Lakera Guard) ont réduit l’ASR mais réagissaient surtout à la présence de tokens spéciaux, rataient la persuasion multi-tour contextuelle et provoquaient de forts taux de faux positifs ; leur mode d’échec grossier « supprimer toute la sortie d’outil » bloque l’agent. Réglez-les pour la rédaction plutôt que la suppression totale, et associez-les aux contrôles ci-dessus.

6. Retestez votre propre pile. Les benchmarks (AgentDojo, InjecAgent) et le code de l’attaque sont publics. Lancez des charges de type ChatInject contre votre modèle et votre famille de templates avant qu’un attaquant ne le fasse — et ne présumez pas qu’un modèle propriétaire est immunisé, la proximité de template avec les familles open source ayant largement porté le transfert inter-modèles.

Statut

Élément	Référence	Date	Notes
Article ChatInject (v3)	arXiv:2509.22830 [cs.CL]	2026-04-13	Publié à ICLR 2026
Benchmarks utilisés	AgentDojo, InjecAgent	—	Métriques ASR + utilité sous attaque
Modèles évalués	Qwen3, GPT-oss-120b, Llama-4, GLM-4.5, Kimi-K2, Grok-2 (open) ; GPT-4o, Grok-3, Gemini-2.5-Pro (closed)	—	Grok-2 le plus résistant (délimiteurs de rôle faibles)
Résultat principal	AgentDojo 5,18 %→32,05 % ASR ; InjecAgent 15,13 %→45,90 % ; multi-tour 52,33 %	—	Moyennes inter-modèles
Défenses testées	détecteur PI, Lakera Guard, prévention par instruction, délimiteurs de données, répétition d’instruction utilisateur	—	Défenses par prompt largement inefficaces ; retrait de balises contourné par perturbation
Code	page projet / GitHub	—	Public, à des fins d’évaluation

Le bon cadrage n’est pas « un chiffre de jailbreak de plus ». C’est que le délimiteur choisi par l’industrie pour marquer la confiance peut lui-même être écrit par l’attaquant, et que défendre des agents outillés impose de déplacer la frontière de confiance hors du prompt, vers l’action.