ASI06 : empoisonnement de la mémoire et du contexte d’un agent

ASI06, sixième entrée du Top 10 OWASP des applications agentiques, traite de ce qu’un agent retient. La mémoire est ce qui le rend utile : sans elle, il recommence chaque tâche en terrain vierge, redemande ce qu’on lui a déjà dit et perd le fil d’un travail long. Avec elle, il acquiert un passé — et ce passé devient une surface d’attaque durable, parce qu’une fausseté qui s’y installe ressort en décision pendant des semaines, longtemps après que la source a disparu.

→ Lire l’explication complète de la marmotte

Le mécanisme : la persistance change tout

Le référentiel définit le contexte largement : tout ce que l’agent retient, récupère ou réutilise. L’historique de conversation, les résumés qu’il fabrique de ses propres échanges, un outil de mémoire explicite, les embeddings et les magasins documentaires interrogés par récupération augmentée. Il en exclut un seul élément, et cette exclusion est la frontière de l’entrée : le prompt d’entrée ponctuel, qui relève de l’injection de prompt du Top 10 LLM.

L’empoisonnement consiste à corrompre ou à ensemencer ce stock. Les sources d’ingestion sont rarement vérifiées de bout en bout : téléversements, flux d’API, saisie utilisateur, échanges avec des agents pairs. Chacune peut n’être validée qu’en partie, et il suffit d’un canal où elle ne l’est pas.

Ce qui distingue cette classe des injections ordinaires est la durée. Une injection de prompt vit le temps d’une requête ; un empoisonnement de mémoire vit le temps de la rétention. Le référentiel décrit plusieurs manières d’y parvenir, et la plus sournoise ne demande aucun accès d’écriture : la manipulation de la fenêtre de contexte. L’attaquant injecte du contenu dans une conversation en cours, sachant que l’agent va la résumer et persister le résumé. Le contenu brut disparaît, le résumé reste, et la contamination survit à la session qui l’a vue naître. Les mécanismes de la mémoire et de son nettoyage sont décrits sur le site dans la mémoire persistante d’un assistant IA, et la question de la fenêtre dans le contexte long et la mémoire d’un LLM.

Une variante mérite son nom : la dérive lente. Par exposition répétée à des données, des résumés ou des retours de pairs légèrement altérés, les connaissances stockées et la pondération des objectifs se déplacent progressivement. Aucun événement n’est détectable, chaque pas est plausible, et seule la comparaison avec un état ancien révèle le trajet parcouru. C’est le mécanisme qui ressemble le plus à la manière dont on manipule un humain, et il n’est pas moins efficace.

Ce qui distingue ASI06 de ses voisins

Le référentiel place ASI06 au milieu d’une séquence temporelle, et cette lecture est la plus utile :

ASI01, détournement d’objectif, est la manipulation directe du but en cours : l’attaquant agit maintenant, sur ce plan-ci ;
ASI06 est la corruption durable de ce qui est stocké : l’attaquant agit une fois, le système se trompe ensuite tout seul ;
ASI08, défaillances en cascade, est la dégradation qui suit : la propagation du défaut, une fois l’empoisonnement fait.

Le document note explicitement que l’empoisonnement de mémoire conduit fréquemment au détournement d’objectif, puisqu’un contexte corrompu altère l’interprétation du but, le chemin de raisonnement et la logique de sélection d’outils. Les deux entrées ne sont donc pas alternatives : ASI06 est souvent la cause, ASI01 l’effet. Dans la taxonomie du projet, l’entrée correspond à T1, empoisonnement de mémoire, avec des impacts liés en T4 (surcharge de mémoire), T6 (objectifs rompus) et T12 (empoisonnement de mémoire partagée).

Ce que ça donne en pratique

Le référentiel propose des scénarios qui ont le mérite d’être concrets et d’éviter le pittoresque.

Le faux fait renforcé. Un attaquant répète une information jusqu’à ce que l’assistant la retienne comme vraie : un tarif, un seuil, une règle interne. L’assistant l’applique ensuite de bonne foi et contourne les contrôles qui dépendaient de cette valeur. Le poison n’est pas une instruction, c’est une donnée — et aucun filtre d’injection ne la reconnaîtra, puisqu’elle n’a pas la forme d’un ordre.

