Prévenir le Memory Poisoning : sécuriser la mémoire à long terme et vectorielle des agents IA

Le Memory Poisoning désigne l'injection ciblée de contenus manipulés dans la mémoire à long terme ou vectorielle d'un agent IA. Contrairement à une injection de prompt ponctuelle, qui n'agit qu'au sein d'une réponse, le contenu malveillant reste stocké de façon persistante. À chaque récupération ultérieure, il compromet le comportement de l'agent. L'OWASP Top 10 for Agentic Applications 2026 répertorie cette menace sous la référence ASI06 (Memory & Context Poisoning).

La différence décisive avec les simples chatbots : alors que ceux-ci oublient d'une session à l'autre, les systèmes agentiques entretiennent une mémoire persistante : historique des conversations, préférences des utilisateurs, contexte appris et bases RAG. C'est précisément ce qui crée une surface d'attaque permanente. L'attaquant injecte une fois, la charge malveillante continue d'agir indéfiniment et chaque session future hérite de la compromission.

• La persistance est le risque central : une seule écriture réussie peut empoisonner durablement la mémoire, et la manipulation survit à des semaines de fonctionnement normal.
• Le moment critique est la récupération, pas la saisie : le dommage ne survient pas lors de l'écriture, mais lorsque l'entrée empoisonnée est récupérée plus tard et traitée comme un contexte de confiance.
• La validation à l'écriture, la provenance et les audits de mémoire forment les trois piliers de la défense : aucune mesure isolée ne suffit.

Vecteurs d'attaque : comment les contenus arrivent dans la mémoire

Le Memory Poisoning exploite plusieurs points d'entrée, en partie combinables. L'agent ne sait pas distinguer de manière fiable instructions et données : chaque texte qu'il lit et enregistre fait partie de la surface d'attaque.

• Injection directe en mémoire : l'agent enregistre un contenu hostile avec un haut niveau de confiance, comme s'il s'agissait d'un fait appris.
• Empoisonnement de la base RAG : un contenu manipulé est introduit dans la base de connaissances référencée.
• Manipulation d'embeddings : des entrées adverses dans l'espace des embeddings déplacent la représentation sémantique.
• Delayed Tool Invocation : des phrases déclencheuses n'activent la charge malveillante que des semaines plus tard, tel un agent dormant dans la mémoire.
• Insertion dans la base vectorielle : les attaques visant des embeddings partagés entre tenants propagent l'empoisonnement au-delà des frontières entre tenants.

Risque de persistance : pourquoi la mémoire est plus dangereuse que la saisie

Ce qui rend le Memory Poisoning si insidieux, c'est le découplage temporel entre l'attaque et son effet. Une mémoire empoisonnée entraîne une dérive comportementale (behavioral drift) qui survient sans modification du code ou du modèle et échappe ainsi aux contrôles classiques de gestion des changements. La prépublication Hidden in Memory: Sleeper Memory Poisoning in LLM Agents de mai 2026 montre avec quelle fiabilité agissent les entrées empoisonnées qui ne se déclenchent que plus tard : des documents, des pages web ou des dépôts préparés ont amené des assistants LLM à enregistrer de faux souvenirs sur l'utilisateur. Une fois récupérées, ces entrées ont déclenché l'action d'agent voulue par l'attaquant dans 60 à 89 % des évaluations, selon le modèle.

En B2B, trois scénarios sont particulièrement pertinents :

• Assureur avec un agent de tri des sinistres : à partir d'un seul exemple empoisonné, l'agent apprend que « les assurés du code postal X doivent être validés en priorité ». Ce biais dormant survit à des semaines de fonctionnement normal.
• Opérateur d'infrastructure critique avec un agent de maintenance prédictive : à partir d'une télémétrie empoisonnée, l'agent apprend qu'un seuil de vibration est « normal », un piège dormant qui peut contribuer à une panne.
• Agent de conformité bancaire : la notion d'« activité suspecte » se déplace progressivement sous l'effet d'un empoisonnement prolongé de la mémoire de session.

Contre-mesures : quatre niveaux de défense

Une défense efficace contre le Memory Poisoning suit le principe de défense en profondeur, de la conception au développement, à l'exécution et à l'exploitation. Aucune couche ne suffit seule : c'est la combinaison qui compte.

La validation et la provenance au cœur du dispositif

Le levier le plus efficace se situe dans l'écriture elle-même. Chaque entrée de mémoire devrait porter des métadonnées de provenance : source, horodatage, chemin d'ingestion et score de confiance. Lors de la récupération, un score de fiabilité de la source pondère les entrées selon leur degré de confiance. Les entrées qui ne peuvent être rattachées à aucune source vérifiable ne doivent pas être traitées comme des connaissances avérées. Les contenus devraient être validés avant l'embedding et étiquetés par niveau de confiance, par exemple « vérifié en interne », « externe non confirmé », « généré par l'utilisateur ».

Séparation des sources de confiance et cloisonnement des tenants

Les bases vectorielles ont besoin de contrôles d'accès au niveau des lignes ou des namespaces. Les stores d'embeddings ne doivent jamais être partagés entre tenants : chaque tenant dispose de son propre index vectoriel. La mémoire est chiffrée au repos, idéalement avec des clés gérées par le client. Contre l'inversion d'embeddings, la limitation de la fréquence des requêtes, la confidentialité différentielle appliquée aux embeddings et la détection d'anomalies dans l'espace des embeddings sont efficaces.

