Sleeper Memory Poisoning : des attaques dormantes contre les agents LLM à mémoire

De quoi s’agit-il ?

Le 14 mai 2026 (révisé le 18 mai), des chercheurs du CISPA et leurs collaborateurs — Sidharth Pulipaka, Stanislau Hlebik, Leonidas Raghav, Sahar Abdelnabi, Vyas Raina, Ivaxi Sheth et Mario Fritz — ont publié Hidden in Memory: Sleeper Memory Poisoning in LLM Agents. Le papier étudie un risque introduit par une fonctionnalité devenue standard cette dernière année : la mémoire persistante, qui permet à un assistant de stocker des informations propres à l’utilisateur d’une session à l’autre, pour la personnalisation et la continuité.

La contribution principale est de caractériser une attaque différée baptisée sleeper memory poisoning (empoisonnement de mémoire dormant). L’attaquant manipule un contexte externe que l’assistant lira plus tard — un document, une page web, un dépôt de code — pour lui faire enregistrer une fausse mémoire concernant l’utilisateur. Contrairement à une prompt injection classique, qui agit sur l’instant puis disparaît, la mémoire implantée peut rester dormante et resurgir lors de nombreuses conversations ultérieures, bien après que le contenu malveillant a quitté la fenêtre de contexte.

Comment ça marche

L’attaque se comprend comme un pipeline en trois étapes, que le papier évalue séparément : écriture, récupération, action.

1. Écriture. L’assistant de la victime ingère un contenu contrôlé par l’attaquant lors d’une tâche normale (résumer une page, relire un dépôt, lire un fichier partagé). Dans ce contenu se cache un texte conçu non pas pour déclencher une action immédiate, mais pour être mémorisé — formulé comme un fait durable sur l’utilisateur ou ses préférences. Le sous-système de mémoire le commit dans le stockage long terme.
2. Récupération. Lors d’une conversation ultérieure et sans rapport, l’étape de récupération fait remonter l’entrée empoisonnée comme s’il s’agissait d’un fait de confiance, confirmé par l’utilisateur. L’injection initiale n’est plus présente : les filtres d’entrée n’ont rien à inspecter.
3. Action. La fausse mémoire oriente le comportement du modèle — en biaisant les réponses, ou, dans une configuration agentique, en déclenchant des appels d’outils conformes à l’intention de l’attaquant.

Les taux mesurés sont frappants. Sur des assistants à mémoire, les mémoires empoisonnées ont été écrites avec succès jusqu’à 99,8 % du temps sur GPT-5.5 et 95 % sur Kimi-K2.6. Parmi les cas où une mémoire empoisonnée a ensuite été récupérée, elle a produit des actions agentiques conformes à l’intention de l’attaquant dans 60 à 89 % des évaluations selon les modèles. Ces taux sont élevés parce que l’étape d’écriture exploite précisément le comportement pour lequel la mémoire est conçue : capter avidement tout ce qui ressemble à un fait utile et durable.

Une étude complémentaire de juin 2026, From Untrusted Input to Trusted Memory de Dash, Ge, Jain, Shah et Shang, rend la structure explicite. Elle identifie quatre canaux d’écriture en mémoire et neuf faiblesses structurelles réparties entre le comportement du modèle, la conception du prompt système et l’architecture de l’agent, organise les attaques en six classes, et fournit MPBench pour les mesurer (nous l’avons traité dans MPBench : une carte commune pour l’empoisonnement de mémoire). Son constat principal rejoint le résultat sleeper : les agents réglés pour écrire et récupérer la mémoire de façon plus agressive sont plus exploitables, et les défenses anti-prompt-injection existantes ne couvrent pas l’empoisonnement de mémoire.

Pourquoi c’est important

La mémoire transforme une injection ponctuelle en point d’ancrage persistant. La propriété déterminante de la variante sleeper est que l’écriture et le bénéfice sont séparés dans le temps, ce qui casse le modèle mental sur lequel reposent la plupart des défenses. Une équipe peut analyser chaque prompt entrant, ne rien trouver, et avoir malgré tout un assistant compromis — parce que l’instruction malveillante a été commitée des semaines plus tôt et vit désormais dans ce que le système considère comme un état utilisateur de confiance.

