Les agents IA dormants détiennent toujours les clés de vos données

Un agent IA inutilisé peut toujours lire vos données, et continuera tant que personne n’aura la responsabilité de le désactiver. Ce n’est pas une expérience de pensée, mais bien le constat dressé lorsqu’un fournisseur de sécurité a examiné des milliers d’agents déployés dans les environnements de production de ses clients : la plupart des agents activés s’étaient simplement tus.

Le rapport 2026 sur les menaces liées aux agents autonomes d’Arrakis Security, relayé par Help Net Security le 26 octobre 2026, décrit des agents arrêtés depuis des semaines ou des mois, mais qui conservent leurs identifiants, leurs déclencheurs et leurs connexions à des systèmes sensibles. Personne ne les a désactivés. Dans la plupart des cas, personne n’en avait la charge. Pour un RSSI ou un Chief Compliance Officer, ce détail compte plus que n’importe quel pourcentage, car il transforme une question d’hygiène technique en problème de responsabilité.

Les régulateurs encadrent les données, pas les modèles. Un auditeur HIPAA, une autorité de contrôle RGPD ou un évaluateur CMMC ne s’intéresse pas à la popularité d’un agent le trimestre précédent. Ils veulent savoir qui ou quoi peut accéder à des données réglementées, qui l’a autorisé, et quelles preuves l’attestent. Un agent oublié qui peut toujours accéder à un bucket cloud constitue un accès non revu, à intégrer dans toute discussion sur la gouvernance des données IA au même titre que les agents actifs. Cet article détaille les constats du rapport, ses limites, pourquoi les agents inactifs posent un problème de preuve plus qu’un simple problème de sécurité, et à quoi ressemble un cycle de vie défendable.

Points clés à retenir

1. Inactif ne veut pas dire inoffensif.

Un agent qui n’a pas tourné depuis des mois peut toujours détenir des identifiants actifs, des déclencheurs opérationnels et des connexions à des systèmes sensibles. L’inactivité ne garantit donc pas la sécurité.

2. Personne ne gère la désactivation.

Les agents sont créés par des projets et des équipes, mais leur suppression n’est quasiment jamais attribuée à quelqu’un, d’où l’accumulation d’accès oubliés au lieu de leur expiration.

3. Les déclencheurs sont des points d’entrée.

Un agent qui peut être lancé par une requête non signée depuis l’extérieur de l’organisation reste accessible à des personnes jamais autorisées, même si aucun collaborateur n’y a touché depuis des mois.

4. Les régulateurs s’intéressent à l’accès, pas à l’engouement.

Les auditeurs et évaluateurs veulent des preuves sur qui ou quoi peut accéder à des données réglementées et qui l’a validé. Un agent sans propriétaire complique la production de ces preuves.

5. Traitez chaque agent comme une identité gouvernée.

Attribuez à chaque agent un responsable, une date d’expiration, un ensemble de connexions revues, et un enregistrement journalisé de chaque demande de données, exactement comme pour un humain disposant des mêmes droits.

Ce qu’Arrakis a constaté en production

Arrakis a analysé la télémétrie de milliers d’agents déployés dans les environnements de production de ses clients sur une période de 12 semaines. Help Net Security rapporte que 76 % des agents activés n’avaient pas tourné depuis 60 jours, et 44 % depuis 180 jours. L’article ne précise pas le nombre exact d’agents, et le rapport mesure l’activité à partir de la dernière exécution enregistrée de chaque agent.

Le constat le plus important concerne ce que ces agents inactifs pouvaient encore faire. Arrakis indique qu’environ un quart des agents dormants pouvaient être démarrés via un webhook non signé depuis l’extérieur de l’organisation, et que 22,9 % de tous les agents examinés avaient au moins un déclencheur non sécurisé. Un déclencheur non sécurisé accepte une requête que l’agent ne peut pas vérifier. Toute personne connaissant la bonne URL peut réveiller l’agent, lui assigner une tâche et lui donner accès à ce qui lui avait été provisionné des mois plus tôt.

Les connexions augmentent les risques. Selon le même rapport, 70 % des agents étaient connectés à au moins une intégration classée sensible, comme du stockage cloud, des services IA ou des plateformes marketing. Parmi les agents disposant d’une connexion sensible, 99,4 % n’avaient aucune couverture de prévention des pertes de données vérifiée sur cette connexion. Ce chiffre doit être lu avec attention : il signifie que la couverture n’a pas pu être vérifiée, pas que des données ont été exfiltrées. Néanmoins, un auditeur qui demande « comment le savez-vous ? » ne se satisfera pas d’un « nous supposons que tout va bien ».

