Confusion de rôle : pourquoi les LLM obéissent au texte qui « fait » autorité
Un nouveau papier ICML 2026 du MIT défend l'idée que la prompt injection est en réalité une « confusion de rôle » : le modèle déduit qui parle du style du texte, pas de sa source. Du raisonnement falsifié atteint ~60 % de succès — et une réécriture quasi invisible fait tomber ce taux à 10 %.
De quoi s’agit-il ?
Prompt Injection as Role Confusion est un article de recherche signé Charles Ye, Jasmine Cui et Dylan Hadfield-Menell (MIT CSAIL, Algorithmic Alignment Group), publié sur arXiv sous la référence 2603.12277 et accepté à ICML 2026. Il a gagné en visibilité après que Simon Willison l’a relayé le 22 juin 2026. Le papier propose une explication mécaniste unique au fait que la prompt injection résiste depuis des années aux correctifs : les modèles ne savent pas de façon fiable qui parle.
Les LLM modernes encadrent le texte par des balises de rôle — <system>, <user>, <assistant> et des balises de raisonnement comme <think> — et sont entraînés à accorder une autorité différente à chaque rôle. La thèse centrale est dérangeante : le modèle décide à quel rôle appartient un fragment de texte en fonction de la manière dont il est écrit, pas de sa provenance réelle. Comme l’écrivent les auteurs, « la sécurité est définie à l’interface, mais l’autorité est attribuée dans l’espace latent ». Un texte non fiable qui imite le style d’un rôle privilégié peut hériter de l’autorité de ce rôle.
Comment ça marche
Les auteurs ont construit des « sondes de rôle » (role probes) — des classifieurs légers qui lisent les activations internes d’un modèle pour reconstituer sa propre perception de qui parle. À l’aide de ces sondes, ils montrent que le degré de confusion de rôle est mesurable avant même la génération du premier token, et que cette confusion interne prédit fortement le succès d’une injection.
L’attaque découle directement du diagnostic. On prend une requête interdite ordinaire placée dans le tour utilisateur, puis on y ajoute un texte dont le style imite le raisonnement interne ou les notes de politique du modèle — la cadence d’un bloc <think> affirmant une exception de politique (fabriquée). Pour un humain, ce texte ajouté n’est manifestement qu’une suite d’entrée utilisateur. Pour le modèle, il se lit comme un monologue interne privilégié : la requête hérite donc d’une autorité élevée et l’entraînement de sûreté est contourné. Le papier rapporte ce résultat sur des modèles à poids ouverts comme gpt-oss-20b, et sur un éventail de modèles à poids ouverts et fermés.
Aucun payload inédit n’est nécessaire pour comprendre le résultat ; nous n’en fournissons donc pas ici. C’est l’effet mesuré qui compte : l’injection d’un raisonnement falsifié atteint ~60 % de succès moyen sur StrongREJECT et 61 % sur une tâche d’exfiltration par agent, à partir de lignes de base proches de zéro.
Le revers de la médaille est le résultat le plus actionnable. Les auteurs testent le « destyling » : réécrire le texte non fiable pour qu’il se lise de la même façon pour un humain, mais qu’il ne corresponde plus au format attendu d’un rôle privilégié. Le résultat :
Le destyling fait chuter le succès moyen des attaques de 61 % à 10 % dans notre jeu de données. Un changement quasi invisible pour un humain bouleverse totalement la perception de rôle du LLM.
Pourquoi c’est important
Cela transforme la prompt injection, d’une liste d’astuces malignes, en une propriété structurelle du fonctionnement actuel des modèles. Si un modèle attribue l’autorité par le style, alors toute défense qui repose sur les balises de rôle ou les délimiteurs comme frontière de confiance est fragile par construction : un attaquant capable d’écrire « dans la bonne voix » peut promouvoir des données non fiables au rang de rôle de confiance. Cela explique aussi cette impression de jeu de taupe — corriger des formulations isolées ne touche pas au mécanisme sous-jacent.
L’enjeu est maximal pour les agents et le RAG, où le contenu non fiable (pages web, sorties d’outils, documents récupérés, e-mails) afflue dans la même fenêtre de contexte que les instructions système. Le résultat d’exfiltration montre que la confusion ne se limite pas aux refus en chat : elle atteint les pipelines outillés, où le coût d’un rôle détourné est un véritable déplacement de données. Les auteurs alertent aussi sur une menace plus subtile : des injections qui déplacent graduellement et « légalement » la perception de rôle du modèle via un texte d’apparence anodine, plutôt qu’une chaîne malveillante évidente.
Défenses
- Ne traitez pas les balises de rôle ou les délimiteurs comme une frontière de sécurité. La séparation
<system>/<user>est une convention d’interface, pas un mécanisme d’autorisation. Partez du principe que n’importe quel texte peut revendiquer n’importe quel rôle. - Normalisez / « destylez » les entrées non fiables avant qu’elles n’atteignent le modèle. Supprimez ou réécrivez le contenu qui imite le formatage système, raisonnement ou assistant (faux blocs
<think>, pseudo-notes de politique, mise en forme de résultats d’outils). À elle seule, cette mesure a fait passer le succès des attaques de 61 % à 10 % dans leur jeu de données. - Utilisez les sondes de rôle comme signal de détection. La confusion de rôle interne est mesurable avant la génération ; une mesure de forte confusion sur une requête est une alerte précoce permettant de la bloquer ou de l’escalader.
- Conservez des contrôles au niveau de l’architecture. La normalisation de style est une mitigation, pas une garantie. Combinez-la avec la séparation des privilèges et la discipline « trifecta létale » / « Agents Rule of Two » : limitez tout agent non supervisé à au plus deux parmi {données privées, contenu non fiable, communication externe}.
- Restreignez l’egress et le périmètre des outils de l’agent. Puisque l’impact démontré est l’exfiltration, mettez sur liste blanche les destinations sortantes et limitez les outils au moindre privilège, afin qu’un rôle détourné ne puisse pas aller loin.
- Filtrez les sorties autant que les entrées. Un contrôle de second étage sur les actions et les réponses limite les dégâts quand un rôle confus passe entre les mailles du filet.
Statut
| Élément | Détail |
|---|---|
| Papier | Prompt Injection as Role Confusion, arXiv:2603.12277 |
| Auteurs | Charles Ye, Jasmine Cui, Dylan Hadfield-Menell (MIT CSAIL) |
| Conférence | Accepté à ICML 2026 |
| Testé sur | Modèles à poids ouverts et fermés, dont gpt-oss-20b |
| Succès d’attaque | ~60 % StrongREJECT ; 61 % exfiltration par agent (base ≈ 0) |
| Défense destyling | Succès d’attaque 61 % → 10 % |
| Mise en lumière | Relais de Simon Willison, 22 juin 2026 |
À retenir : tant que les modèles n’atteignent pas une véritable perception de rôle — distinguer qui parle de comment le texte est écrit — les défenses contre la prompt injection bâties sur les balises de rôle continueront de perdre face à un texte rédigé dans la bonne voix. Le levier pratique aujourd’hui : normaliser les entrées non fiables pour qu’elles cessent d’usurper un rôle de confiance, et faire respecter l’autorité dans l’architecture plutôt que dans le prompt.