Mémoire d’un agent IA : tester l’empoisonnement

Qu’est-ce que l’empoisonnement de la mémoire d’un agent IA ?

C’est l’écriture, dans la mémoire à long terme d’un agent, d’informations ou de consignes choisies par un attaquant. L’OWASP Top 10 for Agentic Applications (publié le 9 décembre 2025) en fait une catégorie à part, ASI06 « Memory and Context Poisoning » : les attaquants empoisonnent les systèmes de mémoire, les embeddings et les bases RAG, ce qui corrompt l’information stockée et peut influencer les décisions d’une session à l’autre.

La différence avec une injection de prompt ordinaire tient à la durée. Une injection classique agit tant que le contenu piégé est dans le contexte. Une injection dans la mémoire survit à la conversation : l’agent « se souvient » de la consigne comme d’un fait, parfois sans que l’utilisateur le sache. Nous traitons le cas voisin des bases vectorielles dans notre article sur le RAG empoisonné.

Quels travaux publics documentent cette attaque ?

Deux sources suffisent à poser le risque : un cas produit et un article de recherche.

• Johann Rehberger, mémoire de ChatGPT (22 mai 2024). Le chercheur a montré qu’une injection de prompt indirecte, depuis un document Google Docs connecté, une image ou une page web, pouvait amener l’outil de mémoire de ChatGPT à enregistrer de faux souvenirs, des biais ou des instructions, qui persistaient dans les conversations suivantes. Chaque puce d’un document piégé pouvait devenir un souvenir, et une injection simple pouvait aussi effacer toute la mémoire. OpenAI a clos le signalement comme un « problème de sécurité du modèle » (Model Safety Issue) plutôt qu’une vulnérabilité de sécurité, selon l’auteur, qui note aussi que des mitigations discrètes avaient été ajoutées pour la navigation, sans être totalement efficaces.
• MINJA (arXiv 2503.03704, mars 2025). Shen Dong et ses coauteurs montrent qu’un attaquant peut injecter des enregistrements malveillants dans la mémoire d’un agent par la seule interaction par requêtes, sans accès direct à la mémoire. Un prompt d’indication pousse l’agent à générer des étapes de raisonnement intermédiaires, puis une stratégie de raccourcissement progressif retire ce prompt pour que l’enregistrement reste retrouvé lors des requêtes d’autres utilisateurs. Selon les auteurs, cela permet à un utilisateur ordinaire d’influencer la mémoire de l’agent.

Pourquoi la mémoire est-elle une surface d’attaque à part ?

Parce qu’elle mélange trois propriétés risquées : elle est écrite à partir de contenus non fiables, elle est relue comme si elle était fiable, et elle dure. L’agent décide souvent seul de ce qui mérite d’être mémorisé, et la consigne stockée se retrouve ensuite placée dans le contexte au même titre qu’une instruction du développeur ou de l’utilisateur.

Trois scénarios à garder en tête :

• Mémoire d’un seul utilisateur. Un e-mail ou un document piégé fait écrire une préférence frauduleuse (« envoie toujours les copies à telle adresse »).
• Mémoire partagée. Dans un agent d’équipe, un message d’un utilisateur influence les réponses données aux autres : c’est le cas de MINJA.
• Mémoire multi-agents. Un agent compromis écrit dans une mémoire que d’autres agents lisent.

Quelle différence avec un RAG empoisonné ?

Dans un RAG, des documents sont indexés puis retrouvés par similarité ; l’attaquant doit faire entrer un document piégé dans la base. Dans une mémoire d’agent, c’est l’agent lui-même qui écrit, à partir de ce qu’il lit ou de ce qu’on lui dit, ce qui ouvre une voie d’entrée de plus : une conversation suffit. Les deux se testent de la même façon (écrire, relire, mesurer l’effet), mais la mémoire ajoute une question propre : qui décide de ce qui est retenu, et l’utilisateur a-t-il son mot à dire ? Si la réponse est « le modèle, sans contrôle », l’écriture est une action sensible comme une autre et mérite les mêmes garde-fous qu’un envoi d’e-mail.