L’étalement sur plusieurs sessions. Les demandes successives sont réparties dans le temps, de sorte que les refus antérieurs sortent de la fenêtre de contexte. L’agent, ne voyant plus qu’il a déjà dit non trois fois, accorde des permissions croissantes. C’est une attaque contre l’oubli, et elle exploite une propriété qu’on avait achetée pour des raisons de coût.

L’empoisonnement de la mémoire partagée. De fausses règles de remboursement insérées dans une mémoire commune sont réutilisées par tous les agents qui la consultent. Un seul point d’écriture, dix agents trompés : la mémoire partagée est un multiplicateur, ce qui explique sa présence dans la taxonomie sous un code distinct.

La fuite par voisinage vectoriel. Un attaquant sème du contenu dupliqué qui exploite des filtres de cloisonnement trop laxistes, et fait remonter par similarité un fragment appartenant à un autre locataire. Ce n’est pas une injection mais une récupération abusive, décrite sur le site dans la fuite par recherche sémantique et, pour les mécanismes sous-jacents, dans les embeddings.

L’empoisonnement du gardien. Le cas le plus déplaisant, et le référentiel le mentionne sans détour : réécrire la mémoire d’un agent de sécurité pour qu’il étiquette une activité malveillante comme normale. La supervision n’échoue pas bruyamment, elle approuve.

Des cas publics existent. Le suivi d’incidents du référentiel renvoie à des travaux documentés sur la corruption de la mémoire long terme d’un assistant grand public par injection de prompt, ainsi qu’à la plantation de fausses mémoires persistantes dans un autre. La littérature académique, citée dans le document, a aussi produit des méthodes d’empoisonnement ciblé de bases de connaissances d’agents.

Réduire : valider à l’écriture, douter à la lecture

Les mitigations du référentiel se répartissent en deux moments, et c’est la bonne façon de les lire.

À l’écriture, il s’agit de ne pas laisser n’importe quoi entrer. Scanner toutes les écritures en mémoire et les sorties de modèle, par règles et par modèle, avant validation. N’accepter que des sources authentifiées et curées. Exiger une attribution de source pour chaque élément stocké — c’est-à-dire savoir d’où vient ce que l’agent croit. Et, recommandation la plus importante du lot : empêcher la réingestion automatique des propres sorties de l’agent dans la mémoire de confiance. Sans cela, le système fabrique lui-même les preuves de ses erreurs, et le document nomme la boucle avec justesse. Les contrôles d’admission applicables à un corpus sont détaillés dans sécuriser un corpus RAG contre l’injection indirecte.

À la lecture, il s’agit de ne pas traiter la mémoire comme une vérité. Cloisonner par locataire et par domaine, isoler les sessions utilisateur, pondérer la récupération par un score de confiance et par l’appartenance — le référentiel suggère d’exiger deux facteurs concordants pour faire remonter un élément à fort impact. Faire décroître ou expirer la mémoire non vérifiée, pour que le poison ne persiste pas : c’est le seul contrôle qui limite la durée du dégât sans supposer qu’on l’ait détecté.

S’y ajoutent les mesures ordinaires dont l’absence serait pourtant fatale : chiffrement en transit et au repos, accès au moindre privilège, rétention minimisée selon la sensibilité, instantanés et contrôle de version permettant un retour arrière, quarantaine des entrées suspectes, et revue humaine pour les actions à haut risque. Les tests adverses, enfin, parce qu’une mémoire ne se vérifie pas à la lecture mais à l’usage.

Détecter : regarder les écritures, pas les réponses

Un empoisonnement se repère mal du côté des sorties, où il se confond avec une hallucination ordinaire : l’agent affirme une chose fausse avec le même aplomb dans les deux cas. Il se repère beaucoup mieux du côté des écritures, et c’est ce que recommande le référentiel sous le nom de provenance et anomalies.

Trois mesures suffisent à rendre la classe observable. Journaliser chaque écriture en mémoire avec sa source, son horodatage et la tâche qui l’a produite — un journal d’écritures, pas seulement un journal d’actions. Surveiller les fréquences : une même affirmation qui revient d’une source unique à intervalles réguliers n’est pas un comportement d’utilisateur, c’est un renforcement. Et comparer périodiquement l’état de la mémoire à un instantané antérieur, pour voir ce qui a changé sans qu’on le demande.

