Prenez la définition d’une base de données, sans le mot.
Un système qui conserve de l’état. Cet état est relu plus tard. Ce qui est relu influence des décisions. L’état survit à la session qui l’a créé, et plusieurs consommateurs y accèdent.
C’est exactement ce que sont un magasin RAG et une mémoire d’agent persistante.
Maintenant, la liste des contrôles qu’une base de données reçoit dans votre organisation. Un schéma. Des droits en écriture distincts des droits en lecture. Un journal d’audit. Des sauvegardes. Une procédure de restauration. Quelqu’un dont le nom apparaît quand une valeur est fausse.
Un magasin vectoriel a généralement une clé d’API et un processus d’ingestion que personne n’a relu depuis sa mise en place.
Ce que l’OWASP en dit
ASI06, empoisonnement de mémoire et de contexte, dans le Top 10 pour les applications agentiques.
Le motif documenté est direct, et il n’a rien de spéculatif. Un attaquant place une information fausse dans une mémoire partagée : des conditions de remboursement inventées, une grille de prix modifiée, une procédure interne qui n’a jamais existé. Les agents en aval la récupèrent plus tard et la traitent comme un fait établi.
Ce qui rend le motif efficace n’est pas sa sophistication. C’est la manière dont le contenu récupéré entre dans le contexte : au même titre que le reste, sans marqueur de provenance, sans date, sans indication de qui l’a écrit ni quand.
L’agent n’a aucun moyen de pondérer un fait selon sa source, parce que la source n’est pas transmise.
La différence avec l’injection de prompt
Les deux se ressemblent et se traitent différemment, donc la distinction vaut la peine.
Une injection de prompt agit pendant la session où elle est livrée. Elle est puissante et elle est bornée dans le temps.
Un empoisonnement de mémoire agit à chaque session suivante. Il persiste, il se propage aux autres agents qui partagent le magasin, et il ne laisse pas de trace dans le contexte où il produit son effet — au moment où l’agent prend une mauvaise décision, la donnée fausse est là depuis longtemps et ressemble à toutes les autres.
Ça continue jusqu’à ce que quelqu’un remarque. Dans la plupart des déploiements, personne n’a la responsabilité de remarquer.
L’angle qu’on manque : l’empoisonnement sans attaquant
Le cas hostile est le plus facile à faire financer et le moins fréquent.
Une mémoire d’agent se dégrade toute seule. Une information exacte y entre, puis cesse de l’être : un prix change, une procédure est révisée, une personne quitte l’organisation, un système est décommissionné.
Rien dans le magasin ne l’indique. La donnée périmée a exactement la même apparence que la donnée courante, et elle est récupérée avec la même confiance.
C’est pour cette raison que la durée de vie est un contrôle de sécurité et pas seulement une question d’hygiène. Sans expiration, un magasin de mémoire accumule les erreurs de manière monotone : les faits corrects y restent, les faits devenus faux aussi, et la proportion se dégrade dans une seule direction.
Les trois contrôles
Aucun n’est exotique. Ce sont ceux qu’on applique déjà à un magasin de données, transposés.
L’écriture est une opération privilégiée. Séparez le droit d’écrire du droit de lire, et accordez-les séparément. Dans beaucoup de déploiements, tout composant capable de lire la mémoire peut aussi y écrire, parce que la bibliothèque n’a pas rendu la distinction visible. C’est le contrôle qui rapporte le plus, et c’est souvent une ligne de configuration.
La provenance accompagne chaque élément. Qui l’a écrit, quand, à partir de quelle source. Ça sert à deux moments : pour pondérer un fait au moment de la récupération, et pour répondre après coup à « d’où vient ceci » — la question qui décide de la durée d’une investigation.
Une durée de vie sur ce qui persiste. Elle force la revalidation. Elle transforme la dégradation silencieuse décrite plus haut en un événement qui se produit à un moment connu.
À quoi s’ajoute une chose qui n’est pas technique : quelqu’un doit être propriétaire du contenu de ce magasin, au même titre qu’une base de données de production a un propriétaire. Sans ça, les trois contrôles précédents existent dans la configuration et personne ne regarde ce qu’ils produisent.
La question à poser
Qui peut écrire dans la mémoire de vos agents ?
Et, celle qui est plus révélatrice : si quelqu’un y avait écrit quelque chose le mois dernier, est-ce que vous pourriez le savoir aujourd’hui ?
Besoin d’aide pour mettre cela en œuvre ?
Nous travaillons avec votre équipe pour concevoir, construire et exploiter les contrôles décrits ci-dessus.