Les agents IA continuent de se connecter en tant qu’humains – et cela fausse vos journaux d’audit
Depuis quatre ans, les entreprises ajoutent des agents IA à une infrastructure d’identité qui n’a jamais été conçue pour les reconnaître comme des acteurs distincts. Ce décalage apparaît désormais dans les données, et pas seulement lors des analyses post-incident. Un nouveau rapport, fondé sur l’activité de connexion anonymisée de plus de 20 000 organisations, montre que les agents IA opèrent dans les environnements d’entreprise aujourd’hui comme ils le faisaient à l’arrivée de l’IA générative : authentifiés en tant qu’humain ou via un humain.
Ce rapport, intitulé Okta Enterprise AI Index, s’appuie sur des données de connexion allant de juin 2022 à juin 2026 et couvrant plus de 100 produits IA distincts, regroupés en 74 suites éditeurs pour l’analyse. L’ampleur de l’échantillon rend ce constat difficile à balayer d’un revers de main. Il ne s’agit pas d’un cas isolé lié à une mauvaise configuration chez un éditeur ou à un déploiement précipité de l’IA dans une entreprise. C’est un schéma qui se répète dans des dizaines de milliers d’organisations, qui choisissent, ou adoptent par défaut, la même méthode d’autorisation des workflows d’agents IA.
Les chiffres de croissance sont impressionnants. Les entreprises natives de l’IA comme Anthropic, OpenAI et Cursor ont plus que quadruplé leur base de clients entreprises sur la période étudiée. Anthropic a dépassé OpenAI en nombre de comptes entreprises en mars 2026, puis en utilisateurs actifs mensuels le mois suivant. Ces étapes illustrent la rapidité avec laquelle l’IA agentique est passée de l’expérimentation à un outil standard en entreprise. Mais le constat le plus important se trouve sous la courbe de croissance : les pratiques d’identité et d’accès pour les agents IA n’ont pas suivi la cadence de leur déploiement.
Le partage sécurisé de données Kiteworks repose sur un principe différent : chaque acteur manipulant du contenu sensible, qu’il soit humain ou machine, doit disposer d’une identité vérifiable, d’autorisations précises et d’une entrée dédiée dans le journal d’audit. C’est précisément ce qui fait défaut dans la majorité des déploiements IA en entreprise selon ce rapport.
Résumé des points clés
1. L’adoption de l’IA en entreprise a dépassé les pratiques d’identité.
Les nouvelles données de connexion sur quatre ans et plus de 20 000 organisations montrent que les éditeurs IA natifs ont multiplié par plus de 4 leurs comptes entreprises, alors que le modèle d’identité sous-jacent à ces outils a à peine évolué depuis l’ère des projets pilotes.
2. Les agents utilisent toujours des identifiants humains.
Les comptes de service, les clés API statiques et les identifiants humains partagés restent la norme pour autoriser les workflows d’agents IA, selon Fei Liu, chercheur chez Okta. Chacune de ces méthodes a été conçue pour un monde sans acteurs logiciels autonomes.
3. Un identifiant emprunté signifie un journal d’audit faussé.
Quand un agent IA s’authentifie en tant que personne, les journaux affichent le nom de cette personne pour des actions qu’elle n’a jamais réalisées, rendant quasi impossible la reconstitution des actions de l’agent lors d’une analyse d’incident.
4. La course Anthropic-OpenAI est un symptôme, pas le sujet.
Le fait qu’Anthropic dépasse OpenAI en comptes entreprises et en utilisateurs actifs mensuels début 2026 confirme la rapidité avec laquelle l’IA agentique s’impose dans les processus métiers, bien plus vite que les programmes d’identité et d’accès ne s’adaptent pour la gouverner.
5. Un contrôle d’accès à l’échelle de l’agent comble l’écart.
Attribuer à chaque agent IA une identité gouvernée, des autorisations et un historique d’audit dédiés, plutôt que de passer par une session humaine, fait toute la différence entre un déploiement IA gouvernable et un déploiement hors de contrôle.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Comptes de service, clés API statiques et identifiants partagés : trois failles dans l’identité des agents
D’après Fei Liu, chercheur Okta cité dans le rapport, les organisations s’appuient principalement sur trois mécanismes pour autoriser les workflows d’agents IA : comptes de service, clés API statiques et, dans certains cas, identifiants humains partagés. Chacun répond à un problème d’intégration à court terme, mais crée un problème de gouvernance à long terme que la plupart des organisations n’ont pas encore pris en compte.
Les comptes de service sont les plus répandus. Ils permettent à un agent IA d’agir en tant qu’identité non humaine désignée dans une application, ce qui semble pertinent jusqu’à ce qu’on observe comment ces comptes sont généralement créés et surveillés. Beaucoup sont créés une seule fois, reçoivent des contrôles d’accès larges pour couvrir tous les besoins potentiels de l’agent, puis sont laissés tels quels. Personne ne révise les autorisations à mesure que le rôle de l’agent évolue. Personne ne relie les actions à une tâche, une demande ou une justification métier précise. Le compte existe, l’agent l’utilise, et les journaux décrivent le compte, pas le travail effectué. L’application d’étiquettes de classification des données sur le contenu accessible par les comptes de service est indispensable pour affiner la portée des accès — sans cela, impossible pour un programme de gouvernance d’imposer des restrictions selon la sensibilité sur ce qu’un agent peut atteindre via ce compte.
Les clés API statiques posent des problèmes similaires, aggravés par leur gestion opérationnelle. Une clé qui autorise un agent à lire des fichiers, interroger une base de données ou accéder à un système interne n’expire généralement pas, ne se renouvelle pas automatiquement, et se retrouve souvent copiée dans des fichiers de configuration, des variables d’environnement, voire pire, directement dans une invite ou la fenêtre de contexte de l’agent, où elle peut être exposée, consignée ou exfiltrée sans que personne ne s’en aperçoive. Dès qu’une clé existe à plusieurs endroits, il devient impossible de savoir avec certitude qui y a accès.
Le troisième schéma, les identifiants humains partagés, est le plus préoccupant car il efface totalement la distinction entre personne et processus. Les identifiants d’un collaborateur sont transmis à un script d’automatisation, un bot ou un agent IA pour qu’il agisse « en tant que » cette personne dans un système qui ne prévoit pas de gestion séparée des identités machines. Dès lors, toutes les actions de l’agent apparaissent dans les journaux comme si l’humain les avait réalisées. Une violation de données confirmée via un identifiant humain partagé utilisé par un agent empêche l’organisation de circonscrire précisément la faille — les obligations de notification au titre de la HIPAA, du RGPD ou d’autres cadres s’appliquent à l’exposition maximale, sauf preuve contraire, preuve qu’un journal d’audit mêlant humain et agent ne peut fournir.
Pourquoi « Lorsqu’un agent IA hérite d’un identifiant humain, le journal d’audit est perdu » doit alerter tout RSSI
L’avertissement de Liu dans le rapport est clair : « lorsqu’un agent IA hérite d’un identifiant humain, vous perdez totalement votre journal d’audit ». Il s’agit d’une défaillance technique précise, pas d’un risque vague. Un journal d’audit n’a d’intérêt que s’il permet de savoir, après coup, qui a fait quoi, quand et pourquoi. Si un agent agit sous la session d’un humain, le journal enregistre le mauvais acteur pour chaque événement. Le nom dans le journal est correct. L’histoire qu’il raconte ne l’est pas.
Cela prend tout son sens lorsque le journal d’audit devient nécessaire : enquête sur une violation, audit de conformité, contrôle réglementaire ou revue interne sur la circulation d’un contenu sensible. Dans chacun de ces cas, on finit par poser la même question : est-ce une personne ou un processus automatisé qui a agi, et sous quelle autorité ? Si la réponse est « nous ne pouvons pas le dire, car l’agent était connecté sous le nom de Sarah », l’enquête piétine, la réponse de conformité s’affaiblit et l’organisation ne peut pas prouver les contrôles d’accès attendus par des cadres comme le NIST CSF, ISO 27001 ou SOC 2. Alimenter en temps réel un journal d’audit attribué aux agents dans une plateforme SIEM transforme l’attribution d’agent d’un outil d’analyse post-incident en une couche de détection comportementale, qui signale les activités anormales d’un agent avant qu’une violation ne se produise.
Il existe aussi un coût plus insidieux, qui se manifeste bien avant tout incident : la responsabilité s’érode progressivement, au fil de l’activité courante. Si personne ne peut dire avec certitude quelles actions relèvent d’un humain ou d’un agent, les validations d’exceptions, les revues d’accès aux données et l’application du principe du moindre privilège deviennent difficiles à piloter. Les réviseurs finissent par accorder des accès larges, car restreindre leur champ semble risqué lorsqu’ils ne peuvent isoler précisément les besoins de l’agent. C’est ainsi que la mauvaise configuration de la sécurité s’accumule, non par une mauvaise décision, mais par une succession de choix raisonnables, sur un modèle d’identité qui n’a jamais séparé humains et logiciels agissant en leur nom.
Le Shadow AI est d’abord un problème d’identité, avant d’être un problème de données
La plupart des discussions sur le shadow AI se concentrent sur la destination des données sensibles : un modèle non approuvé, un plugin non validé, une extension de navigateur non contrôlée. C’est un vrai sujet, mais les données Okta pointent un problème plus en amont. Avant qu’un agent ne puisse déplacer ou exposer des données, il doit s’authentifier quelque part. Si cette étape passe par un compte partagé, une clé API non gérée ou un identifiant emprunté, l’organisation a déjà perdu toute visibilité avant même que la question de la gouvernance des données ne se pose.
C’est pourquoi l’identité doit être au cœur de toute gouvernance IA, et non reléguée au rang de sous-thème de la prévention des pertes de données. Un agent doté d’une identité gérée et limitée par conception ne peut accéder qu’à ce que son rôle autorise, et chaque action est attribuée à cet agent et à cette tâche. Un agent opérant sous la session d’un humain ou via un compte de service trop large n’est pas vraiment limité ; sa portée réelle dépend de ce que l’humain ou le compte peut atteindre, souvent bien plus que ce dont l’agent a besoin. Les programmes de gouvernance des données IA qui commencent par des politiques mais négligent l’architecture d’identité ne résolvent que la moitié du problème. Le shadow AI — agents et outils IA opérant hors de tout programme d’identité validé — en est la conséquence directe : des agents hors de contrôle, invisibles, impossibles à circonscrire ou à attribuer lors d’un incident.
Le rapport annuel Kiteworks 2026 sur les risques de sécurité et de conformité des données identifie la gouvernance IA comme l’une des priorités majeures en matière de sécurité des données cette année. Les conclusions d’Okta le confirment sous un autre angle : les outils agentiques ont été adoptés plus vite que les contrôles d’accès et d’identité zero trust nécessaires pour les gouverner. Les programmes de gestion des risques supply chain qui étendent les exigences de gouvernance d’identité aux fournisseurs IA tiers — couvrant les agents déployés par ces fournisseurs dans les environnements clients, et pas seulement les outils déployés par les clients eux-mêmes — comblent le déficit d’identité supply chain que révèlent les données Okta.
Comment Kiteworks attribue à chaque agent IA une identité vérifiable
Kiteworks aborde ce problème en partant du même constat que les conclusions Okta : humains et agents IA sont tous deux des identités de premier plan qui doivent être authentifiées, autorisées et journalisées individuellement, sous une seule couche de gouvernance. Le Control Plane Kiteworks gouverne chaque demande de contenu sensible, qu’elle émane d’une personne, d’une application ou d’un agent, via ce modèle unique, de sorte que l’accès d’un agent ne passe jamais par un contournement comme un identifiant humain emprunté ou un compte de service non géré.
Le Serveur MCP sécurisé est la brique conçue pour répondre à ce besoin. Il s’authentifie via OAuth 2.0, avec le jeton d’accès stocké dans le coffre sécurisé du système d’exploitation, et non dans un emplacement accessible au modèle IA qui pourrait le lire, le copier ou le divulguer. Cette approche diffère fondamentalement de la remise d’une clé API statique ou d’un mot de passe humain partagé à un agent : l’agent ne détient jamais d’identifiant qu’il pourrait exposer dans une invite, un fichier journal ou une session compromise. Chaque opération de l’agent — lecture d’un fichier, navigation dans un dossier, récupération de contenu pour une tâche — est évaluée en temps réel selon les règles RBAC et ABAC, et journalisée individuellement, au lieu d’être regroupée dans une entrée générique attribuée à une personne. C’est la réponse structurelle à l’alerte de Fei Liu : si l’identifiant ne quitte jamais le coffre sécurisé et que chaque action est autorisée et journalisée séparément, il n’y a plus d’identité partagée susceptible de brouiller le journal d’audit. Le tableau de bord RSSI affiche en temps réel cette télémétrie d’audit au niveau agent, offrant à la direction sécurité la visibilité unifiée sur tous les accès de contenu médiés par l’IA, pointée comme manquante dans la plupart des déploiements actuels par le rapport Okta.
Kiteworks Compliant AI applique la même discipline à ce que les agents peuvent voir et utiliser, et pas seulement à leur authentification. L’application de règles au niveau du contenu détermine ce qu’un agent peut consulter ou retenir avant même que le contenu n’atteigne la fenêtre de contexte du modèle, de sorte que la frontière d’identité et la frontière de données se renforcent mutuellement, au lieu que l’une dépende entièrement de la robustesse de l’autre. La minimisation des données à ce niveau — veiller à ce que chaque agent ne reçoive que le strict minimum nécessaire à sa tâche — réduit l’impact en cas d’exposition d’un identifiant agent, puisque la portée accessible de l’agent est déjà limitée par conception.
Construire un modèle de contrôle d’accès à l’échelle de l’agent avec RBAC et ABAC
Combler le déficit d’identité implique d’aller au-delà de « cet agent dispose-t-il d’un identifiant » pour se demander « cet agent précis, pour cette tâche précise, dispose-t-il de l’autorisation spécifique dont il a besoin à l’instant T ? ». C’est une question de rôle et d’attributs, pas de simple provisionnement statique.
Le contrôle d’accès basé sur les rôles (RBAC) attribue à chaque agent un rôle défini, limité à sa fonction réelle. Par exemple, un agent de synthèse n’a besoin que d’un accès en lecture aux documents à résumer, ou un agent de workflow qui classe des documents n’a besoin que d’un accès en écriture à un dossier précis, et rien de plus dans chaque cas. Le contrôle d’accès basé sur les attributs (ABAC) ajoute du contexte à ce rôle : la classification de la sensibilité du contenu, le moment de la demande, l’environnement de déploiement de l’agent et la tâche en cours déterminent si une requête est autorisée. Ensemble, RBAC et ABAC permettent à une organisation d’accorder à un agent exactement l’accès dont il a besoin pour sa tâche en cours, et rien de plus, à l’opposé de la plupart des comptes de service actuels.
Ce modèle répond aussi à un manque souligné par le rapport Okta : un journal d’audit propre, où chaque entrée mentionne l’agent réel, lié à une tâche réelle, évalué selon une règle réelle, et non un nom de personne à la place d’un travail qu’elle n’a pas effectué. Lorsqu’une analyse d’incident ou un audit de conformité demande ce qui s’est passé, la réponse figure déjà dans le journal, correctement attribuée dès le départ. Un plan de réponse aux incidents documenté, couvrant les scénarios de dysfonctionnement d’agent IA — notamment les étapes d’isolement d’une identité agent compromise, de révocation de ses identifiants et de circonscription des contenus auxquels elle a accédé — transforme le journal d’audit propre en capacité opérationnelle de réponse.
Ce que les entreprises doivent faire dès maintenant pour combler l’écart d’identité des agents IA
L’ampleur des données Okta (quatre ans, plus de 20 000 organisations, plus de 100 produits IA) montre qu’il ne s’agit pas d’un problème réservé aux pionniers ou aux retardataires. Il est quasi universel, ce qui signifie que la plupart des équipes sécurité et identité ont du travail à faire, quel que soit le niveau de maturité de leur programme de gouvernance IA.
Quelques points de départ découlent directement des conclusions du rapport. Premièrement, recensez tous les agents IA actifs dans l’environnement et identifiez précisément quel identifiant chacun utilise : compte de service, clé API ou identifiant humain. Impossible de corriger ce que l’on n’a pas cartographié. Deuxièmement, traitez en priorité tout agent s’authentifiant via un identifiant humain partagé, car ce schéma entraîne la perte d’audit la plus grave décrite dans le rapport. Troisièmement, évaluez si votre infrastructure IAM actuelle peut réellement provisionner des identités distinctes et limitées pour les acteurs non humains, ou si elle a été conçue uniquement pour les personnes. Quatrièmement, fondez les décisions d’accès agent sur les principes du partage de données zero trust : vérifiez chaque demande, accordez le minimum d’accès nécessaire et journalisez le résultat, au lieu de faire confiance à un agent parce qu’il s’exécute sous un compte donné. Une analyse de risques formelle, cartographiant pour chaque agent le type d’identifiant et les autorisations actuelles par rapport à ses besoins réels — et identifiant où des identifiants partagés ou des comptes de service surprovisionnés créent une exposition inacceptable — constitue la base factuelle d’une feuille de route de remédiation priorisée.
Tout cela peut être engagé sans attendre une violation pour le justifier. Les données Okta révèlent un déficit structurel dans la façon dont les entreprises autorisent aujourd’hui les agents IA, pas un risque hypothétique futur. Le combler dès maintenant, alors que l’adoption de l’IA agentique s’accélère, coûte bien moins cher que de devoir reconstituer un journal d’audit inexistant après coup.
Pour en savoir plus sur l’attribution d’une identité gouvernée à chaque agent IA au lieu d’identifiants humains empruntés, réservez votre démo sans attendre !
Foire aux questions
L’Okta Enterprise AI Index est un rapport fondé sur des données de connexion anonymisées couvrant plus de 20 000 organisations de juin 2022 à juin 2026, et plus de 100 produits IA distincts regroupés en 74 suites éditeurs. Il analyse l’adoption des outils IA par les entreprises et, surtout, la façon dont ces outils sont authentifiés et autorisés dans les environnements professionnels. Le rapport révèle que les agents IA sont encore le plus souvent autorisés via des comptes de service, des clés API statiques ou des identifiants humains partagés, au lieu d’identités spécifiquement attribuées à chaque agent. Les organisations souhaitant évaluer leur exposition à ce schéma peuvent commencer par examiner comment leur infrastructure IAM provisionne actuellement les acteurs non humains. Celles soumises à des obligations de conformité réglementaire — HIPAA, RGPD, CMMC — doivent considérer le déficit d’authentification documenté par le rapport Okta comme un point de non-conformité, ces cadres exigeant des contrôles d’accès et des journaux d’audit démontrables, que l’utilisateur soit humain ou agent.
Un compte de service est généralement créé une fois avec des autorisations larges, censées couvrir tous les besoins potentiels de l’agent, puis rarement revu. Résultat : l’agent dispose souvent de bien plus d’accès que nécessaire pour sa tâche actuelle, et chaque action est attribuée au compte, pas à une tâche précise et traçable. Cela va à l’encontre du principe du moindre privilège et affaiblit les contrôles d’accès que les cadres de conformité attendent des organisations. À l’inverse, une identité dédiée à l’agent peut être limitée exactement à ce qu’exige la tâche. La minimisation des données appliquée à la portée des comptes de service — en ne donnant à chaque agent accès qu’aux sources de données nécessaires à sa tâche — permet de transformer le moindre privilège d’une intention politique en réalité opérationnelle.
Lorsqu’un agent IA s’authentifie avec les identifiants d’une personne, toutes ses actions sont enregistrées sous l’identité de cette personne, même si elle ne les a jamais réalisées. Il devient alors impossible de distinguer l’activité humaine de celle de l’agent lors d’une enquête sécurité, d’un audit de conformité ou d’un incident. Fei Liu d’Okta le résume ainsi : dès qu’un agent hérite d’un identifiant humain, le journal d’audit est perdu, car il ne reflète plus qui ou quoi a réellement agi. Les identifiants dédiés à chaque agent évitent cela en garantissant que chaque entrée du journal mentionne l’acteur réel. Les organisations doivent également vérifier que la configuration d’alerte de leur SIEM traite les schémas anormaux dans les journaux attribués aux agents — accès à des horaires inhabituels, volumes de données anormaux, demandes de ressources hors périmètre — comme des signaux de détection prioritaires, et non comme du bruit de fond.
Le Serveur MCP sécurisé est le point d’accès gouverné de Kiteworks pour les agents IA utilisant le Model Context Protocol pour accéder au contenu d’entreprise. Plutôt que de fournir à l’agent un identifiant statique qu’il pourrait détenir ou exposer, il s’authentifie via OAuth 2.0 avec le jeton stocké dans le coffre sécurisé du système d’exploitation, et chaque demande est évaluée en temps réel selon les règles RBAC et ABAC. Cela maintient les identifiants hors de portée de l’agent, ce qui évite précisément la faille décrite par Okta lorsque les agents héritent d’identifiants humains. La classification des données appliquée au contenu géré par le Serveur MCP sécurisé rend l’application d’ABAC précise — les décisions d’accès distinguent le contenu public du contenu confidentiel à chaque requête agent, au lieu d’appliquer une autorisation globale à tout le périmètre accessible de l’agent.
Pas forcément. L’étape la plus urgente consiste à provisionner les agents IA comme une catégorie d’identités gouvernées à part entière, aux côtés des utilisateurs humains et sous les mêmes règles, plutôt que de faire passer les agents par des sessions humaines ou des comptes de service génériques en guise de contournement. Kiteworks le fait via le Control Plane Kiteworks, qui gouverne l’accès, l’utilisation et le partage de contenu sensible pour humains et agents sous un même ensemble de règles, avec des contrôles RBAC et ABAC adaptés à chaque tâche agent. Une analyse de risques cartographiant les agents opérant actuellement via des identifiants partagés — et priorisant la remédiation selon la sensibilité des contenus accessibles via ces identifiants — donne aux équipes identité et sécurité un point de départ ciblé, rendant la remédiation de l’identité agent réalisable et non insurmontable.
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
Pourquoi 77 % des organisations échouent sur la sécurité des données IA - eBook
Écart de 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 des preuves de son efficacité.