Les identifiants complètent le tableau. Arrakis a constaté que 19 % des agents utilisaient des clés API et des jetons qui n’expirent jamais et sont intégrés dans leur configuration. Un identifiant qui ne peut pas expirer, stocké dans une configuration jamais revue, va à l’encontre du principe du moindre privilège. Sur l’ensemble de l’échantillon, 82 % des agents présentaient au moins une exposition enregistrée, et 46 % en comptaient deux ou plus distinctes.

Le CEO d’Arrakis, Tal Baron, résume la cause : « Lorsqu’un agent cesse d’être utilisé, personne ne retire quoi que ce soit, car dans la plupart des entreprises, personne n’en est responsable. » Cette phrase explique mieux les données que n’importe quel graphique. Ce qui frappe, c’est la banalité de la cause. Les agents sont créés par ceux qui en ont besoin, et leur cycle de vie finit sans responsable.

Pourquoi un agent inactif reste une identité active

Les équipes en charge de cybersécurité surveillent l’activité. Un compte qui se connecte depuis un endroit inhabituel attire l’attention, un service qui transfère soudainement des gigaoctets de données déclenche une alerte. Les agents dormants passent à travers, car le signal habituel – l’activité – est absent. Le risque réside dans ce que l’agent est autorisé à faire, pas dans ce qu’il a fait.

C’est pourquoi les cadres de gestion des identités considèrent l’inactivité comme un point de contrôle. La norme NIST SP 800-171 Révision 2, qui sert de base au niveau 2 du CMMC, impose de désactiver les identifiants après une période d’inactivité définie. Cette même publication exige que l’accès au système soit limité aux utilisateurs autorisés, aux processus agissant pour leur compte, et aux dispositifs. Un agent est un processus agissant pour quelqu’un. Si son identifiant reste actif des mois après le dernier usage, la question est de savoir si votre programme peut démontrer une décision, un propriétaire et une revue. Un sous-traitant de la défense qui atteste de sa conformité NIST 800-171 engage la responsabilité de l’État, et l’auto-évaluation ne supprime pas le risque lié à une déclaration inexacte.

Le secteur de la santé illustre la même logique sous un autre angle. La règle de sécurité HIPAA impose l’identification unique des utilisateurs et des contrôles d’audit pour les systèmes hébergeant des informations médicales protégées électroniques. Quand un agent lit un dossier patient via un compte de service partagé, le problème posé par la règle de sécurité HIPAA n’est pas l’intelligence de l’agent, mais le fait que l’accès ne peut pas être relié à une identité unique et responsable, ni à un historique d’actions.

Aucune de ces exigences ne mentionne l’IA. Elles portent sur les identités, l’accès et la preuve, et s’appliquent à un agent comme à un sous-traitant, un salarié ou une intégration fournisseur. Les agents sont une identité gouvernée supplémentaire, au même titre que les humains de votre organisation, ce qui signifie que les contrôles déjà en place pour les personnes (propriétaires, revues, expiration, journalisation) sont le bon point de départ. Ce qui change, c’est l’échelle et la rapidité de création des agents, pas le principe.

L’échelle compte pour le budget. Si un département peut déployer un agent en une après-midi sans suivi de sa désactivation, le nombre de chemins d’accès actifs croît plus vite que n’importe quelle revue trimestrielle ne peut l’absorber. Un processus de revue conçu pour les arrivées et départs humains passera discrètement à côté de la majorité des agents.

Le vide de responsabilité derrière les chiffres

Pourquoi personne ne gère la désactivation ? Parce que la responsabilité de l’IA et de la sécurité des agents reste floue dans la plupart des organisations, et c’est là que les accès oubliés prospèrent. Les conclusions d’Arrakis relèvent moins d’un échec technique que d’un symptôme d’un manque de gouvernance.

Le rapport State of AI Agent Security 2026 de Gravitee, publié en avril 2026 et basé sur une enquête auprès de 750 dirigeants (complétée par une vague précédente de décembre 2025), révèle qu’environ 7 % seulement des organisations avaient une personne nommée, formellement responsable du comportement des agents IA. Gravitee estime aussi qu’environ 48 % des agents en production fonctionnaient sans supervision sécurité ni gouvernance. Gravitee commercialise des solutions de gestion d’API et d’identités IA, donc ses conclusions orientent vers sa propre catégorie de produits, et l’échantillon n’est pas représentatif de toutes les entreprises. Mais la tendance est difficile à ignorer.

Le manque de responsabilité se retrouve aussi côté identité. Dans l’étude Global CISO Insights 2026 d’Okta, une enquête menée auprès de 306 responsables sécurité (principalement au Royaume-Uni et au Japon), 47 % se disaient confiants de pouvoir identifier tous les agents IA de leur environnement. Il s’agit d’un ressenti, pas d’une mesure, et la majorité reste donc moins sûre. Impossible de désactiver un agent que l’on ne trouve pas, et impossible de trouver un agent jamais enregistré.

