Détecter l'empoisonnement de mémoire d'un agent via ses seuls logs d'outils

De quoi s’agit-il ?

Lorsqu’un agent LLM conserve une mémoire persistante, un attaquant peut y déposer une instruction malveillante pendant une session et la déclencher bien plus tard dans une autre. Cet « empoisonnement du canal mémoire » est difficile à repérer : les filtres d’entrée et les contrôles de la couche de récupération ne voient jamais la session de déclenchement, et l’agent enregistre la règle malveillante via sa propre voie d’écriture autorisée — rien ne paraît anormal au moment de l’écriture.

Un article publié sur arXiv le 30 juin 2026 (Forensic Trajectory Signatures for Agent Memory Poisoning Detection) apporte une observation utile pour la défense : même quand l’empoisonnement lui-même est invisible, l’exécution de l’attaque, elle, ne l’est pas. Quand un agent empoisonné finit par agir, il doit récupérer la donnée stockée par l’attaquant avant de pouvoir l’utiliser — et cette récupération apparaît dans le log d’appels d’outils. L’auteur reprend le cadre de la détection sur poste de travail classique : de même qu’un IDS hôte repère une intrusion à partir des séquences d’appels système sans lire la mémoire du processus, la trace d’appels d’outils d’un agent peut trahir une attaque par le canal mémoire sans inspecter le magasin mémoire, les poids du modèle ni le contenu d’un message.

Comment ça marche

L’étude porte sur une attaque d’exfiltration à déclenchement différé. Un document de « conformité » malveillant est récupéré par RAG, l’agent enregistre docilement une règle de routage (une adresse de destination contrôlée par l’attaquant) dans sa mémoire persistante, puis, lors d’une session ultérieure, il rappelle cette règle et envoie des données à l’attaquant.

Le point structurel clé est que l’adresse de destination est stockée comme une valeur de mémoire, pas comme une clé. Lister la mémoire ne renvoie que les noms de clés : pour apprendre où envoyer les données, l’agent doit donc appeler l’opération de rappel avant l’opération d’envoi. Les sessions bénignes — ou celles où une défense a bloqué l’attaque — sautent cette récupération et rédigent directement leur message. Il en résulte un invariant comportemental que l’auteur nomme recall-before-send : dans chaque session d’attaque réussie du jeu de données, le premier rappel précédait strictement le premier envoi, sans aucune exception.

Cette seule règle, appliquée aux logs de la session de déclenchement, sépare déjà les attaques réussies des non-attaques avec une aire sous la courbe d’environ 0,96. Un petit classifieur sur une dizaine et demie de features de trajectoire (nombres d’appels, transitions de paires d’outils, point d’entrée) porte ce chiffre à environ 0,99 — et, fait important, le signal est surdéterminé : retirer toutes les features liées au rappel laisse le score quasi inchangé, car récupérer la règle déclenche une cascade en aval (une seconde rédaction, un envoi supplémentaire) qui s’imprime aussi sur d’autres features. La signature tient sur neuf modèles open source de 7B à 120B de paramètres et se transfère à des modèles de pointe sans réentraînement. Nous décrivons le mécanisme de détection, pas une recette d’attaque.

Pourquoi c’est important

L’empoisonnement de mémoire est l’une des menaces d’agent les plus difficiles à prévenir — des travaux connexes du même auteur montrent que cinq des six classes de défense échouent face à cette attaque à déclenchement différé, parce que la plupart ne peuvent même pas observer la surface concernée. Une méthode de détection qui n’a besoin que des logs d’appels d’outils est séduisante, précisément parce que ces logs sont déjà émis par les frameworks de production tels que LangChain, LangGraph, OpenAI Assistants et l’usage d’outils d’Anthropic. Aucune inspection de la mémoire, aucun accès aux internes du modèle, aucune inférence supplémentaire — un seuil opérationnel bien plus bas que les défenses exigeant de modifier le magasin mémoire ou de lire les activations.

L’approche aide aussi à l’attribution. Une attaque par injection de prompt qui transporte la destination dans le prompt courant n’a pas besoin d’un rappel mémoire, et produit donc une trajectoire différente. Cela permet à un intervenant de distinguer une attaque par le canal mémoire d’une injection de prompt ordinaire à partir du seul log d’opérations — une frontière forensique réellement utile pour reconstituer ce qu’un agent a fait, et pourquoi.

Défenses

À considérer comme une détection qui complète la prévention, sans la remplacer.

• Journalisez chaque appel d’outil avec horodatage. Toute la méthode suppose des logs d’invocation ordonnés et horodatés. Assurez-vous que lectures mémoire, rédactions et envois sont tous capturés ; une récupération qui contourne la couche d’outils (caches internes, injection implicite de contexte) ne laisse aucune signature.
• Alertez sur recall-before-send. Signalez les sessions de déclenchement où un rappel mémoire précède une action sortante vers une destination inhabituelle. C’est peu coûteux, sans accès au modèle, et cela capture à lui seul le motif dominant.
• Détectez sur deux couches. Un classifieur en préfixe peut signaler des sessions suspectes en temps réel avant que l’envoi ne se termine (avec une légère perte de précision), doublé d’un classifieur pleine session pour l’audit forensique a posteriori.
• Conservez la prévention structurelle. La détection n’arrête pas l’attaque. Restreindre la récupération mémoire au niveau de la couche d’outils (pour que l’agent ne puisse pas rappeler en silence une donnée de routage contrôlée par l’attaquant) reste le contrôle structurel le plus solide ; associez-le à une provenance sur les écritures mémoire.
• Calibrez par modèle. Les modèles de raisonnement qui appellent souvent le rappel pour se vérifier augmentent les faux positifs. Ajustez les seuils par déploiement et écartez d’un seuil partagé les modèles aux habitudes de rappel atypiques.

Statut

Élément	Valeur
Classe	Détection forensique de l’empoisonnement du canal mémoire (défense)
Signal	Invariant d’appels d’outils « recall-before-send » dans la session de déclenchement
Entrées requises	Logs d’appels d’outils seulement — ni mémoire, ni poids, ni contenu des messages
Précision rapportée	~0,96 AUC (règle simple) à ~0,99 (classifieur complet) ; généralise de 7B à 120B et aux modèles de pointe
Angle mort connu	Attaques à contournement implicite qui exfiltrent sans rappel mémoire
Divulgué	30 juin 2026 (article de recherche)

Dates clés : 30 juin 2026 — article sur la détection par signatures de trajectoire (arXiv 2606.30566), s’appuyant sur une étude mécaniste de juin 2026 concluant que la plupart des défenses échouent face aux attaques mémoire à déclenchement différé. Des travaux connexes de juin 2026 systématisent les canaux d’écriture de l’empoisonnement mémoire (MPBench, arXiv 2606.04329) et l’injection de prompt stockée inter-sessions (arXiv 2606.04425) ; les attaques à contrôle persistant avaient été montrées plus tôt en 2026 (Zombie Agents, arXiv 2602.15654). Les noms de modèles cités sont ceux rapportés dans les articles sources.