Arrêtez de fixer le prompt : détourner le raisonnement et la mémoire d'un agent
Un papier d'avril 2026, JailAgent, pousse un agent à des appels d'outils malveillants sans toucher au prompt utilisateur — en perturbant sa trajectoire de raisonnement et sa récupération mémoire. Le prompt n'a jamais été toute la surface d'attaque.
De quoi s’agit-il ?
La plupart des défenses contre l’injection de prompt reposent sur un postulat : le danger arrive par l’entrée. On étiquette le tour utilisateur, le document récupéré, la sortie d’outil ; on décide quels segments sont des « instructions » et lesquels sont des « données » ; on filtre les mauvais. Deux papiers récents de red teaming montrent que ce cadrage rate l’endroit où les agents modernes décident réellement de ce qu’ils vont faire.
Le 7 avril 2026, Yanxu Mao, Peipei Liu, Tiehan Cui et leurs co-auteurs ont publié Stop Fixating on Prompts: Reasoning Hijacking and Constraint Tightening for Red-Teaming LLM Agents (arXiv:2604.05549). Leur cadre, JailAgent, amène un agent à exécuter des actions malveillantes sans modifier le prompt utilisateur. Il agit sur la couche située sous le prompt : la trajectoire de raisonnement de l’agent et sa récupération mémoire.
JailAgent est le successeur d’UDora (arXiv:2503.01908, première version le 28 février 2025, dernière révision le 12 novembre 2025 ; Jiawei Zhang, Shuang Yang, Bo Li), qui a introduit l’idée centrale : un agent LLM « raisonne ou planifie abondamment avant d’exécuter ses actions finales », si bien que la trace de raisonnement elle-même est un point où un attaquant peut orienter le modèle. Ensemble, ces travaux délivrent un seul message aux défenseurs : la chaîne de raisonnement et la mémoire font partie de la surface d’attaque, et non d’internes neutres.
Comment ça marche
Cette section décrit la forme de la technique, pas une attaque exécutable. Aucun payload, aucune chaîne de déclenchement ni code d’optimisation n’est reproduit ici ; qui veut la méthode se reportera aux papiers.
Le mécanisme d’UDora, selon son résumé, est une boucle :
1. Exécuter l'agent sur la tâche et capturer sa trace de raisonnement.
2. Repérer dans cette trace les points où une petite perturbation
ferait basculer l'agent vers une action cible (malveillante).
3. Utiliser le raisonnement perturbé comme cible de substitution et optimiser.
4. Itérer jusqu'à ce que l'agent appelle l'outil / exécute l'action choisie.
On ne dit jamais à l’agent « ignore tes instructions ». On infléchit plutôt son propre raisonnement intermédiaire pour que l’appel d’outil nuisible apparaisse comme la suite naturelle vers laquelle le modèle se dirigeait déjà.
JailAgent (avril 2026) généralise cela et supprime entièrement la dépendance à des modifications de prompt. Ses trois étapes, selon les auteurs, sont :
- Trigger Extraction — localiser les indices, dans le contexte ou la mémoire, sur lesquels l’agent s’appuie pour décider d’agir.
- Reasoning Hijacking — orienter de façon adaptative et en temps réel la trajectoire de raisonnement vers l’objectif de l’attaquant, plutôt qu’avec un gabarit figé.
- Constraint Tightening — réduire l’espace des options de l’agent via une fonction objectif optimisée, de sorte que l’action non sûre devienne le chemin de moindre résistance.
Les auteurs rapportent que cela se transfère d’un modèle et d’un scénario à l’autre. Le mécanisme compte plus que tout chiffre isolé : parce que la manipulation vit dans le chemin raisonnement-mémoire, un garde-fou qui n’inspecte que le prompt peut valider l’entrée comme propre et regarder malgré tout l’agent passer à l’acte.
Pourquoi c’est important
Deux conséquences pratiques en découlent.
D’abord, les classifieurs d’entrée ne sont pas un contrôle complet. Une défense qui note le message utilisateur et le texte récupéré à la recherche de contenu « instructionnel » peut rendre un verdict propre alors que la compromission se produit pendant la planification. Cela rejoint les résultats théoriques de la saison — voir l’intégrité contextuelle et le flux de données n’est pas l’autorité — selon lesquels la séparation données/instructions ne peut pas être toute la réponse.
Ensuite, la mémoire est une surface d’attaque vivante. Quand un agent récupère une « expérience » passée pour planifier, des entrées mémoire empoisonnées ou façonnées par l’attaquant deviennent des déclencheurs, comme l’a montré, côté empoisonnement, le détournement d’outils par la mémoire. Un agent doté de mémoire à long terme transporte ses propres déclencheurs futurs.
Le risque se concentre là où les agents sont les plus utiles : les déploiements riches en outils, à effets de bord réels — envoyer du courrier, déplacer de l’argent, exécuter du code, appeler des API internes.
Défenses
On ne corrige pas « le modèle raisonne avant d’agir ». On peut rendre le raisonnement moins déterminant pour la sécurité.
- Contrôlez l’action, pas l’intention. Validez l’appel d’outil final au regard de la politique, indépendamment du chemin de raisonnement qui y a conduit. Un virement, une suppression, une requête sortante doivent passer un contrôle indépendant qui ne lit jamais la chaîne de raisonnement comme une autorité. C’est le cœur de la règle de deux et du cadrage par la triade létale.
- Moindre privilège sur les outils. Cantonnez chaque outil au strict minimum et exigez une approbation humaine explicite pour les actions à fort impact. Un raisonnement détourné se heurte tout de même à un mur si l’agent ne peut tout simplement pas invoquer la capacité dangereuse sans supervision.
- Traitez la mémoire comme une entrée non fiable. Validez, attribuez et segmentez la mémoire récupérée comme un document externe. Conservez la provenance de chaque entrée mémoire et expirez agressivement.
- Isolez la planification du contenu non fiable. N’autorisez pas le même contexte qui contient des données contrôlables par l’attaquant à piloter aussi la sélection d’outils. Les patterns dual-LLM / plan-then-execute tiennent le planificateur privilégié à l’écart du texte non fiable brut.
- Surveillez la trace, avec humilité. Des contrôles d’anomalie sur le raisonnement et la sélection d’outils peuvent attraper un pilotage grossier, mais le résultat d’impossibilité de l’intégrité contextuelle avertit que l’inspection de trace seule ne comblera pas l’écart. À utiliser comme détection en profondeur, pas comme contrôle unique.
État des lieux
| Élément | Référence | Date | Notes |
|---|---|---|---|
| UDora (détournement de trace de raisonnement) | arXiv:2503.01908 | 2025-02-28 → 2025-11-12 (v3) | Insère des perturbations dans le raisonnement de l’agent ; code public |
| JailAgent / Stop Fixating on Prompts | arXiv:2604.05549 | 2026-04-07 | Sans édition de prompt ; Trigger Extraction → Reasoning Hijacking → Constraint Tightening |
| Arrière-plan théorique | Intégrité contextuelle, panoramas sur les agents | 2026 | La séparation données/instructions a des limites dures |
Le titre n’est pas « un nouveau jailbreak ». C’est un déplacement du problème : pour les agents outillés, le prompt n’est qu’une entrée parmi d’autres, et la trace de raisonnement et la mémoire sont celles que votre filtre d’entrée ne voit jamais.