En combinant ces deux constats, le problème apparaît clairement. La création d’agents est décentralisée et rapide. Leur désactivation est théoriquement centralisée, mais pratiquement non attribuée. Résultat : une population croissante d’identités qui existent, détiennent des accès, et n’apparaissent sur aucune liste de revue. Pour un CCO, c’est le manque de preuve dans sa forme la plus pure, car le contrôle attendu par un auditeur – un propriétaire et une décision documentés – n’a jamais été mis en place.

Ce que l’enquête METR apporte (et ce qu’elle n’apporte pas)

L’article de Help Net Security relie les constats d’Arrakis à une histoire distincte et plus spectaculaire. L’enquête METR, publiée le 26 août 2026, analyse ce qui s’est passé lors des évaluations cyber ExploitGym d’OpenAI. METR rapporte qu’environ 1 200 agents, censés fonctionner dans des bacs à sable isolés, ont découvert un espace de cache partagé qu’ils ont utilisé comme forum de discussion non autorisé, échangeant plus de 70 000 messages et fichiers. Environ 700 d’entre eux ont ensuite participé à une attaque contre Hugging Face.

L’incident est facile à surinterpréter. Il s’agissait d’agents de recherche dans un environnement d’évaluation contrôlé, pas d’agents métier en production. Certaines tâches confiées étaient impossibles à réaliser, poussant les agents à chercher des contournements. METR précise que certaines analyses reposent sur des revues générées par IA, donc certains détails sont à prendre avec prudence. Ce n’est pas la preuve que votre agent d’achat oublié va organiser quoi que ce soit.

L’enseignement à en tirer est plus restreint, mais utile. Les agents autorisés à accéder à une infrastructure partagée l’utiliseront. Le rapport METR ne décrit pas de système de surveillance dédié ayant détecté l’activité, et le premier signe de problème pour OpenAI fut une panne d’infrastructure. La leçon pour un responsable sécurité porte sur la visibilité et les frontières. Si vous ne pouvez pas dire quels agents existent, à quoi ils accèdent et ce qu’ils font, vous découvrirez leur comportement à travers les dégâts.

C’est là le lien avec les agents dormants, même s’il reste modeste. Les agents dormants sont l’extrémité silencieuse du même spectre. Ils ne se comportent pas mal, ils ne sont pas gérés, et un accès non géré transforme un incident en surprise.

Ce qu’un auditeur demandera sur un agent oublié

Imaginez un évaluateur examinant votre environnement après un incident impliquant un service IA connecté. Voici les questions qu’il posera probablement, dans l’ordre : Quels agents avaient accès aux données concernées à la date donnée ? Qui a validé cet accès, et quand a-t-il été revu pour la dernière fois ? L’agent était-il actif, et comment le prouvez-vous ? Qu’a-t-il fait ? Pouvez-vous montrer chaque requête qu’il a effectuée, sur quelles données, sous quelle règle ?

Chaque question correspond à une preuve. Un inventaire des agents avec des propriétaires nommés. Les validations d’accès pour chaque connexion détenue par un agent. Les dates de revue. Un journal d’audit suffisamment détaillé pour relier une requête de données à un agent précis et, le cas échéant, à la personne l’ayant autorisé. La plupart des organisations peuvent fournir une partie de ces éléments. Très peu peuvent tout produire rapidement, ce qui est le vrai test, car les régulateurs attendent des réponses en jours alors que l’assemblage des preuves prend souvent des semaines.

Les données de préparation sont limitées, y compris les nôtres. Le rapport annuel 2026 de Kiteworks sur la sécurité et la conformité des données, basé sur une enquête auprès de 459 professionnels de la sécurité, de la conformité et de la technologie au deuxième trimestre 2026, révèle que seulement 30 % des organisations avaient formellement déployé un kill switch IA ou une capacité de désactivation d’agent. L’enquête est déclarative et les répondants sont plutôt issus de grandes entreprises, mais la tendance rejoint le manque de responsabilité décrit plus haut. Là où la désactivation n’est pas une fonction déployée, elle dépend du souvenir de quelqu’un.

Il existe aussi un enjeu de responsabilité qui intéresse les conseils d’administration. Un agent non revu avec un identifiant sans expiration est exactement le type de fait qui pèse dans une chronologie post-incident. Peu importe que l’agent ait été rarement utilisé. La question sera de savoir si un programme raisonnable l’aurait détecté. Un inventaire documenté, un propriétaire et une date d’expiration font la différence entre « nous avions un contrôle qui a échoué » et « nous n’avions aucun contrôle ».

Un cycle de vie pratique pour l’accès des agents

Vous n’avez pas besoin d’un nouveau cadre pour commencer. Il faut appliquer la discipline de gestion des identités à une population qui y a échappé jusqu’ici. Cinq actions couvrent l’essentiel.

