Les agents IA n’agissent pas seulement. Ils se souviennent.
La gouvernance de l’IA en entreprise a passé l’année dernière à rattraper une réalité simple : les outils IA ne sont plus de simples fenêtres de chat. Ils sont connectés à des fichiers, tickets, calendriers, CRM, dépôts de code et bases de connaissances internes. Ils peuvent récupérer du contexte, appeler des outils, résumer des décisions et agir.
Cela crée déjà un problème de gouvernance. Mais le risque suivant est plus subtil.
Les agents IA n’agissent pas seulement. Ils se souviennent.
La mémoire devient une fonctionnalité par défaut dans les systèmes IA d’entreprise. Les agents doivent retenir préférences, contexte de projet, historique utilisateur, schémas de workflow, décisions passées et parfois contexte métier sensible. C’est utile. Cela change aussi le modèle de sécurité.
Un mauvais prompt était un risque ponctuel. Une mauvaise mémoire peut persister.
Pourquoi la mémoire des agents est différente de l’historique de chat
La plupart des équipes de sécurité savent qu’elles ont besoin de visibilité sur les prompts et sorties IA. Elles veulent savoir quels outils les employés utilisent, quelles données y sont collées, et si des informations sensibles quittent l’organisation.
C’est nécessaire, mais insuffisant pour l’IA agentique.
L’historique de chat est généralement un enregistrement de ce qui s’est passé. La mémoire d’agent est un contexte opérationnel qui peut influencer ce qui se passe ensuite.
Si un agent stocke la mauvaise information, la fuit ou récupère la mauvaise chose au mauvais moment, le risque ne se limite plus à une conversation. Il peut influencer des actions futures sur plusieurs sessions.
Cela crée trois risques pratiques pour l’entreprise :
- Des données sensibles peuvent passer d’un système protégé à une couche mémoire moins gouvernée
- Des hypothèses obsolètes ou incorrectes peuvent persister après que la source originale a changé
- Une mémoire compromise ou manipulée peut affecter des décisions futures sans déclencheur évident
Pour les RSSI, c’est inconfortable car la couche mémoire se situe souvent entre les contrôles traditionnels. Ce n’est pas toujours une base de données surveillée par l’équipe sécurité. Ce n’est pas toujours un document dans vos règles DLP. Ce n’est pas toujours une application SaaS avec des logs d’administration clairs.
Mais elle peut contenir un contexte critique pour l’entreprise.
Le problème d’accès caché
La mémoire des agents complique le contrôle d’accès car elle peut brouiller la frontière entre ce qu’un utilisateur est autorisé à voir et ce que l’agent a déjà appris.
Imaginez qu’un employé demande à un assistant IA de résumer un plan de compte confidentiel. L’employé est autorisé à le voir. L’assistant stocke un contexte utile de cette interaction pour être plus efficace plus tard.
Puis l’employé change d’équipe. Son accès au plan de compte original est supprimé.
Que devient la mémoire de l’agent ?
Si la mémoire contient toujours un résumé, des risques clés, un contexte tarifaire, des objections clients ou une stratégie interne, l’organisation a peut-être conservé l’accès à des informations que l’utilisateur ne devrait plus voir.
Ce n’est pas un cas théorique. C’est le schéma normal d’adoption de l’IA en entreprise : les assistants deviennent plus utiles quand ils portent le contexte. Les équipes sécurité doivent alors répondre à une nouvelle question :
La révocation des permissions supprime-t-elle aussi le contexte mémorisé par l’agent ?
Dans beaucoup d’organisations, la réponse honnête est : personne ne sait.
L’empoisonnement de mémoire est la nouvelle injection de prompt
L’injection de prompt est déjà connue des équipes de sécurité IA. Un attaquant cache des instructions dans un document, une page web, un ticket, un email ou un commentaire de code. Le système IA les lit et suit des instructions non prévues par l’utilisateur.
La mémoire ajoute une autre dimension.
Si un attaquant parvient à stocker des instructions malveillantes ou un faux contexte dans la mémoire d’un agent, l’attaque peut survivre au-delà de l’interaction initiale. L’agent peut ensuite récupérer cette mémoire et agir comme si c’était un contexte fiable.
Cela importe car les agents d’entreprise sont de plus en plus connectés à des outils :
- Systèmes de messagerie et calendriers
- Plateformes de ticketing
- Dépôts de code source
- Stockages de documents
- CRM et dossiers clients
- Automatisation interne des workflows
Une mémoire empoisonnée n’a pas besoin de crier « ignorer les instructions précédentes » à chaque fois. Elle peut être plus subtile : une préférence fausse, une exception de politique fictive, une contrainte client incorrecte ou une description trompeuse des autorisations d’un système.
Le risque n’est pas que chaque mémoire devienne malveillante. Le risque est que la plupart des organisations n’ont aucune trace d’audit sur la création, modification, récupération ou utilisation de la mémoire.
L’angle conformité : conservation sans intention
La mémoire des agents complique aussi les obligations de conservation et de confidentialité.
Les équipes sécurité et conformité pensent habituellement en termes d’enregistrements : emails, fichiers, bases de données, logs, tickets. Ces systèmes ont des propriétaires, des politiques de conservation, des contrôles d’accès et des workflows de suppression.
La mémoire des agents peut être plus désordonnée.
Elle peut contenir des fragments de données personnelles, contexte client, préférences employés, informations commerciales ou données réglementées. Elle peut être créée automatiquement. Elle peut être résumée plutôt que copiée textuellement. Elle peut être stockée par un fournisseur, une plateforme interne ou un assistant intégré dans un autre produit.
Cela soulève des questions pratiques :
- Quels types de données les agents sont-ils autorisés à mémoriser ?
- Combien de temps cette mémoire doit-elle être conservée ?
- Qui peut l’inspecter, la corriger ou la supprimer ?
- La mémoire est-elle incluse dans les workflows d’accès, de suppression ou de découverte des données personnelles ?
- L’organisation peut-elle prouver quelle mémoire a influencé une action ?
Si ces questions ne sont pas réglées avant le déploiement, l’organisation ne gouverne pas la mémoire IA. Elle espère que les fournisseurs ont fait les bons choix par défaut.
À quoi ressemble une bonne gouvernance
La réponse n’est pas d’interdire la mémoire. La mémoire est une des raisons pour lesquelles les agents IA deviennent vraiment utiles. La réponse est de traiter la mémoire comme une couche de données d’entreprise gouvernée, pas comme une simple fonctionnalité pratique.
Un modèle de gouvernance pratique doit inclure cinq contrôles.
1. Inventorier chaque agent avec mémoire
Commencez par les bases. Quels systèmes IA peuvent mémoriser le contexte utilisateur ? Quelles fonctionnalités sont activées par défaut ? Quelles équipes les utilisent ? Quels fournisseurs stockent la mémoire en externe ?
Cela doit inclure les outils sanctionnés et l'IA fantôme. Les employés expérimentent souvent avec des créateurs d'agents, des assistants de navigateur, des outils de workflow et des comptes IA personnels avant que le service informatique ne les ait approuvés.
Si vous ne pouvez pas inventorier les agents dotés de mémoire, vous ne pouvez pas gouverner les données qu'ils conservent.
2. Classifier ce que la mémoire peut contenir
Toutes les mémoires ne se valent pas.
Se souvenir qu'un utilisateur préfère des résumés courts présente un faible risque. Se souvenir de la stratégie tarifaire client, des conseils juridiques, des détails de réponse aux incidents ou de l'architecture du code source ne l'est pas.
Les équipes de sécurité doivent définir des catégories claires :
- Mémoire autorisée : préférences, mise en forme, contexte de workflow inoffensif
- Mémoire restreinte : données clients, informations financières, résultats de sécurité, contexte juridique
- Mémoire interdite : secrets, identifiants, données personnelles réglementées, stratégie confidentielle, détails d’incidents
L’objectif n’est pas une politique de façade. L’objectif est de fournir aux équipes techniques des limites applicables.
3. Relier la mémoire aux changements d’identité et d’accès
Lorsqu’un rôle utilisateur change, le contexte mémorisé par l’agent ne doit pas devenir une faille.
Au minimum, les entreprises doivent revoir le comportement de la mémoire lorsque :
- Un utilisateur quitte l’entreprise
- Un utilisateur change de rôle ou d’équipe
- L’accès à un système source est révoqué
- Un projet se termine
- Un compte client change de propriétaire
Si la suppression d’accès n’affecte pas la mémoire stockée, des contrôles compensatoires sont nécessaires.
4. Journaliser la création, la mise à jour, la récupération et la suppression de la mémoire
Si un agent IA agit en fonction de la mémoire, les équipes de sécurité doivent avoir une visibilité sur cette chaîne.
Les journaux utiles doivent répondre à :
- Quelle mémoire a été créée ?
- Quelle source l’a créée ?
- Quand a-t-elle été mise à jour ?
- Quel utilisateur ou système l’a récupérée ?
- A-t-elle influencé un appel d’outil ou une action métier ?
- A-t-elle été supprimée ou conservée ?
Sans cela, les enquêtes deviennent des conjectures.
5. Tester la mémoire dans le cadre des tests de sécurité IA
La plupart des tests de sécurité IA se concentrent sur les prompts, les jailbreaks, les sorties non sécurisées et les mauvais usages d’outils. La mémoire doit faire partie du plan de test.
Les équipes doivent tester si un agent peut être amené à mémoriser des données sensibles, conserver des instructions empoisonnées, récupérer un contexte au-delà des droits d’accès, ou utiliser une mémoire obsolète après modification de la source.
C’est particulièrement important pour les agents connectés à des workflows à fort impact : communications clients, développement logiciel, finance, RH, juridique et opérations de sécurité.
La question au niveau du conseil d’administration
La gouvernance de l’IA commençait par une question simple : quels outils IA les employés utilisent-ils ?
Cette question est désormais trop limitée.
La meilleure question est :
Que notre IA a-t-elle appris, où est-ce stocké, qui y a accès, et comment cela influence-t-il les actions futures ?
C’est le vide de gouvernance créé par la mémoire des agents.
Les entreprises ne doivent pas paniquer. Mais elles doivent cesser de considérer la mémoire comme un simple paramètre produit et commencer à l’intégrer dans l’architecture de sécurité.
Car une fois que les agents se souviennent, le rayon d’impact change.
Aona aide les entreprises à découvrir l’IA fantôme, gouverner les workflows agentiques et mettre en place des contrôles pratiques sur l’accès et l’utilisation des données métier par les systèmes IA. Si votre organisation déploie des agents IA avec mémoire, c’est le moment de rendre cette mémoire visible, auditable et gouvernée.