C’est la triade létale prolongée sur l’axe du temps : accès aux données privées, exposition à du contenu non fiable et capacité d’agir, auxquels s’ajoute la durabilité. L’attaque généralise l’idée de dormance vue dans Trojan Hippo et la contamination temporelle de mémoire, et elle est démontrée sur des assistants commerciaux actuels, pas sur des maquettes. Tout déploiement où un agent lit du contenu tiers et conserve une mémoire long terme — assistants personnels, agents de code à mémoire de projet, bots de support qui mémorisent des comptes — hérite de cette surface.

Défenses

Les papiers sont diagnostiques, mais ils pointent clairement vers des mitigations. Traitez la mémoire comme une frontière d’entrée non fiable, jamais comme un cache de confiance.

1. Contrôlez le chemin d’écriture, pas seulement celui de lecture. Les filtres anti-prompt-injection en entrée ne se généralisent pas à la mémoire. Ajoutez un contrôle distinct au moment où le contenu est commité en stockage durable, puis de nouveau à la récupération.
2. Attachez provenance et niveau de confiance à chaque entrée. Étiquetez chaque mémoire selon sa source (confirmée par l’utilisateur, sortie d’outil, réflexion du modèle) et n’autorisez jamais une note issue d’un document ou d’un outil à être récupérée avec l’autorité d’un fait validé par l’utilisateur.
3. Rendez les écritures en mémoire les moins agressives possible par défaut. Les deux papiers relient les politiques d’écriture/récupération avides à une exploitabilité accrue. Exigez un seuil de pertinence ou de confirmation avant de persister, et préférez le contexte éphémère en cas de doute.
4. Ajoutez une étape de confirmation pour les mémoires à fort impact. Tout ce qui pourrait ensuite modifier des autorisations d’outils, des dépenses ou la gestion d’identifiants ne doit pas être auto-écrit sans contrôle humain ou de politique.
5. Versionnez et auditez la mémoire. Comme l’écriture et le déclenchement sont séparés dans le temps, conservez une trace de qui ou quoi a écrit chaque entrée et quand, afin de remonter à une note empoisonnée après coup — voir l’intégrité de la piste d’audit des agents et le garde-mémoire OWASP pour agents.
6. Évaluez votre propre agent. Servez-vous de MPBench (ou de sa méthodologie) pour énumérer les canaux d’écriture réellement exposés par votre déploiement, plutôt que de supposer qu’un seul filtre suffit.

État des lieux

Élément	Référence	Date	Notes
Hidden in Memory: Sleeper Memory Poisoning	arXiv 2605.15338	2026-05-14 (rév. 05-18)	Définit l’empoisonnement de mémoire différé/dormant ; pipeline écriture→récupération→action
Taux d’écriture réussie	Résumé du papier	2026-05-14	Jusqu’à 99,8 % (GPT-5.5), 95 % (Kimi-K2.6)
Taux d’action agentique parmi les récupérations	Résumé du papier	2026-05-14	60 à 89 % selon les modèles
From Untrusted Input to Trusted Memory (MPBench)	arXiv 2606.04329	2026-06-03	4 canaux d’écriture, 9 faiblesses, 6 classes ; les défenses PI ne couvrent pas la mémoire

À retenir : l’empoisonnement de mémoire n’est pas inédit — mais le cadrage sleeper montre avec quelle netteté l’attaque se dissimule dans le temps, et les taux mesurés sur de vrais assistants prouvent qu’elle n’a rien d’hypothétique. Si votre agent dispose d’une mémoire persistante et que votre seule défense est un filtre de prompt en entrée, partez du principe que vous n’êtes pas couvert.

Cet article résume des travaux de recherche publiquement disponibles à des fins défensives et pédagogiques. Il ne reproduit aucun code d’exploitation.