OWASP Agent Memory Guard : Empêchez l’exploitation malveillante de la mémoire des agents IA
Le poisoning de la mémoire des agents IA exploite le fait que ces agents sont à état persistant. Contrairement à un appel d’API traditionnel qui traite une entrée et retourne une sortie sans rien mémoriser, un agent conserve un état persistant entre les interactions. Cet état réside à plusieurs endroits : les historiques de conversation, les bases vectorielles interrogées pour le contexte via la recherche sémantique, les scratchpads où l’agent note ses raisonnements intermédiaires, et les index RAG qui relient l’agent aux référentiels documentaires de l’entreprise.
Tout attaquant disposant d’un accès en écriture à l’une de ces couches de stockage obtient un canal de commande sur le comportement futur de l’agent. L’attaque ne nécessite pas de compromettre le code de l’agent, les poids du modèle ou les identifiants API utilisés pour invoquer le modèle. Il suffit de pouvoir insérer une chaîne soigneusement conçue dans un stockage que l’agent lira ultérieurement.
La classification ASI06 de l’OWASP distingue le poisoning de la mémoire de l’injection de prompt classique en mettant l’accent sur la persistance. Une injection de prompt directe se produit en une seule session et s’arrête à la fermeture de celle-ci. Le poisoning de la mémoire survit à la fin des sessions, aux redémarrages de l’agent, voire aux redéploiements si la couche de stockage n’est pas effacée. Les outils de sécurité traditionnels n’ont aucune visibilité sur ce que l’agent stocke entre deux appels.
5 points clés à retenir
1. La mémoire des agents IA constitue une surface d’attaque non protégée dans la plupart des entreprises.
Les historiques de conversation, bases vectorielles, scratchpads et index RAG acceptent par défaut les écritures sans authentification ni vérification d’intégrité. Un attaquant ayant un accès en écriture à l’une de ces couches de stockage obtient un canal de commande persistant sur le comportement futur de l’agent — un canal qui survit à la fin des sessions, aux redémarrages et aux redéploiements si la couche de stockage n’est pas effacée. L’OWASP a formalisé ce point sous l’appellation ASI06 dans son Top 10 des applications agentiques. Les cadres de gouvernance des données n’ont pas encore intégré ce modèle de menace.
2. OWASP Agent Memory Guard atteint 92,5 % de rappel, 100 % de précision et une latence médiane de 59 microsecondes.
Cinq détecteurs — injection de prompt, fuite d’informations personnelles identifiables (PII/PHI) et de secrets, altération de clés, vérification d’intégrité SHA-256 et détection d’anomalie de taille — s’exécutent en ligne à chaque lecture et écriture en mémoire. Zéro faux positif signifie qu’aucune opération mémoire légitime n’est bloquée. Une latence médiane de 59 microsecondes permet une utilisation en production sans impact sur le débit. Ces chiffres rendent possible le déploiement en ligne, et pas seulement en analyse hors bande.
3. Le poisoning de la mémoire permet l’exfiltration via des workflows IA qui semblent parfaitement normaux.
Un agent manipulé peut exfiltrer des fichiers, appeler des API externes et transférer du contenu vers des points de terminaison contrôlés par l’attaquant — tout en semblant fonctionner normalement depuis l’interface utilisateur. Ce point est particulièrement important lorsque les agents IA interagissent avec des systèmes de partage sécurisé de fichiers et des pipelines MFT contenant des contrats, des données réglementées et de la propriété intellectuelle. Les outils de sécurité qui surveillent les comportements humains anormaux ne détectent pas ce type d’attaque.
4. L’application de l’ABAC limite l’ampleur des dégâts même en cas de réussite du poisoning de la mémoire.
Un agent dont la mémoire a été compromise et qui tente d’accéder à une base de données à laquelle il n’est pas autorisé se voit refuser l’accès au point d’application de la politique — l’instruction empoisonnée ne peut tout simplement pas s’exécuter. Les principes du zéro trust exigent que chaque accès à une ressource soit explicitement autorisé, qu’il s’agisse d’un utilisateur humain ou d’un agent IA. La défense mémoire bloque le poisoning ; le contrôle d’accès limite les dégâts si l’attaque aboutit malgré tout.
5. Un poisoning de la mémoire entraînant l’exfiltration de données réglementées constitue une violation à déclarer.
Une mémoire contenant des dossiers patients, des CUI ou des données personnelles est soumise à HIPAA, CMMC et RGPD, qu’il s’agisse d’une base de données classique ou d’un index vectoriel. Un poisoning de la mémoire qui conduit un agent à exfiltrer des données réglementées constitue un incident à déclarer dans le cadre de ces réglementations. Toute implémentation d’IA manipulant des données réglementées doit intégrer une couche de sécurité mémoire avant d’être exposée à une attaque.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Fonctionnement d’Agent Memory Guard
OWASP Agent Memory Guard agit comme une couche d’interception à l’exécution entre l’agent IA et ses backends mémoire. Chaque lecture et chaque écriture passent par une chaîne d’évaluation des politiques avant d’être validées. Cette chaîne exécute cinq détecteurs distincts en séquence :
Le détecteur d’injection de prompt analyse le contenu pour repérer les tentatives de contournement des instructions système ou d’injection de commandes dans le contexte de l’agent. Le détecteur de fuite de PII/PHI et de secrets signale tout contenu contenant des données personnelles, des identifiants ou des jetons. Le détecteur d’altération de clés identifie les modifications de matériel cryptographique. Le détecteur d’intégrité SHA-256 vérifie que le contenu mémoire n’a pas été modifié depuis son écriture initiale. Le détecteur d’anomalie de taille repère les écritures inhabituellement volumineuses pouvant indiquer des tentatives d’injection massive.
La politique est définie en YAML et prend en charge quatre actions : autoriser, masquer, mettre en quarantaine et bloquer. Lorsqu’une tentative de poisoning est détectée et bloquée, Agent Memory Guard permet de revenir à un état mémoire sain — une fonctionnalité que les simples journaux d’audit ne proposent pas. Les logs enregistrent ce qui s’est passé ; la restauration remet réellement l’agent dans un état opérationnel propre.
Le risque pour l’entreprise : la mémoire comme vecteur d’exfiltration
Les professionnels de la sécurité considèrent souvent les risques liés aux agents IA sous l’angle de ce que l’agent pourrait dire — hallucinations, atteintes à la vie privée, biais dans les résultats. Le poisoning de la mémoire introduit une nouvelle catégorie de risques : ce que l’agent pourrait faire. Un agent manipulé peut exfiltrer des fichiers, appeler des API externes, transférer du contenu vers des points de terminaison contrôlés par l’attaquant et augmenter ses droits d’accès — tout en semblant fonctionner normalement depuis l’interface utilisateur.
Ce vecteur d’exfiltration est particulièrement critique lorsque les agents IA interagissent avec des systèmes de partage sécurisé de fichiers, des pipelines de transfert sécurisé de fichiers et des référentiels documentaires structurés. Un agent qui lit dans un référentiel de contrats confidentiels et rédige des résumés dans un outil collaboratif fait son travail. Le même agent, après un poisoning de la mémoire, pourrait lire ce référentiel et envoyer le contenu brut — et non plus seulement des résumés — à une adresse contrôlée par l’attaquant.
Le Réseau de données privé Kiteworks répond à cette problématique au niveau du contrôle d’accès. L’application de l’ABAC garantit qu’un agent même totalement compromis ne peut accéder à des données en dehors des autorisations définies par la politique — l’identité de l’agent, son rôle et son contexte d’exécution doivent correspondre à la politique d’accès de la ressource avant toute lecture ou écriture.
Mettre en place une défense en profondeur pour la mémoire des agents IA
Les organisations qui déploient des agents IA dans des environnements réglementés font face à un défi spécifique : les cadres réglementaires qui encadrent la gestion des données — RGPD, HIPAA, CMMC 2.0 — n’ont pas été conçus pour l’IA agentique. Une mémoire contenant des dossiers patients, des CUI ou des données personnelles reste soumise à ces réglementations, qu’il s’agisse d’une base de données classique ou d’un index vectoriel.
OWASP Agent Memory Guard assure une protection à l’exécution. Le AI Data Gateway de Kiteworks propose un canal gouverné pour les interactions IA avec les données de l’entreprise, garantissant que les contenus sensibles ne transitent pas vers les systèmes ou mémoires IA via des chemins non contrôlés. Le Secure MCP Server contrôle quels outils IA peuvent interagir avec les données de l’entreprise. La gouvernance des données IA, en pratique, consiste à traiter la mémoire des agents IA comme n’importe quel autre stockage de données d’entreprise : la classifier, appliquer des contrôles d’accès, surveiller les accès et vérifier l’intégrité.
Pour en savoir plus sur la protection de vos données sensibles dans les workflows d’agents IA, réservez votre démo personnalisée dès aujourd’hui.
Foire aux questions
L’ASI06 est la classification OWASP des attaques de manipulation de la mémoire et de l’état contre les agents IA. Elle couvre les scénarios où un attaquant modifie un état persistant lu par l’agent — historique de conversation, contenu de base vectorielle, données de scratchpad et entrées d’index RAG — pour altérer le comportement lors des interactions suivantes. Elle distingue le poisoning de la mémoire de l’injection de prompt transitoire en mettant l’accent sur la persistance au-delà des sessions. OWASP Agent Memory Guard en est l’implémentation de référence. Les organisations qui développent de l’IA agentique doivent considérer l’ASI06 comme une menace majeure, au même titre que l’injection de prompt et l’exfiltration de données.
L’ABAC évalue chaque accès à une ressource selon une politique prenant en compte les attributs de l’entité demandeuse, de la ressource et de l’environnement d’exécution. Un agent dont la mémoire a été compromise et qui tente de lire une base de données à laquelle il n’est pas autorisé se voit refuser l’accès au point d’application de la politique — l’instruction empoisonnée ne peut pas s’exécuter. L’application de l’ABAC par Kiteworks intervient au niveau du protocole, ce qui garantit la restriction quel que soit le modèle IA ou l’orchestrateur utilisé. Cela limite réellement l’ampleur des dégâts et complète la défense mémoire à l’exécution.
La plupart des outils de sécurité classiques n’ont aucune visibilité sur la mémoire des agents IA. Les SIEM détectent des schémas d’appels API anormaux mais ne peuvent pas inspecter le contenu sémantique d’une écriture dans une base vectorielle pour déterminer si elle contient une commande injectée. Les solutions DLP détectent les schémas de données sensibles connus mais ne sont pas conçues pour analyser la syntaxe d’injection de prompt dans des fragments de documents. Agent Memory Guard comble cette lacune grâce à des détecteurs dédiés. La vérification d’intégrité SHA-256 est particulièrement précieuse — elle détecte le contenu altéré qui ne correspond à aucun schéma malveillant connu, simplement parce qu’il a changé après son écriture.
Toutes les données réglementées auxquelles un agent IA peut accéder sont concernées. Dans la santé, les agents ayant accès à des informations médicales protégées (PHI) exposent les entités couvertes par HIPAA à des risques de violation. Dans la défense, les agents traitant des CUI doivent répondre aux exigences CMMC qui supposent l’intégrité des données — l’exfiltration de CUI constitue un incident à déclarer selon le DFARS. Dans la finance, les agents manipulant des données PCI DSS sont exposés aux mêmes risques. Le poisoning de la mémoire transforme un workflow IA légitime et autorisé en un accès non autorisé aux données.
OWASP Agent Memory Guard inspecte et applique des politiques sur ce qui entre et sort des mémoires des agents. Le AI Data Gateway et le Secure MCP Server de Kiteworks contrôlent quelles sources de données d’entreprise les agents IA peuvent atteindre, quels outils ils peuvent utiliser et quels résultats ils peuvent produire. Un déploiement bien configuré utilise Agent Memory Guard pour empêcher le poisoning de la mémoire, et l’architecture zéro trust de Kiteworks pour limiter ce qu’un agent compromis peut faire si la défense mémoire est contournée.
Ressources complémentaires
- Article de blog
Stratégies Zero Trust pour une protection abordable de la confidentialité IA - Article de blog
Comment 77 % des organisations échouent à sécuriser les données IA - eBook
AI Governance Gap : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025 - Article de blog
Il n’existe pas de « –dangerously-skip-permissions » pour vos données - Article de blog
Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves concrètes.