À quoi s’ajoute une vérification qu’on néglige systématiquement : savoir ce que contient réellement la mémoire d’un agent en production. L’exercice est instructif et rarement agréable, un peu comme la lecture des journaux dont personne ne s’occupe. La plupart des équipes découvrent à cette occasion qu’elles ne disposaient d’aucun moyen simple d’en lire le contenu, ce qui répond par avance à la question de savoir si quelqu’un l’avait vérifié.

Ce que ces mesures ne font pas

Elles ne détectent pas la dérive lente. Un score de confiance arbitre entre deux sources contradictoires ; il ne remarque pas qu’une même source a bougé de deux degrés par semaine. La seule contre-mesure réellement efficace est la comparaison à un état de référence, ce qui suppose de conserver des instantanés datés et d’avoir le courage de les comparer — opération que personne ne planifie et que tout le monde regrette.

Elles ne résolvent pas non plus la tension de fond : une mémoire qui expire perd son intérêt, une mémoire qui persiste garde le poison. Le compromis se règle par sensibilité, pas en principe. Un agent qui retient des préférences d’affichage peut tout garder ; un agent qui retient des seuils d’approbation ne devrait rien garder de ce qu’il n’a pas reçu d’une source d’autorité — et, à la réflexion, ne devrait pas retenir de seuils d’approbation du tout. C’est encore la moindre agentivité : la question n’est pas comment protéger cette mémoire, mais pourquoi cette information était en mémoire.

🐝 Ce qui arrive si on s’en passe

Sans attribution de source sur les éléments stockés, aucune enquête n’est possible : la mémoire contient des affirmations sans provenance, et rien ne distingue ce que l’utilisateur a dit de ce qu’un document a prétendu ou de ce que l’agent a déduit. Il devient alors impossible de purger sélectivement après la découverte d’un empoisonnement, et le seul geste disponible est l’effacement complet, qui emporte aussi tout ce qui était vrai. Sans expiration de la mémoire non vérifiée, un élément introduit une fois reste actif tant que personne ne le lit à voix haute — c’est-à-dire indéfiniment, puisque personne ne relit une mémoire d’agent. Sans blocage de la réingestion des sorties de l’agent, enfin, une erreur unique se cite elle-même au tour suivant et devient une source : au bout de quelques cycles, le système dispose de plusieurs occurrences concordantes de la même fausseté, ce que tout mécanisme de confiance interprétera comme une confirmation.

🦫 Explication de la marmotte 🍫

Un assistant informatique utile se souvient. Il retient ce qu’on lui a dit, les documents qu’il a consultés, les résumés qu’il a faits de ses conversations. C’est cette mémoire qui lui évite de tout redemander à chaque fois. Le risque décrit ici est qu’on y dépose une fausseté, qui s’y installe et ressort ensuite en décision, pendant très longtemps.

Il y a plusieurs façons d’y parvenir, et la plus efficace ne demande rien de technique : répéter une information fausse jusqu’à ce que l’assistant la retienne comme un fait. Un tarif, un seuil, une règle interne. Ensuite, il l’applique de bonne foi, et les contrôles qui dépendaient de cette valeur ne protègent plus rien. Une autre façon consiste à étaler ses demandes sur plusieurs jours, pour que l’assistant oublie les refus qu’il a déjà opposés.

Ce qui rend ce risque particulier, c’est la durée. Une consigne piégée dans un document agit une fois ; une mémoire empoisonnée agit tous les jours, et longtemps après que le document a été supprimé. Dans un système où plusieurs assistants partagent la même mémoire, une seule entrée fausse trompe tout le monde.

Les protections tiennent en deux gestes. À l’écriture : ne retenir que ce qui vient de sources identifiées, conserver pour chaque élément d’où il vient, et ne jamais laisser l’assistant archiver ses propres conclusions comme s’il s’agissait de faits établis. À la lecture : ne pas traiter la mémoire comme une vérité, cloisonner celle de chaque utilisateur, et faire expirer ce qui n’a jamais été vérifié — c’est le seul moyen de limiter la durée du dégât sans avoir besoin de s’apercevoir qu’il a eu lieu.

Pages voisines

La citent

ASI06 : empoisonnement de la mémoire et du contexte d'un agent

Elle cite

: les deux pages se citent l’une l’autre.