Empoisonner une fois, exploiter pour toujours : poisoning persistant de la mémoire des agents LLM (OWASP ASI06)
Un papier arXiv d'avril 2026 sur le memory poisoning inter-sites et un post OWASP du 13 mai 2026 sur la découverte MemoryTrap de Cisco contre Claude Code convergent vers le même constat : la mémoire d'agent est une frontière de confiance.
What is this?
Trois publications, en avril et mai 2026, ont transformé l’empoisonnement de la mémoire d’agent d’inquiétude théorique en classe d’attaque documentée avec une étiquette équivalente à un CVE. L’OWASP Gen AI Security Project l’a formalisé sous le nom ASI06 : Memory & Context Poisoning dans son Top 10 for Agentic Applications 2026. Le 13 mai 2026, Idan Habler, co-pilote de l’entrée ASI06 chez Cisco, a publié Memory Is a Feature. It Is Also an Attack Surface sur le blog OWASP, en articulant la catégorie autour d’une découverte concrète de Cisco — MemoryTrap — contre Claude Code, divulguée le 1ᵉʳ avril 2026 et corrigée par Anthropic dans Claude Code v2.1.50. Deux jours plus tôt, le 3 avril 2026 (révision du 7 avril), Wei Zou et ses coauteurs chez Amazon AWS publiaient Poison Once, Exploit Forever: Environment-Injected Memory Poisoning Attacks on Web Agents sur arXiv (2604.02623, cs.CR), démontrant la même classe d’attaque contre les navigateurs agentiques — OpenClaw, ChatGPT Atlas, Perplexity Comet — sans aucun accès direct à la mémoire.
La thèse commune aux trois sources est simple : un agent qui retient du contexte est un agent dont le passé est devenu une partie de son plan de contrôle actuel. Une fois qu’un attaquant écrit dans ce passé, chaque session future hérite de la compromission. La vague de recherche 2026 montre que ce n’est pas un cas marginal.
How it works
La mémoire des agents LLM actuels vit dans plusieurs endroits qui paraissent tous anodins du point de vue du développeur — un fichier memory.json, un vector store de trajectoires passées, un CLAUDE.md ou SKILL.md, une configuration globale de hooks, un cache de conversation résumée. L’objectif de l’attaquant est de déposer des tokens qu’il contrôle dans n’importe laquelle de ces surfaces, de telle sorte que le runtime les considère comme dignes de confiance lors d’un tour ultérieur.
Trois patterns d’attaque récents illustrent la surface.
MemoryTrap (Cisco, 1ᵉʳ avril 2026). Un utilisateur clone un dépôt et demande à Claude Code de le configurer. Claude propose proactivement d’installer les paquets npm requis ; le script postinstall malveillant écrit un payload dans le fichier de mémoire persistante de l’utilisateur, dans la configuration globale des hooks, et — avant le patch — dans une couche que l’agent chargeait directement dans son system prompt. À la session suivante, sur un autre projet, l’agent fait toujours confiance à ce texte comme si Anthropic l’avait livré. Le correctif d’Anthropic dans Claude Code v2.1.50 retire les user memories du system prompt, fermant le chemin à plus haute confiance ; la classe d’attaque, elle, reste ouverte.
eTAMP / Poison Once, Exploit Forever (Amazon AWS, 3 avril 2026). Modèle de menace plus fort : l’attaquant n’a aucun accès à la mémoire. Il modifie une seule observation dans l’environnement — une fiche produit, un fil de forum, un faux message d’erreur — que l’agent web se contente de consulter. L’agent stocke cette trajectoire comme une mémoire utile « voici comment se passe ce type de tâche » puis, sur un autre site dans une session future, il la récupère. Les taux de succès atteignent 32,5 % sur GPT-5-mini, 23,4 % sur GPT-5.2, 19,5 % sur GPT-OSS-120B sur (Visual)WebArena. Un résultat secondaire — la Frustration Exploitation — multiplie le taux de succès jusqu’à 8x quand l’agent peine déjà avec des clics manqués ou une UI dégradée. Les modèles les plus capables ne sont pas plus sûrs.
MINJA (arXiv 2503.03704, mars 2025). Le résultat séminal antérieur, conservé ici parce qu’il reste la démonstration la plus propre : un utilisateur ordinaire, par ses seules requêtes, pousse l’agent à écrire une mémoire pont qui relie ses futures requêtes bénignes à des étapes de raisonnement choisies par l’attaquant. Rapporté à 98,2 % de réussite d’injection, 76,8 % d’attaque downstream dans le modèle de menace du papier.
Layer Where it lives Trust assumed by runtime
------------------- ------------------------------ ----------------------------
Persistent memory memory.json, vector store Treated as past first-party
System-prompt CLAUDE.md / user memories Loaded high-authority
Hooks / config global hooks, shell profiles Executed silently
Retrieved context RAG store, summaries Mixed into next prompt
Why it matters
Trois propriétés rendent cette classe d’attaque plus difficile que le prompt injection classique.
D’abord, la persistance. Une injection standard meurt avec la session. Une injection mémoire survit jusqu’à un nettoyage manuel du store — pour lequel il existe rarement une UI. Le papier eTAMP montre que l’activation peut survenir sur un autre site, plusieurs jours plus tard — exactement le type de fuite inter-contextes que les défenses par permissions n’ont jamais été conçues pour attraper.
Ensuite, le blanchiment de confiance. Le runtime ne distingue pas facilement la mémoire écrite par l’attaquant de la mémoire écrite par l’utilisateur. Les deux arrivent par le même chemin d’écriture ; les deux ressemblent à du contexte first-party à la lecture. C’est précisément la critique structurelle qui sous-tend ASI06 : les stacks agentiques séparent déjà prompts développeurs et entrée utilisateur, mais n’ont pas d’équivalent pour les écritures mémoire.
Enfin, la surface d’attaque suit la capacité. La mémoire devient une feature standard dans chaque produit agentique majeur — Claude Code, ChatGPT memories, les nouveaux « browser agents » (OpenClaw, ChatGPT Atlas, Perplexity Comet) étudiés dans le papier eTAMP. Chaque nouvelle surface mémoire est une nouvelle ligne dans la frontière de confiance que les défenseurs peuvent ignorer.
Defenses
ASI06 est suffisamment récent pour qu’aucune mitigation seule ne ferme la classe. La liste défensive la plus courte, tirée de l’entrée OWASP et des trois papiers ci-dessus :
- Traiter les écritures mémoire comme non fiables par défaut. La décision de confiance ne doit pas se prendre à l’écriture mais à la lecture, avec un runtime capable de tagger la provenance de chaque entrée (issue de l’utilisateur, d’un tool, d’une observation environnementale) et une politique qui décide ce qui peut migrer vers un contexte à haute autorité.
- Sortir les user memories du system prompt. C’est le correctif spécifique livré par Anthropic dans Claude Code v2.1.50. La mémoire peut continuer à informer le modèle, sans pour autant siéger dans la même couche que les règles et le rôle de l’agent.
- Mettre en quarantaine les observations issues de l’environnement. Distinguer ce que l’agent a vu de ce que l’agent a décidé de retenir. Tagger les observations par URL/domaine source ; ne jamais laisser une observation issue de
example-shop.cominfluencer le comportement surexample-bank.com. - Rendre les écritures mémoire auditables. Un journal mémoire diffable — visible par l’utilisateur, signable par le runtime — transforme un canal de persistance silencieux en canal vérifiable. Le projet OWASP Agent Memory Guard est la piste d’implémentation de référence sur ce contrôle.
- Limiter et passer en revue les écritures de hooks. Le chemin MemoryTrap passait par les hooks globaux et
npm postinstall. Une écriture de hook par l’agent devrait exiger une confirmation humaine explicite, et le system prompt ne devrait jamais charger en aveugle des fichiers de hooks écrits pendant la même session. - Tester les fuites inter-sessions et inter-sites. Les suites de régression standard pour le prompt injection s’arrêtent à la frontière de session. Les suites conscientes d’ASI06 doivent exécuter une attaque en session N et vérifier l’activation en session N+k sur une autre surface.
- Plafonner le rayon d’impact via la portée des capacités. Même quand une mémoire empoisonnée gagne à la lecture, une exécution bornée par les capacités — ACL par skill, pas de credentials ambiants, whitelist de sortie — limite ce que l’attaquant peut en faire.
Status
| Item | Référence | Date | Notes |
|---|---|---|---|
| Post de cadrage OWASP | OWASP Gen AI Security Project | 2026-05-13 | Idan Habler (Cisco), co-lead de l’entrée ASI06 |
| Papier eTAMP | arXiv:2604.02623 v2 | 2026-04-07 | jusqu’à 32,5 % d’ASR sur GPT-5-mini, inter-sites |
| Divulgation MemoryTrap | Cisco AI Blog | 2026-04-01 | corrigé dans Claude Code v2.1.50 |
| Papier MINJA | arXiv:2503.03704 | 2025-03 | 98,2 % d’injection / 76,8 % d’attaque |
| Interview Habler | Help Net Security | 2026-04-14 | Agentic AI memory attacks spread across sessions and users |
| Catégorie | OWASP Top 10 for Agentic Apps | 2025-12 → 2026 | ASI06 : Memory & Context Poisoning |
La mémoire, c’est ce qui rend un agent personnel. C’est aussi ce qui fait survivre une seule mauvaise observation à la session où elle a atterri. Les publications d’avril et mai 2026 ci-dessus n’inventent pas une attaque inédite — elles rendent explicite le coût d’en ignorer une ancienne.
Sources
- → https://arxiv.org/abs/2604.02623
- → https://arxiv.org/html/2604.02623v2
- → https://genai.owasp.org/2026/05/13/memory-is-a-feature-it-is-also-an-attack-surface/
- → https://blogs.cisco.com/ai/identifying-and-remediating-a-persistent-memory-compromise-in-claude-code
- → https://arxiv.org/abs/2503.03704
- → https://www.helpnetsecurity.com/2026/04/14/idan-habler-cisco-agentic-ai-memory-attacks/