MPBench : une taxonomie systématique de l'empoisonnement mémoire des agents LLM

De quoi s’agit-il ?

Le 3 juin 2026, cinq chercheurs — Pritam Dash, Tongyu Ge, Aditi Jain, Tanmay Shah et Zhiwei Shang — ont publié sur arXiv (cs.CR/cs.AI) From Untrusted Input to Trusted Memory: A Systematic Study of Memory Poisoning Attacks in LLM Agents. Ce n’est pas une nouvelle attaque, mais une systématisation : l’article reprend les résultats épars sur l’empoisonnement mémoire publiés depuis deux ans, les organise en taxonomie, puis livre un banc d’essai, MPBench, pour les mesurer.

L’empoisonnement mémoire désigne le fait qu’un agent traite une entrée non fiable comme une mémoire long terme digne de confiance. L’idée centrale de l’article : une seule écriture adverse peut influencer durablement le comportement ultérieur de l’agent, bien après la fin de la conversation qui l’a déposée. Là où l’injection de prompt est un détournement ponctuel du tour courant, l’empoisonnement mémoire est un détournement qui persiste d’une session à l’autre. C’est la première tentative publiée de cartographier cette surface de façon méthodique plutôt qu’exploit par exploit.

Comment ça marche

L’article décompose le problème selon trois axes. Aucun payload n’est reproduit ici ; la référence canonique est le PDF arXiv.

Axe 1 — CANAUX D'ÉCRITURE (4)
  Comment du contenu non fiable atteint la mémoire durable :
  - tours de conversation enregistrés dans le stockage long terme
  - sorties d'outils / de récupération réécrites comme « expérience »
  - étapes de résumé ou de réflexion qui distillent l'entrée en notes
  - écritures mémoire explicites émises par l'utilisateur ou l'agent

Axe 2 — VULNÉRABILITÉS STRUCTURELLES (9)
  Pourquoi ces canaux sont exploitables, regroupées sous :
  - capacités du modèle (incapacité à distinguer donnée et instruction)
  - conception du system prompt (aucune provenance ni étiquette de confiance)
  - architecture de l'agent (politiques d'écriture/lecture agressives, pas de revue)

Axe 3 — CLASSES D'ATTAQUE (6)
  Six familles d'empoisonnement issues de la matrice canal × faiblesse

Deux constats comptent surtout pour les praticiens. D’abord, l’agressivité est un risque : les agents réglés pour écrire et récupérer la mémoire plus volontiers — le réglage même qui les rend « intelligents » et personnalisés — se révèlent plus exploitables sur MPBench. Le curseur du confort est aussi celui du risque. Ensuite, plus net : les auteurs testent les défenses anti-injection existantes et constatent qu’elles ne couvrent pas l’empoisonnement mémoire. Un filtre qui inspecte le prompt courant n’a rien à dire d’une note malveillante écrite en mémoire des jours plus tôt et récupérée comme contexte de confiance.

Cela rejoint des attaques déjà documentées par la communauté — par exemple AgentPoison, qui montrait dès 2024 l’empoisonnement de mémoire et de bases de connaissances d’agents — et nos articles antérieurs sur la catégorie ASI06 d’OWASP, l’exfiltration mémoire dormante et la contamination temporelle de la mémoire. Ce qu’ajoute 2606.04329, c’est le tissu conjonctif : un vocabulaire commun et un outil de mesure.

Pourquoi c’est important

La mémoire est désormais une fonctionnalité par défaut, pas un objet de laboratoire. Les produits d’assistant embarquent une mémoire persistante, les frameworks d’agents réécrivent des « expériences » dans des bases vectorielles, et les pipelines RAG brouillent la frontière entre donnée récupérée et instruction. Chacun de ces cas est un canal d’écriture au sens de l’article.