Audits de mémoire et signaux de détection

Les audits de mémoire contrôlent les contenus par échantillonnage et vérifient leur provenance. Les signaux suivants indiquent un empoisonnement :

• Dérive du comportement de référence de l'agent sans modification du code ou du modèle.
• Entrées de mémoire invérifiables, sans enregistrement de provenance.
• Valeurs aberrantes sémantiques dans la base vectorielle.
• L'agent affirme « se souvenir » d'instructions pour lesquelles aucun enregistrement de provenance n'existe.

Une journalisation d'audit complète pour chaque action de l'agent (situation en 2026) devrait couvrir au minimum les événements d'écriture et de lecture en mémoire, les requêtes de récupération avec les identifiants des documents renvoyés ainsi que la justification de la décision, idéalement sous forme de logs WORM (write-once-read-many) avec signature cryptographique pour détecter toute manipulation.

Exemple concret : Delayed Tool Invocation

La Google Gemini Memory Attack (février 2025, documentée par Johann Rehberger) illustre parfaitement le mécanisme. Un document téléversé contenait des prompts cachés qui demandaient à Gemini de n'enregistrer de fausses informations qu'au moment où des mots déclencheurs comme « yes », « no » ou « sure » apparaîtraient dans une conversation future. Résultat : Gemini « se souvenait » du chercheur comme d'un platiste de 102 ans. Google a classé le risque comme lié à un usage abusif, avec une faible probabilité et un faible impact.

En pseudo-code, l'attaque peut se résumer ainsi :

```

Phase 1. Injection (une seule fois, via un document manipulé)

SI saisie_utilisateur CONTIENT mot_declencheur ("yes" | "no" | "sure"):
memory.ecrire(entree="L'utilisateur a 102 ans", confiance=haute)
# aucun enregistrement de provenance, aucune validation à l'écriture

Phase 2. Activation (des semaines plus tard, dans n'importe quelle session)

à la récupération : memory.lire("Profil utilisateur")
-> renvoie l'entrée empoisonnée comme un fait avéré
```

Une défense avec validation à l'écriture aurait rejeté l'entrée dès la phase 1 : aucun enregistrement de provenance traçable, source externe et non vérifiée, niveau de confiance faible. Lors de la récupération en phase 2, la pondération selon la fiabilité de la source aurait déclassé l'entrée. Dans le Calendar Invite Poisoning (Targeted Promptware Attacks, 2025), des invitations d'agenda manipulées ont implanté des instructions persistantes dans les « Saved Info » de Gemini. Les auteurs ont classé 73 % des menaces analysées entre High et Critical (Nassi et al. 2025). Les 14 scénarios vont du spam au pilotage d'appareils domotiques.

Ancrage réglementaire en Allemagne et en Autriche

Le Memory Poisoning est un sujet à la fois technique et réglementaire. Sur le fond, ASI06 correspond à la technique MITRE ATLAS AML.T0080 (AI Agent Context Poisoning), et le Memory Poisoning en particulier à la sous-technique AML.T0080.000 (Memory). Toutes deux ont été ajoutées lors de la collaboration avec Zenity d'octobre 2025. Étroitement liée, la technique AML.T0020 (Poison Training Data), qui existait déjà auparavant, en constitue l'équivalent côté entraînement et se situe en amont d'ASI06. Le document de l'OWASP consacré au Top 10 for Agentic Applications rattache lui-même ASI06 à la menace T1 Memory Poisoning du guide OWASP Agentic AI Threats and Mitigations. Pour les déployeurs en Allemagne et en Autriche, les points d'ancrage suivants sont pertinents (situation en 2026) :

• RGPD : art. 5(1)(d) (exactitude), art. 17 (droit à l'effacement), art. 32 (mesures techniques et organisationnelles).
• Règlement européen sur l'IA : art. 10 (gouvernance des données) et art. 15 (cybersécurité), tous deux uniquement pour les systèmes d'IA à haut risque. Les attaques par inversion d'embeddings ne sont pas encore codifiées spécifiquement dans les normes : c'est au déployeur de combler cette lacune.
• ISO/IEC 42001 : A.7 (données pour les systèmes d'IA), A.7.4 (qualité des données), A.6.2.8 (journalisation).

Les procédures d'effacement de la mémoire doivent être alignées sur l'art. 17 du RGPD. Le droit à l'effacement s'applique aux données personnelles quel que soit leur lieu de stockage, donc aussi aux mémoires persistantes des agents et aux stores d'embeddings, dès lors qu'ils contiennent des données personnelles.

Pour les agences et les décideurs B2B

Si tu utilises une IA agentique pour des clients ou dans ta propre entreprise, tu ne devrais pas traiter la sécurité de la mémoire comme un détail secondaire. Avant chaque déploiement, clarifie trois questions : quelles sources ont le droit d'écrire dans la mémoire persistante ? Chaque entrée porte-t-elle des métadonnées de provenance ? Les index des différents tenants sont-ils proprement séparés ? Pour les agences marketing et digitales qui exploitent des systèmes agentiques pour plusieurs clients, l'isolation des bases vectorielles entre tenants est le levier le plus important : une contamination de la mémoire entre tenants représente à la fois un risque de confiance et un risque de responsabilité. Blck Alpaca aide les entreprises en Europe à mettre en place la validation de la mémoire, des concepts de provenance et des audits de mémoire réguliers selon OWASP ASI06, le règlement européen sur l'IA et le RGPD, de manière pragmatique et prête pour l'audit.