Attaques par flux de contrôle mémoire : quand la mémoire pilote les outils d'un agent

De quoi s’agit-il ?

Le 16 mars 2026, Zhenlin Xu, Xiaogang Zhu, Yu Yao, Minhui Xue et Yiliao Song ont publié From Storage to Steering: Memory Control Flow Attacks on LLM Agents (arXiv:2603.15125, cs.CR). Le papier nomme une classe d’attaque que les auteurs appellent Memory Control Flow Attacks (MCFA) — attaques par flux de contrôle mémoire.

La plupart des travaux publiés sur la mémoire des agents — dont les cas traités dans l’empoisonnement de mémoire d’agent (ASI06) et MemMorph — abordent la mémoire empoisonnée comme un problème de contenu : l’agent récupère un fait erroné et produit une mauvaise réponse. MCFA recadre la menace. Les auteurs montrent que la mémoire récupérée agit comme une entrée de contrôle : elle ne change pas seulement ce que l’agent dit, elle change quels outils l’agent appelle et dans quel ordre — même lorsque l’utilisateur donne des instructions explicites et sûres. La mémoire devient, selon leur formule, un « signal de contrôle écrit une fois, lu plusieurs fois ».

Comment ça marche

Un agent doté de mémoire exécute une boucle : Lire la mémoire → Planifier la séquence d’outils → Exécuter → Écrire une nouvelle mémoire. MCFA cible le lien Lire→Planifier. L’attaquant n’a besoin d’aucun privilège interne : il ne peut ni modifier le system prompt, ni changer le code des outils, ni toucher directement au magasin de mémoire, ni installer d’outils. Il interagit simplement normalement avec l’agent et, en une ou quelques conversations, lui fait stocker une « préférence » ou une « règle » orientée action en mémoire à long terme. Plus tard, lors d’une tâche bénigne sans rapport, cette mémoire est récupérée et oriente la trace d’outils.

Le papier formalise cinq familles d’attaque (aucun payload exploitable n’est reproduit ici — voir l’annexe du papier pour le protocole) :

Famille       Effet sur la trace d'appels d'outils
------------  -------------------------------------------------------------
Override      Une "préférence" récupérée force un outil risqué/non voulu
              dans la trace, contournant les filtres de sécurité statiques.
Order         Des étapes sont réordonnées ou sautées — ex. une étape Audit
              requise est contournée avant une étape Transfer. Invisible
              pour les défenses par liste blanche, qui ne vérifient que
              *quels* outils, pas l'ordre.
M-Scope       La règle injectée se généralise à des tâches sans rapport,
              agissant comme une "clé maîtresse" inter-domaines.
Persistence   La déviation continue de se déclencher longtemps après
              l'injection, sans réinjection.
Relapse       Les instructions explicites "arrête / corrige" échouent ;
              l'état mémoire empoisonné résiste à la correction textuelle.

Pour mesurer cela à grande échelle, les auteurs ont construit MemFlow, un cadre automatisé qui opérationnalise chaque attaque en injecter une mémoire malveillante → la récupérer pendant des tâches bénignes → auditer les déviations de flux de contrôle. Ils l’ont exécuté contre GPT-5 mini, Claude Sonnet 4.5 et Gemini 2.5 Flash, avec des outils réels de LangChain et LlamaIndex.

Pourquoi c’est important

Les chiffres sont élevés et constants d’un modèle à l’autre. Plus de 90 % des essais étaient vulnérables au MCFA, même sous contraintes de sécurité strictes. Les overrides de choix d’outil apparaissaient dans 91,7–100 % des essais, le réordonnancement de workflow dans 52,8–69,4 %, l’expansion de portée inter-tâches dans 97,2–100 %, avec une persistance de 100 % observée sur les horizons longs.