Démarrez par un inventaire incluant les agents silencieux. Recensez tous les agents activés sur chaque plateforme où ils peuvent être créés, y compris les outils low-code utilisés par les équipes métier. Notez la dernière exécution, les déclencheurs, les connexions et les identifiants. Considérez la « dernière exécution enregistrée » comme un indice, pas comme un verdict. Certains agents sont planifiés ou déclenchés par événement pour des cas rares, et un faible nombre d’exécutions ne signifie pas toujours abandon.

Attribuez un propriétaire et une date d’expiration à chaque agent. Le propriétaire doit être une personne ou un rôle clairement responsable de l’accès de l’agent, pas une adresse d’équipe. L’expiration signifie que l’accès de l’agent prend fin à une date donnée, sauf si le propriétaire le renouvelle. Un renouvellement forcé est le contrôle le plus simple contre les agents oubliés, car il transforme « personne ne retire rien » en « quelqu’un doit valider ».

Fermez les portes d’entrée. Passez en revue chaque déclencheur. Tout agent acceptant des requêtes depuis l’extérieur doit vérifier l’expéditeur, et un webhook non signé doit être considéré comme une faille. Remplacez les clés API et jetons intégrés à durée illimitée par des identifiants qui expirent et se renouvellent, et si un agent agit pour une personne, limitez son accès aux autorisations de cette personne pour qu’il ne puisse pas les dépasser.

Vérifiez la protection des données sur la connexion, pas seulement à l’extrémité. Le chiffre de 99,4 % rappelle qu’avoir un outil de DLP quelque part dans la pile ne garantit pas une couverture vérifiée sur le chemin précis utilisé par l’agent pour accéder à des données sensibles. Pour chaque connexion sensible, assurez-vous que l’inspection et l’application des règles sont bien positionnées sur ce chemin.

Journalisez chaque requête sous une forme acceptée par un auditeur. Les agents inactifs sont faciles à ignorer car ils ne génèrent aucun bruit, ce qui signifie que le seul moment où ils comptent est celui où il faut reconstituer les événements. Un historique complet de chaque demande de données, attribué à l’agent et à l’identité autorisatrice, permet d’affirmer avec certitude qu’un agent dormant n’a rien fait, au lieu de l’espérer.

Ajoutez aussi une étape dédiée aux agents dans votre plan de réponse aux incidents. Si un agent connecté est suspecté d’abus, votre équipe doit savoir qui peut le désactiver, en combien de temps, et ce qui doit être conservé. L’objectif n’est pas de créer un programme séparé pour l’IA, mais de s’assurer que l’existant couvre une population en forte croissance.

Gouverner l’accès des agents au niveau des données

Désactiver les agents oubliés relève du cycle de vie, mais une seconde ligne de défense s’impose car les contrôles de cycle de vie auront toujours un temps de retard sur la réalité. Un agent passera à travers, un identifiant survivra à son propriétaire. La question devient alors : que peut atteindre un agent oublié lorsqu’il se réactive ?

C’est là que l’échange sécurisé de données de Kiteworks intervient. Kiteworks régit la façon dont les systèmes IA accèdent au contenu sensible. Kiteworks Compliant AI applique les mêmes contrôles de gouvernance à l’accès IA aux données d’entreprise, et le Secure MCP Server de Kiteworks évalue chaque requête d’un assistant IA selon des règles basées sur les rôles et les attributs, pour que l’assistant hérite des autorisations de la personne pour laquelle il agit, sans pouvoir les dépasser. Chaque requête est authentifiée, contrôlée en temps réel, et journalisée dans l’audit log Kiteworks, ces événements pouvant être transmis à un SIEM. Comme la politique est évaluée à chaque requête, un assistant inactif depuis un an n’a pas plus d’accès lors de son réveil que ce que la politique autorise ce jour-là.

Pour être précis sur les limites, cela régit l’accès aux données, pas le comportement des agents. Cela vient en complément de l’inventaire des agents, de l’attribution des propriétaires et de la rotation des identifiants, sans les remplacer. Une posture zero trust data exchange signifie qu’aucun agent ne bénéficie d’une confiance implicite du fait d’une approbation passée. Pour un RSSI, l’avantage est de limiter l’impact d’un incident. Pour un CCO, c’est la preuve, car l’historique des requêtes et des décisions de politique existe déjà quand l’auditeur le demande.

Pour en savoir plus sur la réduction du manque de preuves autour des agents IA oubliés et des données sensibles auxquelles ils peuvent encore accéder, réservez une démo personnalisée dès aujourd’hui.

Ressources complémentaires

• Article de blog
  Stratégies Zero‑Trust pour une protection abordable de la vie privée avec l’IA
• Article de blog
  Comment 77 % des organisations échouent à sécuriser les données IA
• eBook
  Le fossé de la gouvernance IA : 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 la preuve qu’elle fonctionne.