MemAudit : un audit forensique pour repérer la mémoire d'agent empoisonnée

De quoi s’agit-il ?

Les agents LLM persistants ont une mémoire. Ils écrivent des résumés, des « leçons apprises » et des faits récupérés dans un magasin à long terme, puis rechargent ces entrées dans le contexte lors des tours suivants — souvent pour des utilisateurs et des tâches différents. Ce magasin est une surface d’attaque. L’empoisonnement de la mémoire injecte un contenu forgé qui ressemble à un souvenir ordinaire mais qui, une fois récupéré, oriente l’agent vers l’objectif d’un attaquant : fuite de données, appel du mauvais outil, ou validation d’une instruction malveillante. Comme la charge arrive par le canal d’écriture normal et se déclenche bien plus tard, elle ne touche ni les poids du modèle ni le code, et échappe aux défenses qui n’inspectent que le prompt courant.

La plupart des défenses publiées sont préventives : elles tentent d’empêcher l’écriture ou la récupération de mauvaises entrées. MemAudit, publié sur arXiv en mai 2026, adopte la posture inverse : supposer qu’un poison est déjà passé, et donner aux équipes de réponse un moyen d’auditer le magasin de mémoire après coup. Ce travail s’inscrit dans une littérature en pleine expansion — une étude 2026 sur la sécurité de la mémoire à long terme en cartographie tout le cycle de vie, et des travaux offensifs comme MemoryGraft montrent qu’une seule « expérience » empoisonnée peut compromettre durablement un agent.

Comment ça marche

MemAudit repose sur deux idées présentes dans son titre : l’attribution causale et la détection d’anomalies structurelles.

L’attribution causale répond à la question forensique « quels souvenirs ont causé ceci ? ». Lorsqu’un agent produit une action nuisible ou inattendue, l’auditeur doit savoir quelles entrées stockées l’y ont poussé. Plutôt que d’examiner à l’œil des milliers de notes, l’approche remonte l’influence depuis l’action observée jusqu’aux entrées précises qui ont façonné la décision — transformant « l’agent a mal agi » en « ces trois entrées, récupérées ensemble, ont dicté le comportement ». C’est la différence entre savoir qu’on a été compromis et savoir quoi supprimer.

La détection d’anomalies structurelles travaille dans l’autre sens. Un magasin de mémoire sain présente des régularités : la façon dont les entrées se relient, se regroupent, sont formulées et référencées. Les entrées empoisonnées détonnent souvent sur ce fond : une instruction déguisée en fait, une note reliée à bien plus de récupérations que ses voisines, un contenu dont la structure ne correspond pas à la manière habituelle dont l’agent s’écrit à lui-même. Signaler ces valeurs aberrantes fait remonter des candidates à examiner, même quand aucune entrée ne paraît malveillante isolément.

Utilisés ensemble, les deux signaux se recoupent. La détection d’anomalies réduit le champ aux entrées suspectes ; l’attribution causale confirme lesquelles ont réellement influencé un mauvais résultat donné. Aucun payload d’exploitation n’est nécessaire pour mener l’audit, et aucun n’est reproduit ici — l’objectif est le tri et le nettoyage, pas l’attaque.

Pourquoi c’est important

L’empoisonnement de la mémoire est l’une des menaces agentiques les plus difficiles, précisément à cause du décalage temporel. L’écriture et le dommage sont séparés par des heures, des jours ou plusieurs sessions, si bien que le filtrage d’entrée classique et les garde-fous par tour ne voient rien d’anormal. Dans les déploiements multi-utilisateurs, le rayon d’impact grandit : une entrée empoisonnée écrite pendant votre session peut être récupérée dans celle de quelqu’un d’autre. Des défenses préventives certifiées existent — voir SMSR, une proposition de juin 2026 assortie d’une borne de robustesse — mais la prévention n’est jamais parfaite, et les équipes ont besoin d’une réponse à « on pense que la mémoire est contaminée ; et maintenant ? ». L’audit forensique est cette réponse. Il augmente aussi le coût d’un empoisonnement furtif et lent : un attaquant qui misait sur une entrée éternelle doit désormais survivre à un audit capable de remonter des effets vers leurs causes.

Défenses

Traitez le magasin de mémoire comme un état sensible du point de vue de la sécurité, pas comme un simple cache de confort. Concrètement : liez chaque entrée à son origine (qui l’a écrite, depuis quelle session et quelle source) pour que l’attribution causale ait quelque chose à suivre ; conservez un journal en ajout seul des écritures et des récupérations pour rendre les incidents reconstructibles ; et cloisonnez la mémoire par niveau de confiance et par tenant pour qu’une entrée empoisonnée ne migre pas dans le contexte d’un autre utilisateur. Menez des audits périodiques — scans d’anomalies structurelles plus attribution sur toute action surprenante — plutôt que de vous fier à un filtre unique. Exigez la provenance et, si possible, une vérification humaine avant qu’un souvenir ne puisse autoriser un appel d’outil sensible, afin qu’une note récupérée ne soit jamais la seule base d’une action irréversible. Enfin, rendez la suppression effective : quand un audit désigne une entrée, purgez-la ainsi que tout ce qui en dérive, puis retestez.

Statut

Élément	Référence	Notes
MemAudit (audit a posteriori)	arXiv 2605.23723, mai 2026	Attribution causale + détection d’anomalies structurelles
Panorama de la menace	arXiv 2604.16548, 2026	Étude de la sécurité de la mémoire à long terme sur tout le cycle
Attaque représentative	arXiv 2512.16962 (MemoryGraft)	Compromission durable via récupération d’expérience empoisonnée
Prévention certifiée	arXiv 2606.12703 (SMSR), juin 2026	Défense préventive complémentaire avec borne de robustesse

Le glissement de fond va de « peut-on empêcher le poison d’entrer ? » à « peut-on le retrouver une fois entré ? ». Les deux questions comptent : la prévention réduit la probabilité, l’audit forensique borne les dégâts quand la prévention échoue. Pour tout agent qui écrit dans une mémoire durable, prévoyez les deux.