L’implication défensive est inconfortable. La plupart des équipes ayant adopté en 2025 un filtre anti-injection côté entrée supposaient implicitement qu’il se généralisait. Cet article prouve le contraire. Une mémoire empoisonnée est, par construction, de confiance au moment où elle est lue : elle a déjà franchi la frontière que le filtre était censé garder. L’exposition est aussi asymétrique dans le temps : l’écriture et le déclenchement peuvent être séparés de plusieurs jours ou sessions, ce qui déjoue la surveillance par requête et complique l’analyse forensique, le tour malveillant ayant pu disparaître des journaux.

Une taxonomie et un banc d’essai, c’est exactement ce dont ce domaine avait besoin. Ils permettent de poser des questions concrètes — lequel des quatre canaux mon agent expose-t-il, laquelle des six classes puis-je reproduire contre ma propre pile — plutôt que de débattre d’anecdotes.

Défenses

L’article est diagnostique plus que prescriptif, mais sa structure désigne directement les parades. Traitez la mémoire comme une frontière d’entrée non fiable, pas comme un cache de confiance.

1. Étiquetez la provenance de chaque élément stocké. Marquez les entrées mémoire avec leur source (utilisateur, sortie d’outil, réflexion du modèle) et leur niveau de confiance, et ne laissez jamais une note issue d’un outil ou d’un document être récupérée avec la même autorité qu’une instruction vérifiée.
2. Filtrez le chemin d’écriture, pas seulement de lecture. Les filtres anti-injection côté entrée ne se généralisent pas à la mémoire ; ajoutez un contrôle distinct au moment où le contenu est écrit dans le stockage durable, puis à la récupération.
3. Rendez les écritures mémoire les moins agressives possible par défaut. Le constat MPBench est explicite : les politiques d’écriture/lecture avides sont plus exploitables. Exigez un seuil de pertinence ou de revue avant de persister, et préférez le contexte éphémère à la mémoire durable en cas de doute.
4. Ajoutez une revue humaine ou par politique pour les écritures à fort impact. Une mémoire pouvant modifier de futures autorisations d’outils, la gestion de secrets ou des décisions de dépense ne doit pas être auto-écrivable sans contrôle.
5. Conservez et versionnez la mémoire pour la forensique. Comme écriture et déclenchement sont décalés dans le temps, gardez une trace d’audit de qui/quoi a écrit chaque entrée et quand, afin de retracer une note empoisonnée après coup. Voir notre note sur l’intégrité des journaux d’agents.
6. Évaluez votre propre agent. Utilisez MPBench (ou sa méthodologie) pour énumérer les canaux d’écriture et classes d’attaque que votre déploiement expose réellement, au lieu de supposer qu’un seul filtre suffit.

État des lieux

Élément	Référence	Date	Notes
arXiv 2606.04329 v1	arXiv (cs.CR/cs.AI)	2026-06-03	Soumis ; étude systématique + banc MPBench
Quatre canaux / neuf faiblesses / six classes	Résumé de l’article	2026-06-03	Taxonomie modèle, prompt, architecture
« Mémoire agressive ⇒ plus exploitable »	Constat de l’article	2026-06-03	Mesuré sur MPBench
« Les défenses anti-injection ne couvrent pas l’empoisonnement mémoire »	Constat de l’article	2026-06-03	Faille clé pour les déploiements existants
Travaux fondateurs (AgentPoison)	arXiv 2407.12784	2024	Attaque antérieure d’empoisonnement mémoire/base de connaissances

La bonne leçon n’est pas « l’empoisonnement mémoire est nouveau » — il ne l’est pas. C’est que le domaine dispose enfin d’une carte commune et d’une règle graduée. Si votre agent a une mémoire persistante et que votre seule défense est un filtre côté entrée, cet article est la raison documentée de supposer que vous n’êtes pas couvert, et une façon structurée de trouver où sont les trous.

Cet article résume une recherche publiquement disponible à des fins défensives et éducatives. Il ne reproduit aucun code d’exploitation.