Bad Memory : l'injection qui persiste dans les fichiers mémoire des agents de code

De quoi s’agit-il ?

Le 16 juillet 2026, Soham Gadgil, David Alexander, Sai Sunku et Franziska Roesner (Université de Washington) ont publié Bad Memory: Evaluating Prompt Injection Risks from Memory in Agentic Systems sur arXiv. L’article mesure une surface d’attaque de plus en plus répandue : les fichiers mémoire en texte clair que les agents de code lisent comme un contexte de confiance — les fichiers d’instructions chargés automatiquement comme CLAUDE.md (Claude Code) et AGENTS.md (Codex), ainsi que les fichiers de comportement et de connaissances référencés comme core/behaviors.md et knowledge/*.md.

Les auteurs mènent leurs expériences dans un espace de travail synthétique isolé, contre deux systèmes agentiques de production — Claude Code et OpenAI Codex — et quatre modèles (Claude Opus 4.7, Claude Haiku 4.5, GPT-5.2, GPT-5.5). Chaque condition est répétée sur 10 essais. Le résultat principal : s’il est difficile de faire écrire du contenu malveillant à un agent dans sa propre mémoire à partir d’une entrée externe non fiable, une charge déjà présente dans un fichier mémoire oriente de manière fiable la session en cours, se redéclenche souvent lors de sessions ultérieures, et reste fréquemment dans le fichier ensuite. L’équipe indique avoir signalé ses conclusions à Anthropic et OpenAI en même temps que la publication.

Comment ça marche

L’injection indirecte classique ressemble à un XSS réfléchi : une instruction malveillante se cache dans un contenu que l’agent lit une fois (une page web, un ticket, un fichier) et agit le temps de ce seul tour. Le cadre proposé par l’article est que l’injection basée sur la mémoire ressemble à un XSS stocké — l’instruction est écrite dans un état persistant et peut affecter toute session future qui la charge.

Le modèle de menace est volontairement étroit et réaliste. L’adversaire contrôle le contenu d’un fichier persistant de l’espace de travail que l’agent peut charger comme contexte, mais ne contrôle pas le modèle, le harnais, ni le prompt de l’utilisateur. La façon dont le fichier empoisonné arrive est considérée hors périmètre — le scénario plausible est un développeur qui copie-colle un CLAUDE.md / AGENTS.md « partagé » ou « prêt à l’emploi » depuis un forum ou un dépôt public non fiable, autrement dit un problème de chaîne d’approvisionnement de configuration. Comme ces fichiers sont traités comme s’ils avaient été rédigés par l’utilisateur, l’instruction plantée est chargée automatiquement au démarrage de la session (pour les fichiers racine) ou lorsque l’agent juge un fichier référencé pertinent, puis influence une tâche par ailleurs légitime.

Trois propriétés aggravent la situation par rapport à une injection unique. D’abord la persistance : la charge survit d’une session à l’autre. Ensuite l’effet cumulatif : une fois que l’agent a produit des artefacts cohérents avec la charge — par exemple du code qui lit déjà un identifiant — une session ultérieure le considère comme normal et se méfie moins. Enfin l’accumulation : plusieurs charges indépendantes peuvent s’empiler dans la mémoire au fil du temps. L’étude a testé trois objectifs d’attaquant — exfiltration d’identifiants, installation non autorisée d’une dépendance vulnérable connue, et promotion de marque dissimulée — chacun associé à un type de fichier différent. Aucune charge n’est reproduite ici ; le mécanisme ci-dessus est le résultat conceptuel, et les auteurs fournissent un artefact isolé permettant aux défenseurs de reproduire l’évaluation.

Pourquoi c’est important

Deux chiffres reconfigurent la façon de penser la mémoire des agents. Le taux de réussite variait fortement selon le modèle et l’objectif — la réussite moyenne au premier essai allait d’environ 23 % (GPT-5.2) à 63 % (Haiku 4.5), et certaines cellules atteignaient 100 % (par exemple l’usage d’outil non autorisé sur Haiku, et le ciblage de marque sur GPT-5.5). Mais le constat le plus dérangeant est l’écart entre détecter et nettoyer.

Persistance et réussite ne coïncident pas. Claude Opus 4.7 affichait l’un des taux de réussite moyens les plus faibles, mais la persistance de charge la plus élevée (~97 %) : il reconnaissait souvent une instruction comme dangereuse, refusait d’agir, puis la laissait dans le fichier mémoire. C’est la combinaison dangereuse, car l’article note que les utilisateurs rétrogradent souvent vers un modèle moins cher et moins robuste à l’approche d’une limite de tokens — et ce modèle plus faible est justement celui qui a le plus de chances d’obéir à la charge que le modèle plus fort avait refusée. Un refus qui laisse le poison en place n’est pas un correctif ; c’est un report vers votre modèle le moins capable.

L’étude montre aussi des effets d’ordre : refuser une première attaque rendait les modèles plus méfiants face à une seconde, tandis que réussir la première baissait leur garde. Cela compte, car de vrais fichiers mémoire évoluent au fil de nombreuses sessions, pas d’une seule.

Défenses

L’article est une évaluation défensive, et ses recommandations se traduisent en contrôles concrets :

1. Cesser de traiter la mémoire persistante comme uniformément fiable. Les systèmes agentiques doivent distinguer les vraies préférences de l’utilisateur du contenu externe récupéré ou partagé. Un fichier venu d’un dépôt ou d’un forum ne devrait pas avoir la même autorité qu’une instruction saisie par l’utilisateur cette session-ci. C’est la même confusion d’autorité que derrière l’empoisonnement de la mémoire des agents (ASI06).

2. Soumettre les fichiers mémoire à fort impact à une revue explicite. Les modifications de CLAUDE.md, AGENTS.md et des fichiers de comportement universels devraient exiger que l’utilisateur voie et approuve un diff, plutôt que d’être chargées ou mises à jour en silence.

3. Hiérarchiser la mémoire par niveau de confiance. Séparez la mémoire en paliers de politique afin que les fichiers de connaissances peu fiables fournissent des faits mais ne puissent pas outrepasser les règles de sécurité ni les contraintes comportementales globales. Une note de préférences techniques ne devrait jamais pouvoir autoriser la lecture d’un identifiant.

4. Valider la mémoire au début de chaque session, et supprimer réellement ce qui est signalé. Le résultat sur la persistance est la leçon clé : détecter sans supprimer ne sert à rien lorsqu’une session ultérieure peut tourner sur un modèle plus faible. Si l’agent identifie une instruction plantée comme malveillante, la remédiation doit la retirer du fichier, pas seulement refuser de la suivre cette fois-ci.

5. Écarter les secrets de l’espace de travail. Les charges d’exfiltration d’identifiants ne paient que si les identifiants sont accessibles. Gardez les clés d’API et les identifiants cloud dans un gestionnaire, hors de l’environnement dans lequel l’agent opère — la même leçon que le trio létal.

6. Traiter les configs d’agent partagées comme des dépendances non fiables. Un CLAUDE.md ou AGENTS.md récupéré sur internet mérite la même vigilance qu’un paquet non audité. Lisez-le avant de le déposer dans un projet.

Statut

Élément	Référence	Date	Notes
Article Bad Memory (arXiv 2607.14611)	arXiv	2026-07-16	Claude Code + Codex ; 4 modèles ; 10 essais/condition
Systèmes / modèles testés	arXiv	2026-07-16	Claude Opus 4.7, Claude Haiku 4.5, GPT-5.2, GPT-5.5
Plage de réussite au premier essai	arXiv	2026-07-16	~23 % (GPT-5.2) à ~63 % (Haiku 4.5) ; plusieurs cellules à 100 %
Écart de persistance	arXiv	2026-07-16	Opus 4.7 : réussite la plus faible mais ~97 % de persistance
Divulgation responsable	arXiv	2026-07-16	Signalé à Anthropic et OpenAI en même temps que la publication
Artefact de reproduction	anonymous.4open.science	2026-07	Bac à sable + harnais ASR/persistance multi-sessions

La bonne lecture n’est pas « les agents de code sont cassés ». C’est qu’un fichier mémoire est un état persistant, privilégié et inter-sessions — et que les agents actuels vont le lire, parfois lui obéir, et souvent ne pas le nettoyer. Si votre flux de travail partage ou réutilise des fichiers CLAUDE.md/AGENTS.md, traitez-les comme du code que l’on relit, pas comme des notes que l’on croit sur parole.