MemPoison : piéger la mémoire d'un agent par simple conversation

What is this?

Le papier Hijacking Agent Memory: Stealthy Trojan Attacks Through Conversational Interaction, publié sur arXiv en mai 2026, décrit MemPoison : une méthode pour implanter une porte dérobée déclenchable dans la mémoire long terme d’un agent LLM en n’utilisant qu’une conversation ordinaire. L’attaquant n’a besoin d’aucun privilège élevé ni d’aucun accès en écriture au magasin de mémoire. Il discute avec l’agent — comme n’importe quel utilisateur le ferait sur une plateforme partagée — et une charge dormante est laissée derrière lui pour plus tard.

C’est un raffinement d’un problème déjà connu. MINJA (NeurIPS 2025) a montré qu’un utilisateur pouvait injecter des enregistrements malveillants dans la mémoire d’un agent par de simples requêtes, et l’étude attaque-défense de janvier 2026 a durci le tableau. Ce que MemPoison ajoute, c’est une réponse directe à la défense évidente : beaucoup d’agents en production ne stockent pas les conversations telles quelles. Ils exécutent un pipeline de mémoire sélectif qui extrait, résume et réécrit le contenu avant tout enregistrement. Les attaques antérieures supposaient discrètement que le texte injecté arrivait intact en mémoire. MemPoison est précisément conçu pour survivre à ce pipeline — c’est ce qui le rend digne d’attention. Il est étroitement lié à l’injection de prompt stockée inter-session, mais vise l’étape de construction de la mémoire elle-même.

How it works

MemPoison se déroule en deux phases. Dans la phase d’injection, l’attaquant empoisonne la mémoire via des tours de conversation normaux sur un agent partagé. Dans la phase de déclenchement, la porte dérobée s’active par l’une de deux voies : déclenchée par l’utilisateur, où le déclencheur se trouve dans un contenu externe (une page web) qu’un utilisateur innocent demande ensuite à l’agent de lire, ce qui amène l’agent à récupérer et exécuter la charge implantée ; ou déclenchée par l’attaquant, où celui-ci émet simplement une requête contenant le déclencheur pour obtenir la réponse malveillante à la demande.

La contribution réside dans le passage de la charge à travers la mémoire sélective. Le papier décrit trois composants, que nous résumons de façon conceptuelle plutôt que de les reproduire :

• Un pont relationnel sémantique lie le déclencheur et la charge en une seule phrase cohérente, de sorte que l’étape d’extraction les conserve ensemble au lieu d’en éliminer une moitié.
• Le masquage d’entité façonne le déclencheur pour qu’il ressemble à une entité nommée, afin que l’étape de réécriture le préserve plutôt que de le paraphraser.
• L’optimisation conjointe des embeddings regroupe les textes porteurs du déclencheur en un amas serré dans l’espace d’embedding tout en les séparant du contenu bénin, de sorte que la récupération fasse fiablement remonter la charge sur le déclencheur et reste silencieuse autrement.