Deux propriétés rendent cela pire qu’une injection de prompt ponctuelle. D’abord, la persistance et la portée inter-tâches : une seule interaction d’empoisonnement continue d’orienter des tâches futures et sans rapport — l’utilisateur qui déclenche le mauvais comportement n’est pas forcément celui qui l’a planté. Ensuite, la famille Order défait la logique de liste blanche. Beaucoup de garde-fous en production vérifient si un outil peut s’exécuter ; MCFA réordonne ou saute des outils légitimes et autorisés (sauter l’audit, puis transférer), de sorte que chaque appel pris isolément paraît permis. C’est le problème de la trifecta létale déplacé dans le planificateur : du contenu non fiable qui atteint la mémoire influence désormais la sélection d’actions, pas seulement la sortie.

La frontière de confiance à retenir : tout ce qu’une partie externe peut faire écrire en mémoire à long terme doit être traité comme une entrée contrôlable par l’attaquant pour le planificateur — et non comme un état utilisateur de confiance.

Défenses

Les auteurs testent une mitigation de type production et précisent explicitement qu’elle n’est pas une solution miracle : plus de la moitié des scénarios évalués présentaient encore plus de 85 % de déviation de flux de contrôle après son application. La défense est ici en couches, pas un interrupteur unique.

1. Ségrégation de mémoire par rôle (RBMS). La mitigation du papier : séparer les règles système des préférences utilisateur dans des canaux distincts et imposer une hiérarchie de priorité explicite, pour que la mémoire utilisateur accessible à l’attaquant ne puisse jamais primer sur la politique système. Elle réduit le succès des attaques mais ne l’élimine pas — à considérer comme un plancher, pas un plafond.

2. Faire du flux de contrôle un objet de politique, pas un produit émergent. Définissez l’ordre d’outils requis pour les workflows sensibles (ex. Audit doit précéder Transfer) et imposez-le de façon déterministe en dehors du modèle. La famille Order est invisible pour les listes blanches précisément parce que celles-ci ignorent la séquence et les dépendances.

3. Traiter la mémoire récupérée comme non fiable au moment de la récupération. Appliquez des étiquettes de provenance aux entrées mémoire (qui/quoi a écrit ceci, depuis quel canal) et refusez que des mémoires du canal utilisateur introduisent ou réordonnent des outils dans les traces critiques. Couplez avec des contrôles de cohérence entre mémoires liées, comme dans A-MemGuard et les patterns du guide OWASP sur la mémoire des agents.

4. Auditer la trace, pas seulement la sortie. Le MCFA est défini comme une déviation auditable dans la trace d’appels d’outils. Journalisez la séquence complète d’outils par tâche et alertez sur les traces qui violent les dépendances déclarées ou incluent des outils risqués — c’est observable même quand la réponse finale paraît correcte.

5. Tester la persistance et la rechute. Comme un comportement corrigé peut rechuter, les tests de sécurité doivent injecter, puis exécuter des tâches ultérieures et sans rapport et vérifier que la déviation a réellement disparu — pas seulement qu’elle est absente au tour suivant. Des benchmarks comme AgentDojo offrent un point de départ pour l’évaluation au niveau trace.

Statut

Élément	Référence	Date	Notes
Papier MCFA / MemFlow	arXiv:2603.15125	2026-03-16	Définit MCFA, 5 familles d’attaque, cadre MemFlow
Modèles évalués	Papier §4	2026-03-16	GPT-5 mini, Claude Sonnet 4.5, Gemini 2.5 Flash
Frameworks testés	LangChain, LlamaIndex	2026-03-16	Outils réels, pas des mocks
Mitigation (RBMS)	Papier §4.5	2026-03-16	Réduit l’ASR ; >85 % de déviation encore dans >la moitié des scénarios
Défense liée	A-MemGuard, arXiv:2510.02373	2025-10	Validation par consensus + mémoire de « leçons »

C’est un résultat de recherche, pas un CVE ni un incident en conditions réelles : il n’y a pas de correctif éditeur à installer. L’enseignement actionnable est architectural — si vous déployez un agent avec mémoire persistante et usage d’outils, partez du principe que des parties externes peuvent y planter des signaux de contrôle, et placez le flux de contrôle des workflows sensibles sous une politique déterministe que vous maîtrisez plutôt que sous le planificateur du modèle.