GhostWriter : empoisonner la mémoire d'un agent IA personnel via un simple e-mail

De quoi s’agit-il ?

Le 6 juillet 2026, des chercheurs ont publié un article (préprint arXiv, cs.CR) décrivant GhostWriter, une attaque qui empoisonne la mémoire à long terme d’un agent assistant personnel outillé — le type d’agent qui surveille votre boîte de réception, gère votre agenda et rédige des e-mails à votre place. La nouveauté ne tient pas au fait que la mémoire puisse être empoisonnée ; des travaux antérieurs l’avaient déjà montré. Elle tient au point d’entrée. Là où les attaques précédentes supposaient que l’adversaire pouvait atteindre directement le magasin de mémoire ou piloter l’agent avec ses propres prompts, GhostWriter n’exige rien de plus que la capacité d’envoyer un e-mail à la victime.

L’article pointe une faille qui s’est aggravée à mesure que les agents gagnent une mémoire persistante. Pour éviter des fenêtres de contexte toujours plus larges, les agents dotés de mémoire enregistrent ce qu’ils voient — résumés, faits extraits, workflows utiles — et le récupèrent ensuite par similarité sémantique. La quasi-totalité d’entre eux enregistrent tout, sans aucun contrôle de sécurité sur ce qui est écrit. Cette logique « on mémorise d’abord, on ne se pose jamais de question » est la vulnérabilité. Les auteurs mesurent un taux d’injection moyen d’environ 98 % et un taux d’activation moyen d’environ 60 %, sur cinq agents à mémoire de pointe reposant sur quatre familles de modèles différentes. Il s’agit d’un article défensif, orienté classe d’attaque ; il ne contient aucun exploit exécutable.

Comment ça marche

GhostWriter se déroule en deux phases, et c’est l’écart entre elles qui le rend dangereux.

Dans la phase d’injection, l’attaquant rédige un e-mail d’apparence banale — un compte-rendu de réunion, un message « mes coordonnées ont changé » — et y dissimule une directive alignée sur une tâche future plausible. Lorsque le message arrive dans la boîte, l’agent l’ingère automatiquement et l’écrit en mémoire à long terme, étiqueté pour une récupération ultérieure. Aucune action de l’utilisateur n’est requise, et rien de visiblement anormal ne se produit.

Dans la phase d’activation, la mémoire empoisonnée reste dormante jusqu’à ce que l’utilisateur formule une demande ordinaire — « envoie la mise à jour au client », « planifie la revue ». L’étape de récupération remonte les mémoires sémantiquement proches, dont la mémoire empoisonnée, et l’agent, traitant sa propre mémoire comme fiable, suit l’instruction implantée : ajout d’un destinataire caché, redirection d’un message vers une adresse contrôlée par l’attaquant, ou fuite de détails d’un projet.

Pour fiabiliser la récupération, l’attaquant peut optimiser sa charge utile en pur boîte noire. À partir d’un corpus d’e-mails public (l’article utilise le jeu de données Enron) découpé en thèmes, il réécrit le message pour que son embedding se rapproche des formulations que l’utilisateur taperait probablement, en itérant jusqu’à ce que le score de similarité franchisse un seuil. L’adversaire ne touche jamais au modèle ni à la logique de récupération de l’agent — seulement au contenu qu’il envoie. L’article classe les objectifs en quatre catégories : corruption d’intégrité, fuite d’informations sensibles, exfiltration furtive et dépassement de périmètre. Le facteur déterminant reste l’absence de gouvernance de la mémoire orientée sécurité ; les auteurs notent qu’un filtrage anti-spam classique n’aide pas, car un message ciblé et sémantiquement valide — le même savoir-faire que la fraude au président (BEC) — passe au travers des classifieurs agrégés.

Pourquoi c’est important

Le rayon d’impact correspond à l’ensemble des outils dont dispose l’agent. Un assistant e-mail/agenda capable d’envoyer des messages peut être poussé à l’exfiltration ; un assistant de code avec accès au dépôt est une cible plus lourde. Deux propriétés aggravent le problème par rapport à une injection de prompt ponctuelle. D’abord la persistance : une seule mémoire injectée survit d’une session à l’autre, l’attaquant paie une fois et le piège attend. Ensuite le blanchiment de confiance : une fois le texte de l’attaquant dans le magasin de mémoire, l’agent cesse de le traiter comme une entrée non fiable et le considère comme son propre souvenir. L’attaque colle aussi à des adversaires réalistes — un contact interne qui connaît vos projets, ou un tiers externe travaillant à partir de vos seules pages LinkedIn et d’entreprise — sans aucune compromission de compte. C’est une instance concrète du risque catalogué dans la directive OWASP sur l’injection de prompt, poussée jusqu’à la couche mémoire.

Défenses

L’article associe à l’attaque une défense, AM-Sentry, dont la structure constitue l’enseignement pratique même si vous n’adoptez jamais ce système précis. Le principe : gouverner la couche mémoire comme une frontière de sécurité, à l’écriture comme à la lecture.

• Filtrez ce qui est écrit en mémoire. N’enregistrez pas chaque élément ingéré. Faites passer chaque candidat par une politique qui le note avant admission — le juge de l’article évalue origine, confiance, type et utilité, et n’admet que les entrées à la fois utiles et peu risquées.
• Modélisez explicitement la confiance dans la source. Pondérez une mémoire selon sa provenance : une déclaration directe de l’utilisateur prime sur un e-mail interne, lui-même prioritaire sur un message d’un expéditeur externe inconnu. Une instruction issue d’une origine non fiable ne doit pas devenir une mémoire durable.
• Filtrez de nouveau à la récupération. Avant que les mémoires récupérées n’entrent dans le contexte du modèle, passez-les dans un filtre qui retire les directives cachées — un second point de contrôle qui rattrape ce qui a échappé à la politique d’écriture.
• Séparez faits et instructions. Traitez les workflows stockés « fais X quand Y » comme bien plus sensibles que les faits stockés, puisque ce sont les directives qui réorientent le comportement.
• Gardez l’humain dans la boucle pour les actions irréversibles. Exigez une confirmation avant qu’un agent n’envoie de l’argent, ne transmette des documents confidentiels ou n’ajoute un destinataire externe — les actions dont ces objectifs ont finalement besoin.
• Journalisez chaque écriture en mémoire. Une piste d’audit durable de ce qui est entré en mémoire, et depuis quelle source, est ce qui rend une entrée empoisonnée repérable a posteriori.

Les auteurs indiquent qu’AM-Sentry réduit fortement le taux de succès de GhostWriter tout en préservant l’essentiel de l’utilité de l’agent — preuve que le compromis sécurité/utilité est ici favorable, et non binaire.

Statut

Élément	Valeur
Divulgation	Préprint arXiv (cs.CR), 6 juillet 2026
Attaque	GhostWriter — empoisonnement indirect de la mémoire à long terme via des entrées d’outils non fiables
Impact mesuré	~98 % de taux d’injection ; ~60 % de taux d’activation moyen
Périmètre testé	5 agents à mémoire sur 4 familles de modèles
Défense proposée	AM-Sentry (politique à l’écriture + filtre à la récupération)
Cause racine	Absence de gouvernance de la mémoire orientée sécurité

Dates clés : 6 juillet 2026 — publication du préprint GhostWriter et AM-Sentry. Ce travail prolonge des recherches antérieures sur l’empoisonnement de mémoire (AgentPoison, MINJA) qui supposaient un accès adverse plus fort.