Le 6 juillet 2026, des chercheurs de plusieurs universités ont publié sur arXiv un article intitulé "When Claws Remember but Do Not Tell" décrivant une classe d'attaque inédite contre les agents IA dotés de mémoire persistante. L'attaque, nommée MemGhost, permet à un expéditeur externe d'envoyer un seul email contenant des instructions cachées qui poussent l'agent IA à écrire de fausses informations dans ses fichiers de mémoire persistante, à dissimuler cette action dans sa réponse visible, et à restituer ces fausses informations lors de toutes les sessions ultérieures sans jamais signaler leur origine douteuse. Les chercheurs ont mesuré un taux de succès de 87,5 % contre le framework OpenClaw alimenté par GPT-5.4, et de 71,4 % contre le Claude Code SDK sur le modèle Sonnet 4.6.
Ces chiffres ne décrivent pas une preuve de concept théorique difficile à reproduire. Ils décrivent une attaque que les chercheurs ont été capables d'automatiser : leur outil génère des payloads d'email complets sans interaction itérative avec le modèle cible. Un attaquant qui dispose de cet outil peut envoyer un email et attendre que l'agent corrompe lui-même sa propre mémoire.
Les agents IA conversationnels modernes ont une capacité que les chatbots classiques n'avaient pas : ils peuvent conserver des notes entre les sessions. Ces notes, généralement stockées dans des fichiers texte comme MEMORY.md ou AGENTS.md, permettent à l'agent de se souvenir des préférences d'un utilisateur, de mémoriser des faits importants pour son travail, et de maintenir une continuité entre les conversations qui dure au-delà du contexte d'une session unique.
Cette persistance est précieuse. Un assistant IA qui se souvient que l'utilisateur préfère les réponses concises, ou qui conserve une liste des projets en cours, est significativement plus utile qu'un assistant qui repart de zéro à chaque conversation. Mais cette persistance crée aussi une surface d'attaque nouvelle : si un acteur malveillant peut écrire dans ces fichiers de mémoire, les informations plantées persisteront dans toutes les conversations futures de l'agent, influençant ses réponses de façon invisible et durable.
La veille sur les menaces cyber est essentielle pour suivre ce type de recherche. La mémoire persistante est souvent implémentée via des fichiers texte editables, des bases de données vectorielles, ou des combinaisons des deux. Dans tous les cas testés par les chercheurs de MemGhost, le mécanisme fondamental est le même : l'agent lit sa mémoire au début de chaque session et traite son contenu comme une source d'information fiable pour guider ses réponses. Corrompre cette mémoire, c'est corrompre toutes les sessions qui suivront.
L'attaque exploite la façon dont les agents IA traitent les emails entrants. Un agent qui surveille une boîte mail et répond aux messages doit lire chaque email pour en comprendre le contenu. Quand l'agent lit un email contenant des instructions MemGhost, il perçoit ces instructions non pas comme du contenu à transmettre à l'utilisateur mais comme des directives adressées à lui-même. L'email piégé contient du texte conçu pour ressembler à une correspondance normale tout en ordonnant à l'agent d'exécuter trois actions séquentielles : écrire des informations falsifiées dans ses fichiers de mémoire persistante, ne pas mentionner cette écriture dans la réponse visible envoyée à l'utilisateur humain, et traiter ces informations comme factuelles dans toutes les sessions ultérieures.
Les chercheurs ont entraîné un modèle attaquant hors ligne contre des copies fantômes du framework cible, en récompensant les emails qui réussissaient à modifier la mémoire tout en maintenant une réponse visible inoffensive. Ce processus d'entraînement produit un générateur de payloads qui peut créer automatiquement des emails MemGhost sans nécessiter d'accès interactif au modèle cible. L'attaquant n'a pas besoin de tester manuellement différentes formulations pour trouver ce qui fonctionne : le modèle attaquant génère directement des payloads optimisés.
L'exemple concret testé par les chercheurs illustre le type d'impact que l'attaque peut produire. Un email MemGhost a planté dans la mémoire de l'agent ciblé une fausse information selon laquelle la limite de transfert Zelle était de 10 000 dollars. Dans une session ultérieure, quand un utilisateur a demandé à l'agent des informations sur les limites de transfert bancaire, l'agent a restitué le chiffre falsifié comme une information factuelle, sans aucune indication que cette information provenait d'une source externe non vérifiée. L'utilisateur a reçu une mauvaise information présentée avec la même confiance que les informations légitimes.
Le taux de succès de 87,5 % contre OpenClaw avec GPT-5.4 et de 71,4 % contre le Claude Code SDK sur Sonnet 4.6 sont des mesures empiriques sur les configurations par défaut de ces frameworks avec leurs défenses de sécurité standard activées. Les filtres d'entrée standard ont manqué l'attaque dans plus de 90 % des cas testés. Les modèles durcis, c'est-à-dire les variantes entraînées spécifiquement pour résister aux injections de prompt, ont quand même suivi les instructions plantées environ 50 % du temps.
Les chercheurs ont également testé l'attaque contre des systèmes de mémoire basés sur des bases de données vectorielles plutôt que des fichiers texte. Le taux de succès est resté supérieur à 80 %, ce qui indique que la vulnérabilité n'est pas spécifique à une implémentation de mémoire particulière mais inhérente à l'architecture générale où un agent IA traite du contenu externe non contrôlé comme potentiellement autoritatif. La base de données vectorielle est un détail d'implémentation ; le problème fondamental est que l'agent lit de l'email non contrôlé et peut en extraire des instructions.
Pour mesurer la portée du risque, les chercheurs ont développé WhisperBench, un benchmark de 108 cas couvrant des scénarios de désinformation allant des erreurs médicales à la fraude financière. Ce benchmark permet d'évaluer non seulement si une attaque MemGhost réussit techniquement à corrompre la mémoire, mais aussi si la corruption produit des conséquences réelles pour les utilisateurs qui dépendent de l'agent pour des décisions importantes. Les résultats montrent que les conséquences sont réelles et mesurables dans des domaines où une mauvaise information peut avoir des impacts concrets.
La montée en puissance des agents IA autonomes qui traitent des emails est un développement relativement récent dans l'outillage des entreprises. Ces agents prennent différentes formes : assistants personnels qui lisent et répondent à des emails en délégation, agents de support client qui traitent les demandes entrantes, agents de veille qui surveillent des boîtes mail spécialisées pour extraire des informations, et agents d'orchestration qui coordonnent des workflows déclenchés par des emails entrants. Dans tous ces cas, l'agent doit lire du contenu provenant de sources externes non contrôlées.
Jusqu'à la publication de la recherche MemGhost, l'injection de prompt via email était considérée comme une menace connue mais dont les conséquences restaient généralement limitées à la session en cours : un attaquant pouvait peut-être faire faire à l'agent quelque chose de non désiré pendant le traitement d'un email spécifique, mais l'impact ne persistait pas au-delà de cette session. MemGhost change cette évaluation fondamentalement. L'impact d'une attaque réussie persiste indéfiniment dans toutes les sessions futures de l'agent, jusqu'à ce que la mémoire corrompue soit détectée et nettoyée manuellement. Ce changement de persistance transforme l'injection de prompt d'une nuisance de session en une compromission durable de l'agent.
Les chercheurs et les équipes de sécurité des frameworks testés ont proposé plusieurs approches de mitigation. La première est l'étiquetage de source : l'agent devrait enregistrer dans chaque entrée de mémoire l'origine de l'information (email externe, conversation avec l'utilisateur, configuration administrative, etc.) et traiter les informations provenant de sources non contrôlées avec un niveau de confiance inférieur à celles provenant de sources vérifiées. Cette approche est techniquement réalisable mais nécessite une modification de l'architecture de mémoire des agents existants.
La deuxième mitigation est l'approbation obligatoire avant toute écriture dans la mémoire persistante à partir de contenu externe. Avant que l'agent ne sauvegarde une information provenant d'un email dans sa mémoire, il devrait demander confirmation à l'utilisateur humain. Cette approche est efficace mais elle réduit l'autonomie de l'agent : une partie de la valeur des agents autonomes est précisément qu'ils n'ont pas besoin de demander confirmation pour chaque action. Si chaque écriture en mémoire déclenche une demande de confirmation, l'agent devient beaucoup moins fluide à utiliser.
La troisième approche, recommandée par les équipes de sécurité d'OpenClaw, est architecturale : router les emails non contrôlés à travers un agent de lecture séparé qui n'a pas accès aux fichiers de mémoire persistante, puis ne passer que des résumés de cet agent de lecture à l'agent principal. Cette séparation empêche physiquement les emails externes d'atteindre la mémoire persistante. Elle est efficace mais elle représente une modification architecturale significative pour les déploiements existants, et les chercheurs notent que cette configuration spécifique n'a pas été incluse dans leurs tests, donc son efficacité précise contre MemGhost reste à mesurer.
La journalisation de chaque modification de fichier de mémoire est une mitigation complémentaire : elle ne prévient pas l'attaque mais permet de la détecter après coup. Un log horodaté de toutes les écritures dans MEMORY.md ou les équivalents, incluant le contenu de l'email ou du message qui a déclenché l'écriture, permet à un analyste de revenir en arrière et d'identifier les entrées de mémoire corrompues. Sans cette journalisation, distinguer les entrées légitimes des entrées MemGhost après le fait nécessite une reconstruction manuelle fastidieuse des sessions passées.
Les organisations qui ont déployé des agents IA dotés de mémoire persistante pour traiter des emails entrants devraient traiter la publication de MemGhost comme un signal pour réexaminer leur architecture de déploiement. La question centrale n'est pas "est-ce que nos agents sont vulnérables à MemGhost" mais "est-ce que nos agents lisent du contenu externe non contrôlé et peuvent écrire dans une mémoire persistante". Si la réponse est oui, la vulnérabilité est présente dans sa forme fondamentale indépendamment du modèle de langage sous-jacent et de l'implémentation spécifique de la mémoire.
Les mesures immédiates les plus accessibles sans refonte architecturale complète sont la journalisation des modifications de mémoire et la revue régulière du contenu des fichiers de mémoire persistante. Ces deux mesures permettent de détecter une attaque MemGhost réussie et de nettoyer les entrées corrompues avant qu'elles n'influencent un nombre excessif de sessions. Elles ne préviennent pas l'attaque mais elles limitent significativement sa fenêtre d'impact et permettent une remédiation ciblée plutôt qu'une remise à zéro complète de la mémoire de l'agent.
Pour les organisations qui envisagent de déployer de nouveaux agents IA avec capacité de traitement d'email, la recherche MemGhost plaide fortement pour l'architecture de séparation recommandée par OpenClaw : un agent de lecture sans accès à la mémoire persistante, séparé de l'agent principal qui bénéficie de la mémoire. Cette architecture devrait être la conception par défaut pour tout nouvel agent traitant des emails externes, pas une option avancée à implémenter après que les problèmes de sécurité ont été identifiés en production.
Une réaction intuitive à la découverte de MemGhost serait de penser que la vulnérabilité est spécifique aux systèmes de mémoire basés sur des fichiers texte et que les implémentations plus sophistiquées utilisant des bases de données vectorielles seraient protégées. Les chercheurs ont testé cette hypothèse directement et l'ont réfutée : le taux de succès de MemGhost contre les systèmes de mémoire vectorielle est resté supérieur à 80 %. La raison est structurelle plutôt que technique.
Dans un système de mémoire vectorielle, les informations sont stockées sous forme d'embeddings, des représentations numériques de haute dimension qui capturent la signification sémantique des données. Quand l'agent cherche des informations pertinentes pour répondre à une question, il cherche les embeddings les plus proches de l'embedding de la question et récupère les entrées correspondantes. Une entrée MemGhost stockée dans cette base de données vectorielle sera récupérée avec la même confiance qu'une entrée légitime si son contenu est sémantiquement proche des questions auxquelles elle est censée répondre. Le format de stockage ne change pas le fait que l'agent traite le contenu récupéré comme une source d'information fiable.
La seule mitigation qui adresse le problème au niveau structurel est l'étiquetage de provenance : chaque entrée de mémoire doit conserver une trace de sa source et de son niveau de confiance, et l'agent doit utiliser cette métadonnée pour pondérer les informations récupérées. Une entrée provenant d'un email externe non vérifié devrait être traitée avec un niveau de confiance inférieur à une entrée provenant d'une instruction directe de l'utilisateur ou d'une configuration administrative. Implémenter ce système de provenance dans un framework d'agent existant n'est pas trivial, mais c'est la seule approche qui adresse la cause racine plutôt que ses symptômes.
MemGhost s'inscrit dans un contexte plus large d'attaques par injection de prompt contre les agents IA, mais elle se distingue de ses prédécesseurs sur deux dimensions critiques : la persistance et l'invisibilité. Les attaques par injection de prompt documentées avant MemGhost opéraient généralement au niveau de la session courante : un document malveillant traité par l'agent pouvait l'amener à exécuter une action non désirée pendant le traitement de ce document, mais l'impact se terminait avec la session. L'agent, à sa prochaine conversation, n'avait aucun souvenir de la manipulation subie.
MemGhost rompt avec ce modèle en transformant l'injection de prompt en attaque d'infrastructure. Plutôt que de manipuler le comportement de l'agent pendant une seule session, MemGhost modifie la base de données qui persistera et influencera toutes les sessions futures. C'est la différence entre pousser un humain à faire quelque chose de regrettable dans un moment de distraction et lui implanter de faux souvenirs qui modifient sa vision du monde de façon permanente. Le premier est une erreur récupérable ; le second est une compromission durable.
L'invisibilité est la deuxième dimension distinctive de MemGhost. Les attaques précédentes par injection de prompt laissaient souvent des traces visibles : l'agent produisait une réponse ou effectuait une action clairement anormale qui alertait l'utilisateur ou un observateur attentif. L'objectif explicite de MemGhost est que la réponse visible de l'agent à l'email piégé soit entièrement normale, ne révélant rien de l'écriture en mémoire qui vient de se produire. Les chercheurs ont récompensé spécifiquement cette invisibilité dans leur processus d'entraînement du modèle attaquant, ce qui a produit des payloads optimisés pour maintenir une apparence normale tout en effectuant la modification de mémoire. Une surveillance basée sur le comportement observable de l'agent ne détectera pas une attaque MemGhost réussie parce qu'il n'y a rien d'anormal à observer au moment de l'attaque.
La recherche MemGhost a été conduite principalement sur des frameworks d'agents IA grand public et de développement, mais les implications sont directement pertinentes pour le déploiement des agents IA dans des contextes d'entreprise. Les cas d'utilisation qui combinent les deux conditions de la vulnérabilité, mémoire persistante et traitement d'emails externes non contrôlés, sont de plus en plus courants dans les entreprises qui ont commencé à déployer des assistants IA pour automatiser des workflows.
Un assistant IA configuré pour surveiller une boîte mail de support client et répondre aux demandes entrantes, tout en conservant une mémoire des politiques de l'entreprise et des préférences des clients réguliers, remplit les deux conditions. Un agent de veille concurrentielle qui surveille une boîte mail pour les newsletters et alertes du secteur, tout en maintenant une mémoire de l'état du marché et des positions des concurrents, remplit les deux conditions. Un agent de gestion de projet qui traite des emails de mise à jour de partenaires externes et maintient une mémoire de l'état du projet, remplit les deux conditions. Dans chacun de ces cas, un expéditeur externe qui envoie un email spécialement formulé peut potentiellement corrompre la mémoire de l'agent et influencer ses réponses futures à tous les utilisateurs internes qui interagissent avec lui.
L'impact dans ce contexte n'est pas limité à l'utilisateur individuel de l'agent. Un agent d'entreprise compromis par MemGhost peut influencer les décisions de multiples employés qui dépendent de lui pour des informations de référence, sans qu'aucun d'entre eux ne soit en mesure de détecter que les informations qu'ils reçoivent ont été altérées. La surface d'impact d'une attaque MemGhost réussie contre un agent d'entreprise partagé est proportionnelle au nombre d'utilisateurs qui font confiance à cet agent et au domaine de décision que cet agent couvre. Dans un contexte financier ou médical, cette surface d'impact peut être très significative.
Les auteurs de la recherche MemGhost ont adopté une approche de divulgation responsable en partageant leurs résultats avec les équipes de sécurité des frameworks testés avant la publication de l'article arXiv. OpenClaw a mis à jour ses recommandations de sécurité pour inclure l'architecture de séparation des agents de lecture. Anthropic et les équipes du Claude Code SDK ont reçu les détails techniques des tests de succès contre leur framework. Ces réponses sont les premières étapes d'un processus qui doit aboutir à des protections architecturales intégrées dans les frameworks eux-mêmes, pas seulement à des recommandations de configuration que les déployeurs doivent implémenter manuellement.
Le benchmark WhisperBench que les chercheurs ont publié avec l'article est un outil de mesure communautaire : il permet aux équipes de sécurité des frameworks d'agents et aux chercheurs indépendants d'évaluer l'efficacité de nouvelles mitigations contre la classe d'attaque MemGhost. Un framework qui implémente l'étiquetage de provenance ou l'approbation obligatoire avant écriture en mémoire peut mesurer son taux de succès contre les payloads WhisperBench pour vérifier l'efficacité de sa protection. Ce type d'outillage de mesure partagé est essentiel pour transformer une recherche sur une vulnérabilité en progrès défensif vérifiable plutôt qu'en simple documentation d'une menace.
Les attaques comme celles décrites dans cet article rappellent pourquoi la surveillance proactive de votre exposition externe ne peut pas rester optionnelle. Quand des identifiants sont volés, quand des agents IA sont manipulés, ou quand des données d'organisation circulent dans des canaux souterrains, les dégâts sont souvent déjà faits au moment où votre équipe les détecte.
Defendis surveille le dark web, les forums criminels et les marchés souterrains pour remonter les preuves d'exposition de votre organisation avant que les attaquants ne passent à l'action. Si des identifiants ou des données liés à votre organisation apparaissent dans un log de stealer ou une annonce de broker, Defendis les remonte avec le contexte complet : l'individu concerné, les données exposées, et comment la compromission s'est probablement produite.
Réservez une démo pour voir Defendis en action.