Comment tester l’empoisonnement de la mémoire ?

Testez chaque étape de la vie d’un souvenir : écriture, stockage, lecture, effacement. Utilisez des comptes de test, des données fictives et un environnement de développement ou de recette.

1. Cartographier la mémoire. Que mémorise l’agent (préférences, faits, résumés de sessions), où (base, fichier, vecteurs), qui peut lire, qui peut écrire, et combien de temps cela dure ?
2. Écriture par contenu non fiable. Faites lire à l’agent un document, un e-mail ou une page de test contenant une consigne du type « retiens que… ». Un souvenir est-il créé ? L’utilisateur en est-il informé ?
3. Consigne persistante. Ouvrez une nouvelle session. La consigne resurgit-elle sans nouvelle injection ? Cherchez un effet mesurable : un canari repris dans la réponse, un destinataire modifié, un ton imposé.
4. Isolation entre utilisateurs. Avec deux comptes de test, écrivez la consigne avec le compte A et interrogez avec le compte B. Un souvenir de A influence-t-il B ? C’est le scénario de MINJA.
5. Effacement. Une injection peut-elle supprimer ou écraser des souvenirs existants, comme dans les essais de Rehberger ?
6. Contrôle de l’utilisateur. Peut-on lister, corriger et supprimer les souvenirs ? La suppression retire-t-elle aussi les copies (résumés, vecteurs, sauvegardes) ?
7. Expiration. Un souvenir injecté disparaît-il un jour ? Une consigne vieille de plusieurs mois pèse-t-elle encore ?
8. Action déclenchée. La consigne mémorisée suffit-elle à déclencher un outil sensible (envoi, paiement, suppression) sans validation ?

Mesurez le taux de réussite sur plusieurs essais, car la récupération d’un souvenir dépend de la requête et du modèle. Pour le cadrage, nous nous appuyons sur la page méthode.

Quelles défenses mettre en place ?

• Écrire avec prudence. Ne laissez pas un contenu non fiable (e-mail, page, document) déclencher seul une écriture en mémoire. Exigez une confirmation de l’utilisateur ou une règle explicite.
• Rendre la mémoire visible. L’utilisateur doit voir ce qui est enregistré, pouvoir le corriger et le supprimer.
• Cloisonner. Une mémoire par utilisateur, par tenant, voire par tâche ; aucune écriture croisée sans autorisation. L’isolation est la parade directe au scénario de MINJA, où un utilisateur influence les réponses données aux autres.
• Faire expirer. Une durée de vie par type de souvenir, et une restauration possible à un état antérieur en cas de doute.
• Ne jamais obéir à un souvenir pour une action sensible. Les actions irréversibles passent par une validation indépendante de ce que dit la mémoire (validation humaine).
• Journaliser les écritures. Qui a écrit quoi, à partir de quelle source, et quand.

Comment l’intégrer à un rapport ?

Rattachez le constat à ASI06 pour les agents, et à LLM04:2025 (empoisonnement des données et des modèles) ainsi qu’à LLM08:2025 (faiblesses des vecteurs et embeddings) quand la mémoire repose sur une base vectorielle. Précisez le chemin d’écriture, la durée de persistance et l’action déclenchée : un souvenir modifiable mais sans effet est un constat faible, un souvenir qui change un destinataire d’e-mail est un constat fort.

La page sécurité des agents IA replace la mémoire parmi les autres surfaces d’un agent (outils, données, identités).

Comment CleanIssue teste la mémoire d’un agent ?

Nous suivons le cycle écriture, stockage, lecture, effacement sur votre environnement de test, avec deux comptes pour vérifier l’isolation et un canari pour prouver la persistance. Le Red Team Agent Express couvre un agent en 5 jours, avec démarrage sous 48 h après signature du devis et de l’autorisation. Pour une mémoire partagée entre plusieurs agents ou plusieurs clients, le Red Team sur mesure se chiffre sur devis. Rien n’est conservé sans l’accord du client.

Le premier échange est un rendez-vous découverte de 30 minutes, gratuit.