Une étude COLM montre qu'une interaction peut empoisonner la mémoire d'un agent IA

Des chercheurs ont montré qu'une seule interaction peut inscrire une instruction persistante dans la mémoire d'un agent IA et influencer des réponses ultérieures sur le même sujet. Soumise le 24 août 2026 et acceptée à COLM 2026, l'étude InjecMEM considère la mémoire comme une frontière de sécurité, et non comme une simple fonction de confort.

Ce résultat ne signifie pas que tous les agents dotés de mémoire sont vulnérables. Les expériences portent principalement sur MemoryOS et incluent aussi MemGPT, plusieurs familles de modèles ouverts et une sortie cible contrôlée sans effet opérationnel. L'attaque la plus performante suppose également un accès au modèle sous-jacent pour l'optimisation. Dans ces limites, l'étude met en évidence un risque concret : un attaquant peut ne pas avoir besoin d'accéder directement à la base de données pour empoisonner l'état durable d'un agent.

Fonctionnement de l'attaque InjecMEM

De nombreux agents enregistrent des interactions, récupèrent ensuite les entrées pertinentes et les placent dans un prompt ultérieur. InjecMEM vise les deux parties de cette boucle.

L'attaquant envoie d'abord une interaction conçue avec une ancre thématique. Cette ancre contient des indices suffisamment larges pour que le système de mémoire associe l'enregistrement à un sujet cible, par exemple la santé ou la finance. L'interaction contient ensuite une commande malveillante optimisée pour rester efficace à différentes positions dans un prompt long et changeant.

Lorsqu'un utilisateur pose plus tard une question bénigne sur le sujet cible, le système peut récupérer l'enregistrement empoisonné. Si la récupération réussit, la commande peut orienter le modèle vers une sortie prédéfinie. L'attaquant n'a pas besoin de lire ni de modifier directement le magasin de mémoire.

L'étude décrit aussi une voie indirecte. Un outil compromis pourrait renvoyer un texte malveillant que l'agent enregistre en mémoire. Corriger l'outil ne supprimerait pas automatiquement l'entrée stockée.

Résultats des expériences

Les auteurs distinguent la réussite de la récupération et celle de la génération. Le taux de récupération indique si l'entrée empoisonnée réapparaît lors d'une question ultérieure liée au sujet. Le succès conditionnel indique si le modèle produit la sortie cible après cette récupération.

Il s'agit de résultats de recherche, pas de taux d'incident en production. La sortie cible était volontairement non opérationnelle. L'attaque restait efficace avec l'accumulation de souvenirs bénins et se transférait dans certaines familles. Le transfert entre familles était moins fiable. Une commande optimisée sur Qwen et Mistral n'a pas fonctionné sur un modèle Llama non vu, mais la concaténation de commandes a produit un succès mesurable sur les trois familles évaluées.

Les chercheurs ont aussi testé des filtres à la récupération. Un juge LLM, ProtectAI et PromptGuard ont parfois réduit la récupération, mais le succès conditionnel est resté proche du niveau sans défense. Un filtre de perplexité a supprimé l'attaque, au prix du blocage de 71,8 % des pages bénignes. Le filtrage seul peut donc rendre la mémoire inutilisable sans résoudre le problème de confiance.

Pourquoi la mémoire persistante change le modèle de sécurité

Une injection de prompt classique peut n'affecter qu'une réponse. Une mémoire empoisonnée peut réapparaître bien plus tard, lorsque l'opérateur a oublié l'interaction initiale. Elle peut aussi atteindre un autre processus si la mémoire est partagée entre tâches, utilisateurs ou agents.

OWASP identifie séparément l'empoisonnement de la mémoire et du contexte comme un risque des applications agentiques. Ses recommandations traitent le contexte stocké, les résumés, les hooks et la configuration locale comme un état sensible, car ils peuvent influencer la planification et l'utilisation d'outils. Ce modèle de menace plus large soutient la préoccupation de l'étude, mais ne reproduit pas indépendamment les pourcentages d'InjecMEM.

Pour les équipes qui exploitent des agents outillés, la conséquence dépasse une mauvaise réponse. Une instruction récupérée peut influencer l'API appelée, les données divulguées ou l'alignement d'une action ultérieure avec la tâche de l'utilisateur. Le guide Maetra sur les contrôles contre l'injection de prompt explique pourquoi l'inspection du contenu doit être associée à une autorité limitée sur les effets externes.

Six contrôles à examiner maintenant

1. Traiter chaque écriture en mémoire comme une entrée non fiable. Analyser et classer un enregistrement avant qu'il ne devienne persistant. Un résumé produit par l'agent n'est pas automatiquement sûr.
2. Conserver la provenance. Enregistrer la source, l'identité de l'utilisateur ou de l'outil, l'heure, la tâche et l'historique des transformations.
3. Séparer locataires et tâches. Empêcher un enregistrement de franchir les limites d'un utilisateur, d'un espace de travail ou d'une finalité sans politique explicite.
4. Appliquer conservation et révocation. Définir une expiration pour les mémoires sensibles, permettre une suppression ciblée et invalider les entrées liées à une source compromise.
5. Contrôler à l'écriture et à la lecture. Un filtre de récupération peut manquer une attaque ou bloquer trop de contenu légitime. Validation, détection d'anomalies et politique sont nécessaires aux deux étapes.
6. Limiter l'effet du texte récupéré. La mémoire peut informer le raisonnement, mais ne doit pas accorder d'identifiants ni d'autorité. Les appels d'outils à conséquence réelle exigent encore un point de contrôle indépendant et des preuves d'audit IA utiles.

Les tests devraient couvrir une interaction unique, les sorties d'outils, la dérive, la mémoire partagée, la suppression, la reprise et les changements de modèle. Une entrée supprimée ne doit pas retrouver son influence après la reconstruction d'un index ou la restauration d'une sauvegarde.

Incertitudes restantes

L'article est accepté dans une conférence, mais l'évaluation reste limitée. L'optimisation la plus forte utilise un accès au modèle que l'attaquant ne possède pas toujours. Les systèmes qui réécrivent ou résument fortement les interactions avant stockage peuvent se comporter autrement. Les auteurs ne montrent pas non plus un transfert fiable vers toutes les familles inconnues.

Les pourcentages ne doivent pas devenir une estimation universelle du risque. Une évaluation pratique doit utiliser l'implémentation réelle de la mémoire, la logique de récupération, le modèle, le format du prompt, les outils, les permissions et les frontières de données en production.

Analyse Maetra : la mémoire exige son propre cycle de contrôle

La mémoire d'un agent doit être inventoriée comme toute autre capacité à conséquence réelle. Les équipes doivent savoir ce qui est stocké, qui ou quoi l'a écrit, où l'entrée peut être récupérée, quelles actions elle peut influencer et comment elle est révoquée.

Commencez par un agent qui conserve du contexte entre les sessions. Suivez une entrée depuis son ingestion jusqu'à sa récupération, puis jusqu'à un appel d'outil ou un effet externe. Si elle peut influencer une action sans provenance, politique ni preuve, la couche mémoire fait déjà partie du plan de contrôle, même si le produit ne la présente que comme une fonction de personnalisation.

Sources

• InjecMEM: Memory Injection Attack on LLM Agent Memory Systems, soumis le 24 août 2026 et indiqué comme accepté à COLM 2026.
• Articles acceptés à COLM 2026, consulté le 25 août 2026.
• OWASP : Memory Is a Feature. It Is Also an Attack Surface, publié le 13 mai 2026.