Le poisoning de la mémoire des agents AI transforme une entrée non fiable en état durable. Lorsqu’un agent écrit du contenu contrôlé par un attaquant dans une mémoire persistante, ce contenu peut réapparaître plusieurs jours ou sessions plus tard sous la forme d’un contexte apparemment fiable. Défendez l’ensemble du cycle de vie : contrôlez chaque écriture, associez une provenance et une date d’expiration, isolez les enregistrements par utilisateur et par agent, réévaluez les résultats de retrieval, maintenez l’autorisation des actions en dehors du modèle et conservez un journal d’influence permettant le rollback.
Table des matières
Qu’est-ce que le poisoning de la mémoire des agents AI ?
Le poisoning de la mémoire des agents AI consiste à insérer ou modifier des enregistrements persistants afin que leur retrieval ultérieur modifie la réponse, la décision ou l’utilisation d’un outil par un agent. L’entrée d’origine peut avoir disparu lorsque l’effet se manifeste. Ce décalage temporel rend l’attaque plus difficile à détecter et à reconstituer qu’une prompt injection visible dans la conversation actuelle.
La mémoire peut se trouver à plusieurs endroits :
La technologie de stockage n’est pas le facteur déterminant. La persistance, combinée à une influence ultérieure, crée la frontière de sécurité.
Ce risque se distingue de trois risques voisins. La prompt injection manipule le contexte actuel du modèle, même si elle peut devenir le canal de diffusion d’une mémoire empoisonnée. Le poisoning des données d’entraînement modifie le comportement du modèle via le corpus d’entraînement. Le retrieval poisoning cible le contenu sélectionné pour une requête. Le poisoning de la mémoire d’un agent persiste un enregistrement que le système peut ensuite traiter comme faisant partie de l’historique, des préférences ou de l’état opérationnel de l’utilisateur.
Trois schémas d’attaque sont importants en pratique :
| Schéma | Forme stockée | Activation | Pourquoi un filtre simple éprouve des difficultés |
|---|---|---|---|
| --- | --- | --- | --- |
| Corruption directe | Un enregistrement contient la directive nuisible ou le faux fait | L’enregistrement est récupéré ultérieurement | Le contenu peut être déguisé en préférence, résumé ou note de tâche |
| Corruption compositionnelle | Plusieurs enregistrements semblent acceptables pris isolément | Le retrieval conjoint assemble le sens nuisible | Chaque écriture est acceptée, car le risque n’apparaît qu’en combinaison |
| Corruption dormante | Un enregistrement contient une instruction dépendant d’un déclencheur | Un événement, une phrase ou un état d’outil ultérieur l’active | Le déclencheur est absent au moment de l’écriture |
Les recommandations actuelles de Microsoft décrivent la même préoccupation structurelle en termes défensifs : la mémoire persistante stocke des données sensibles et influence également le comportement du modèle ainsi que la sélection des outils. Elle doit donc être gouvernée à la fois comme un système de données et comme un plan de contrôle. Microsoft Learn
Ce que trois études récentes ont mesuré
Trois preprints de juillet 2026 ont examiné différentes parties de cette menace. Considérés ensemble, ils montrent pourquoi un filtre de mémoire unique constitue un faible critère de mise en production.
GhostWriter a testé l’injection immédiate et l’activation ultérieure
When Agents Remember Too Much a présenté GhostWriter, une attaque en deux étapes contre des agents personnels utilisant des outils. Un adversaire place d’abord du contenu dissimulé dans une source non fiable. L’agent traite cette source et écrit une mémoire influencée par l’attaquant. Une tâche ultérieure récupère l’enregistrement et active son effet.
Dans les agents et modèles testés par l’article, GhostWriter a atteint un taux moyen d’injection d’environ 98 % et un taux moyen d’activation d’environ 60 %. Les auteurs ont également testé AM-Sentry, qui combine une politique plus stricte de sauvegarde en mémoire avec un écran de retrieval. L’article évalue à la fois la réussite de l’attaque et l’utilité de la tâche dans sa simulation personnalisée d’une semaine de travail ; les résultats de la défense varient selon le modèle et la configuration.
Les limites sont importantes. Le travail couvre cinq agents, quatre familles de modèles et des workflows liés aux e-mails ou aux calendriers. Son test d’utilité est personnalisé, les attaquants ne sont pas adaptatifs et les résultats n’estiment pas la fréquence des attaques contre des agents déployés.
MemPoison a séparé les défaillances directes, compositionnelles et dormantes
MemPoison a rassemblé 1 227 cas validés manuellement, répartis entre quatre types d’attaque, trois canaux d’injection et trois substrats mémoire. L’évaluation incluait sept familles de modèles open-weight et trois familles de modèles closed-weight.
La contribution utile de l’article est sa taxonomie à trois niveaux. L1 correspond à une corruption directe d’un seul enregistrement. L2 devient nuisible lorsque plusieurs enregistrements sont récupérés ensemble. L3 reste dormant jusqu’à ce qu’un contexte ultérieur l’active. Les auteurs indiquent que les défenses de base au moment de l’écriture suppriment les attaques directes plus efficacement que les cas L2 ou L3. Leur analyse mécaniste de l’influence attribue cet écart aux enregistrements qui semblent inoffensifs lors de leur stockage, mais deviennent nuisibles par composition ou sous l’effet d’un déclencheur.
Cela ne prouve pas que tous les filtres d’écriture utilisés en production échoueront. Le benchmark couvre trois substrats mémoire représentatifs et des canaux textuels standard. Les auteurs appellent à approfondir les travaux sur la dégradation, la summarization, les contrôles d’accès et d’autres écosystèmes mémoire.
MemGhost a testé un canal de diffusion par e-mail en une seule étape
When Claws Remember but Do Not Tell a présenté WhisperBench, un benchmark de 108 cas utilisant un workflow IMAP/SMTP réel et une compétence d’agent e-mail. Son framework d’attaque, MemGhost, génère un payload e-mail sans feedback à l’exécution. La réussite exige que l’agent adopte la mémoire empoisonnée, évite d’alerter l’utilisateur dans sa réponse immédiate et modifie son comportement ultérieur.
Sur 56 cas réservés au test, l’article rapporte une réussite de bout en bout de 87,5 % sur OpenClaw avec GPT-5.4 et de 71,4 % sur le Claude Code SDK avec Sonnet 4.6.
Ces chiffres appartiennent au benchmark, à l’environnement proxy, à la conception de la récompense et aux versions de modèles des auteurs. L’évaluation commence après l’arrivée d’un message dans la boîte de réception. Elle ne modélise pas les contrôles du fournisseur de messagerie tels que le filtrage antispam, SPF, DKIM ou DMARC. L’article est un preprint en première version ; ses résultats doivent donc être répliqués.
Pourquoi le filtrage au moment de l’écriture ne suffit pas
Un contrôle d’écriture observe l’enregistrement proposé et les éléments disponibles à cet instant. Il peut ne pas voir la tâche future, les autres enregistrements qui seront récupérés à ses côtés ou l’outil que l’agent appellera ultérieurement.
Cela crée quatre angles morts :
Les contrôles au moment de l’écriture restent importants. Ils réduisent la quantité d’état non sûr qui atteint la persistance. L’erreur consiste à traiter l’approbation du stockage comme une confiance permanente.
Le retrieval doit renvoyer un contexte candidat, et non une autorité. Avant d’insérer un enregistrement dans le contexte du modèle, le système peut vérifier sa source, son ancienneté, sa pertinence pour la tâche, ses contradictions, sa sensibilité et l’effet demandé. Un enregistrement à haut risque peut être retenu, résumé ou envoyé en revue. Les recommandations actuelles de Microsoft préconisent cette séparation entre écriture et retrieval, ainsi qu’un isolement déterministe et une visibilité sur l’ensemble du cycle de vie. Microsoft Learn
La décision finale de sécurité doit toujours être prise en dehors de la mémoire. Une note récupérée indiquant « envoyer les rapports à cette adresse » ne doit pas modifier la liste blanche des destinataires. Une préférence mémorisée pour une région de déploiement ne doit pas créer de permission cloud. Utilisez deterministic AI agent permissions→ pour évaluer l’action proposée selon l’utilisateur, la ressource, la portée et la politique actuels.
Une architecture sécurisée pour la mémoire des agents
Le système doit disposer d’une chaîne traçable allant de la source à l’action :
`source → write decision → stored version → retrieval decision → model context → policy decision → tool result`
*Légende : un enregistrement mémoire ne devient un contexte candidat qu’après les contrôles d’écriture et de retrieval. Une politique indépendante autorise toujours chaque action ayant des conséquences, tandis que la chaîne d’influence facilite l’investigation et le rollback.*
1. Exiger une intention explicite pour les écritures durables
Ne laissez pas chaque message, document ou réponse d’outil devenir une mémoire à long terme. Définissez les événements pouvant créer un état durable. Les préférences confirmées par l’utilisateur et les actions explicites « souviens-toi de ceci » sont plus faciles à justifier qu’un résumé autonome d’une pièce jointe non fiable.
Enregistrez qui ou quoi a demandé l’écriture. Si un outil ou un sous-agent l’a initiée, préservez cette identité au lieu de tout attribuer au nom de l’utilisateur final.
2. Stocker la provenance, la portée et l’expiration avec l’enregistrement
Un enregistrement mémoire utile nécessite davantage que du texte et un embedding. Stockez au minimum :
Une signature peut protéger l’intégrité de l’enregistrement. Elle ne peut pas prouver que le contenu d’origine était vrai, sûr ou autorisé.
3. Appliquer l’isolement dans le code et le stockage
Les frontières entre tenants, utilisateurs, agents et espaces de travail doivent être appliquées par des listes de contrôle d’accès, des tokens à portée limitée, des politiques au niveau des lignes et des frontières de chiffrement. Les instructions de prompt ne constituent pas un contrôle d’accès. La mémoire partagée doit être une fonctionnalité explicite, avec des auteurs et lecteurs nommés, et non un namespace par défaut choisi par commodité.
Le même principe s’applique à l’environnement d’exécution. Si le contenu récupéré peut provoquer l’exécution de code ou une utilisation étendue des outils, confinez le processus avec AI agent sandbox security→. L’isolation de la mémoire limite le contexte qui franchit une frontière. Les contrôles de sandbox et d’identité limitent ce qui se produit si un contexte non sûr atteint malgré tout l’agent.
4. Mettre en quarantaine les écritures à faible confiance
Créez un état intermédiaire entre « rejeté » et « mémoire fiable ». Les fichiers externes, e-mails, pages web, sorties indirectes d’outils et enregistrements dont l’intention est incertaine peuvent entrer en quarantaine. Ils ne doivent pas apparaître dans le retrieval normal avant qu’une règle déterministe ou un réviseur autorisé ne les promeuve.
La quarantaine offre également aux équipes de réponse aux incidents un emplacement où conserver les preuves sans poursuivre l’influence.
5. Réévaluer les enregistrements au moment du retrieval
Le risque du retrieval dépend de la tâche actuelle. Évaluez l’ensemble sélectionné, et pas seulement chaque enregistrement :
Évaluez le retrieval séparément de la génération. Un RAG evaluation workflow→ aide à distinguer « le mauvais enregistrement a été sélectionné » de « le modèle a mal utilisé un enregistrement correct ». Ajoutez des dimensions propres à la mémoire, telles que la provenance, la dépendance à un déclencheur, la composition et l’activation intersessions.
6. Maintenir l’autorisation des outils indépendante
La mémoire peut fournir des paramètres. Elle ne doit jamais étendre les permissions. La passerelle d’outils doit appliquer l’identité actuelle, l’action autorisée, la limite de ressource, la destination, le budget et les exigences d’approbation. Traitez les arguments dérivés de la mémoire comme des entrées non fiables et validez-les selon la politique actuelle.
L’approbation humaine nécessite également un contexte récent. Affichez l’action proposée, la ressource concernée, la destination des données et les mémoires qui l’ont influencée. Un simple « Approuver ? » sans cette chaîne dissimule les éléments pertinents de la décision.
7. Journaliser l’influence et permettre le rollback
Journalisez les opérations de création, lecture, mise à jour et suppression de la mémoire, avec leur identité et leur provenance. Pour les actions ayant des conséquences, conservez les identifiants et versions des enregistrements injectés dans le contexte. Cela permet de répondre à trois questions d’incident :
La suppression doit éliminer l’influence active, et pas seulement masquer une ligne dans l’interface utilisateur. Testez les indexes, résumés, caches, réplicas et enregistrements dérivés. Les recommandations d’OWASP pour les agents préconisent une mémoire validée et isolée, ainsi que des tests adversariaux et des preuves avant mise en production ; son analyse plus large de la mémoire associe la prompt injection persistante à la surface de menace de la mémoire des agents. OWASP Agent Security Cheat Sheet OWASP GenAI Security Project
Choisir une politique pour chaque classe de mémoire
Une seule politique de rétention est trop grossière. Commencez par des classes soumises à des règles différentes d’écriture et de retrieval.
| Classe de mémoire | Politique d’écriture par défaut | Politique de retrieval | Autorité sur les actions |
|---|---|---|---|
| --- | --- | --- | --- |
| Contexte de tâche éphémère | Automatique, TTL court | Tâche actuelle uniquement | Aucune |
| Préférence confirmée par l’utilisateur | Confirmation explicite | Même utilisateur et finalité déclarée | Peut suggérer, jamais autoriser |
| Résumé généré par l’agent | Versionné et lié aux sources | Revérifier les sources et l’actualité | Aucune |
| Contenu externe | Quarantaine par défaut | Seulement après vérifications de confiance et de pertinence | Aucune |
| Instruction opérationnelle | Auteur autorisé et revue de politique | Portée exacte, version actuelle | Nécessite toujours la politique de l’outil |
| Secret ou donnée réglementée | Bloquer ou utiliser des systèmes dédiés aux secrets et aux données | Ne jamais placer dans la mémoire générale | Plan de contrôle dédié uniquement |
Ce tableau constitue un point de départ, et non une affirmation de conformité. Un agent médical, un assistant de programmation, un agent commercial et un assistant personnel présentent des modèles de dommages différents. L’invariant est plus limité : la persistance ne doit pas convertir silencieusement un contenu non fiable en permission.
Un workflow reproductible de test du memory poisoning
Construisez le banc de test autour de marqueurs inoffensifs et de comptes jetables. Vous n’avez pas besoin de véritables identifiants ni de payloads d’exfiltration pour détecter les défaillances de persistance et de politique.
Étape 1 : Capturer une référence propre
Exécutez un ensemble fixe de tâches avec un magasin mémoire vide. Enregistrez les réponses, les résultats du retrieval, les propositions d’outils, les décisions de politique, la latence et les explications visibles par l’utilisateur. Répétez suffisamment l’expérience pour distinguer les changements du système de la variance normale du modèle.
Étape 2 : Définir des cas propres et empoisonnés appariés
Pour chaque cas, conservez la tâche utilisateur constante et ne modifiez que le chemin potentiel de la mémoire. Couvrez au minimum :
Utilisez une action canary telle que l’écriture de `TEST_BLOCKED` dans un journal jetable. Le test échoue si l’agent exécute ou propose cette action en dehors du chemin de politique attendu.
Étape 3 : Observer chaque frontière
Capturez quatre résultats distincts :
Une réussite de bout en bout peut masquer une couche faible. Par exemple, l’autorisation peut bloquer l’action canary alors qu’un enregistrement empoisonné a été stocké et récupéré à plusieurs reprises. Il s’agit d’un confinement utile, mais le défaut de mémoire doit tout de même être corrigé.
Étape 4 : Mesurer l’utilité et les faux positifs
Faites passer les cas de mémoire légitimes dans le même pipeline. Suivez l’achèvement des tâches, les préférences utilisateur acceptées, les mises en quarantaine incorrectes, la précision du retrieval, la latence et le volume de revue. Un filtre qui bloque toute mémoire durable présente un faible taux de réussite des attaques parce qu’il a supprimé la fonctionnalité.
Étape 5 : Définir des critères de mise en production selon le risque
Les critères utiles comprennent :
Le projet open source Agent Memory Guard d’OWASP constitue un signal d’implémentation pour l’analyse de mémoire et les outils de test. Son dépôt et son évaluation auto-déclarée peuvent aider les équipes à examiner des approches, mais ne remplacent pas les tests de l’agent, du modèle, du backend mémoire et de la pile de politiques réellement utilisés.
Réexécutez la suite après toute modification de l’extraction mémoire, de la summarization, des embeddings, du retrieval, des prompts, des modèles, des schémas d’outils, de l’autorisation ou de la logique de suppression. Ces couches interagissent.
Ce que les éléments disponibles permettent — ou non — d’affirmer
Les articles ont mesuré la réussite des attaques dans des benchmarks construits. Ils n’ont pas mesuré le taux de poisoning de la mémoire des agents AI dans la population de production.
Ils permettent de tirer trois conclusions plus limitées :
Les articles déduisent que la gouvernance de la mémoire nécessite des défenses sensibles au contexte. Microsoft et OWASP recommandent indépendamment une défense en profondeur couvrant les écritures, l’isolement, le retrieval, le contrôle utilisateur, l’observabilité et les tests.
L’interprétation pratique consiste à rendre chaque transition testable. Une équipe doit pouvoir expliquer pourquoi un enregistrement a été stocké, pourquoi il a été récupéré, comment il a influencé une action, quelle politique a autorisé cette action et comment supprimer les effets en aval de l’enregistrement.
Questions fréquentes des équipes
Le poisoning de la mémoire des agents AI est-il identique à la prompt injection ?
Non. La prompt injection est une manière d’introduire des instructions hostiles. Le poisoning de la mémoire ajoute la persistance : le contenu manipulé est stocké, récupéré dans un contexte ultérieur et peut influencer le raisonnement ou l’utilisation future des outils après la disparition de l’entrée d’origine.
Les enregistrements mémoire signés peuvent-ils empêcher le poisoning ?
Non. Les signatures peuvent prouver qu’un enregistrement n’a pas été modifié après sa création. Elles ne prouvent pas que le contenu d’origine était vrai, sûr ou autorisé. Une conception sécurisée nécessite également une provenance, une intention d’écriture explicite, une portée, une expiration, des contrôles du retrieval et une autorisation indépendante des actions.
Les défenses contre le poisoning de la mémoire doivent-elles s’exécuter à l’écriture ou au retrieval ?
Les deux. Les contrôles d’écriture réduisent la persistance de contenu non sûr. Les contrôles du retrieval détectent les risques obsolètes, contradictoires, compositionnels ou dépendants d’un déclencheur qui n’étaient pas visibles lors du stockage des enregistrements individuels. Aucune de ces couches ne doit pouvoir accorder une autorité sur les outils.
Vérification des affirmations
| Affirmation | Vérification | Statut |
|---|---|---|
| --- | --- | --- |
| GhostWriter a atteint environ 98 % d’injection moyenne et environ 60 % d’activation moyenne dans ses expériences | Rapporté par l’article pour les configurations d’agents personnels testées ; il ne s’agit pas d’une estimation de prévalence en production | Vérifié, avec périmètre |
| MemPoison contient 1 227 cas validés manuellement couvrant quatre types d’attaque, trois canaux d’injection et trois substrats mémoire | Indiqué dans le résumé et la description de l’évaluation de l’article | Vérifié |
| Les défenses de base au moment de l’écriture présentent des angles morts structurels pour les attaques compositionnelles et dormantes | Les auteurs de MemPoison rapportent une influence résiduelle pour les cas L2 et L3 | Vérifié, avec périmètre |
| MemGhost a rapporté des taux de réussite de bout en bout de 87,5 % et 71,4 % sur deux configurations réservées au test | Rapporté sur 56 cas réservés au test dans le cadre expérimental de l’article | Vérifié, avec périmètre |
| MemGhost n’a pas mesuré les contrôles antispam et d’authentification des fournisseurs de messagerie | L’évaluation commence après la livraison dans la boîte de réception et ne modélise pas ces contrôles | Vérifié |
| Microsoft recommande de traiter la mémoire comme des données et comme un plan de contrôle | Indiqué dans les recommandations actuelles de Microsoft Learn | Vérifié |
| Une signature valide ne rend pas une mémoire fiable | L’intégrité après création n’établit ni l’origine sûre, ni la véracité, ni l’intention, ni l’autorité | Vérifié |
| L’activité d’un dépôt ne prouve pas qu’un framework mémoire est sécurisé | Les étoiles, commits et releases mesurent l’attention et la maintenance, pas l’efficacité de sécurité | Vérifié |