INJECTION  (l'attaquant discute sur un agent partagé)
  tours de conversation ──▶ pipeline de mémoire sélectif
                            (extraire → résumer → réécrire → embed)
                                         │  survit, par conception
                                         ▼
                              MÉMOIRE LONG TERME  [déclencheur + charge]

   ... l'attaquant part ; l'entrée reste dormante ...

DÉCLENCHEMENT
  (A) la victime demande à l'agent de lire un contenu externe portant le déclencheur
  (B) l'attaquant re-requête avec le déclencheur
        └──▶ la récupération fait remonter la charge ──▶ l'agent émet une réponse malveillante

Aucune charge fonctionnelle n’est reproduite ici ; la leçon n’en a pas besoin. Les taux de succès rapportés atteignent jusqu’à 0,95 tout en préservant la précision bénigne, et la porte dérobée reste efficace face au filtrage par perplexité et à la paraphrase. L’analyse mécaniste des auteurs attribue cette robustesse à l’anisotropie de l’espace d’embedding et à la redistribution de l’attention — autrement dit, elle exploite des propriétés structurelles du système de mémoire, pas une simple chaîne fragile.

Why it matters

Le point dérangeant, c’est le modèle de menace, pas les chiffres. L’attaquant est un utilisateur ordinaire d’un agent partagé, sans accès particulier, qui laisse un piège qu’un autre utilisateur déclenchera plus tard. Un pipeline de mémoire sélectif — précisément le mécanisme que les équipes ajoutent pour se sentir plus en sécurité sur ce qui est mémorisé — est ici traité comme la surface d’attaque plutôt que comme la défense. Et comme la charge est dormante et furtive par construction, la fenêtre de détection se compte en jours, pas dans le tour qui l’a implantée.

Cela frappe le plus fort les déploiements multi-tenant et en équipe : bases de connaissances partagées, magasins de mémoire communs, agents qui servent de nombreux utilisateurs depuis un même état persistant. Dans ces contextes, une seule conversation empoisonnée peut ressurgir dans la session de quelqu’un d’autre, transformant une nuisance individuelle en point d’ancrage durable.

Defenses

Aucun contrôle unique ne supprime cette classe. L’objectif est de cesser de traiter la mémoire comme un contexte de confiance et de briser la boucle écriture-puis-récupération.

• Traitez la mémoire récupérée comme une entrée non fiable. Revalidez le contenu persistant à la lecture avec la même rigueur que le contenu externe frais. L’erreur de fond, c’est l’agent qui fait confiance à sa propre mémoire parce que « c’est déjà dedans ».
• Partitionnez la mémoire par provenance. Étiquetez les entrées avec leur source et la tâche qui les a écrites. Le contenu issu de conversations non fiables doit être mis en quarantaine et jamais injecté directement dans les prompts de planification ou de sélection d’outils.
• Isolez par utilisateur et par tenant. Préférez une mémoire à portée restreinte aux magasins mutables partagés. Une entrée écrite dans la session d’un utilisateur ne devrait pas être récupérable dans celle d’un autre par défaut — cela neutralise à soi seul la voie de déclenchement inter-utilisateur.
• Défendez à la récupération, pas seulement à l’écriture. Puisque MemPoison survit aux filtres de perplexité et de paraphrase à l’écriture, ajoutez des contrôles au moment de la récupération : filtrage par provenance, détection d’anomalies sur les mémoires qui remontent pour une requête, et vérifications d’implication ou de cohérence entre une mémoire récupérée et la requête courante.
• Contrôlez et journalisez chaque écriture. Rendez les écritures en mémoire explicites et encadrées par une politique — ce qui peut être écrit, par quelle tâche, depuis quelle source — avec journalisation de la provenance pour qu’une investigation ultérieure puisse remonter d’un comportement jusqu’à la conversation qui l’a implanté.
• Expirez agressivement et limitez l’exfiltration. Les TTL et l’oubli limitent le temps qu’une entrée dormante peut attendre son déclencheur ; un outillage à moindre privilège et la surveillance des sorties réduisent ce qu’une charge déclenchée peut réellement faire.

Status

Aspect	Empoisonnement de mémoire naïf	MemPoison (mai 2026)
Accès requis	Suppose souvent l’écriture directe en mémoire	Conversation seule, sans privilège
Pipeline de mémoire sélectif	Supposé contourné / absent	Conçu pour survivre extraction + réécriture
Déclencheur	Immédiat ou implicite	Dormant ; déclenché par l’utilisateur ou l’attaquant
Taux de succès rapporté	Variable	Jusqu’à 0,95, précision bénigne préservée
Résiste perplexité / paraphrase	Pas de façon fiable	Oui
Contrôle principal	Filtrage à l’écriture	Récupération consciente de la provenance + isolation

À retenir du papier de mai 2026 : un déplacement de l’endroit où la défense doit se situer. Filtrer ce qui entre en mémoire ne suffit pas quand un attaquant peut façonner une charge pour passer l’extraction et la réécriture intacte. Dans un agent à état, le pipeline de mémoire fait partie de la surface d’attaque — et les contrôles qui prennent la mémoire récupérée pour vérité de terrain continueront de manquer les portes dérobées conçues pour ressembler à des souvenirs.