Les agents IA accèdent à des données sans autorisation : trois nouvelles enquêtes confirment le manque de gouvernance

Trois études indépendantes, publiées à quelques jours d’intervalle à l’été 2026, sont arrivées à la même conclusion inconfortable, chacune sous un angle différent : la plupart des entreprises ignorent ce à quoi leurs agents IA peuvent accéder, qui a validé ces accès, ou comment les révoquer en cas de problème.

J’ai lu de nombreuses enquêtes de ce type au fil de l’année, et la plupart mesurent la même inquiétude générale avec des mots différents. Ce qui distingue ce trio, c’est que les chiffres concordent réellement. 1Password a interrogé 1 000 professionnels de la sécurité et de l’ingénierie dans de grandes entreprises américaines et a constaté que les agents accèdent régulièrement à des données bien au-delà de ce qui a été validé. Okta a interrogé 306 dirigeants de la sécurité dans le monde pour son rapport Global CISO Insights 2026 et a révélé que moins de la moitié se sentent capables d’identifier tous les agents IA présents dans leur environnement, et encore moins de contrôler leurs actions. Enfin, le Kiteworks 2026 Data Security and Compliance Risk: Annual Survey Report, basé sur une étude auprès de 459 responsables sécurité et conformité, a quantifié ce même écart en mesurant le déploiement effectif des contrôles, et a constaté que l’écart est tout aussi large, voire plus.

Pris séparément, chaque rapport raconte une histoire marquante. Ensemble, ils dessinent un véritable état des lieux du secteur : l’accès des agents IA dépasse presque partout la gouvernance mise en place, et les organisations qui exploitent ces agents en production sont, dans la plupart des cas, les dernières à découvrir l’étendue réelle de ces accès. Cet article détaille les constats de chaque étude, leurs points de convergence, et ce qu’exige un modèle de gouvernance adapté à la fois aux identités humaines et aux agents.

Résumé des points clés

• Les agents accèdent déjà à plus de données que ce qui a été validé. 1Password a constaté qu’environ 4 organisations sur 10 disposent d’agents IA accédant à des données hors du périmètre approuvé, et que les agents manipulent collectivement environ deux fois plus de données que ce qui a été validé.
• Les RSSI n’ont pas de visibilité sur ce qu’ils doivent gouverner. L’enquête mondiale d’Okta révèle que moins de la moitié des responsables sécurité sont confiants dans leur capacité à identifier chaque agent IA dans leur environnement, à contrôler leurs accès ou à déterminer ce qu’ils sont autorisés à faire.
• Les données mesurées par Kiteworks confirment cet écart de façon indépendante. Le Kiteworks 2026 Data Security and Compliance Risk: Annual Survey Report a relevé un score de maturité de la gouvernance IA de 35 sur 100 auprès de 459 organisations, ce qui signifie qu’en moyenne, chaque organisation a déployé environ 7 des 19 fonctions de gouvernance IA mesurées.
• Le purpose binding et les kill switches sont les contrôles les moins déployés. Seules 26 % des organisations limitent les agents IA aux tâches et aux périmètres de données autorisés, et seulement 21 % peuvent automatiquement couper l’accès d’un agent en cas de comportement anormal.
• La question de la responsabilité reste non résolue, même là où la technologie existe. 1Password a constaté que 65 % des répondants estiment qu’une autre personne devrait être responsable lorsqu’un agent cause un préjudice, alors que la gouvernance permettant d’attribuer cette responsabilité au niveau du contrôle d’accès reste rare.

La réalité côté développeurs : les agents accèdent déjà à plus de données que ce qui a été validé

Commençons par les personnes qui conçoivent et exploitent ces systèmes au quotidien. L’enquête de 1Password, menée fin mai et début juin 2026 auprès de 1 000 professionnels de la sécurité et de l’ingénierie dans de grandes entreprises américaines, décrit un environnement où les agents IA sont passés du pilote à la production plus vite que les contrôles d’accès censés les encadrer.

Quarante-six pour cent des développeurs déclarent exploiter des agents IA en production aujourd’hui. Ce n’est pas surprenant : l’adoption de l’IA agentique s’est accélérée toute l’année. Ce qui l’est davantage, c’est ce qui se passe une fois ces agents déployés : 71 % des développeurs affirment que leurs agents peuvent accéder à des informations sensibles, et dans environ 4 organisations sur 10, les agents accèdent à des données explicitement hors du périmètre qui leur a été approuvé. Sur l’ensemble de la population interrogée, les agents manipulent collectivement environ deux fois plus de données que ce qui a été validé. Ce n’est pas une simple erreur d’arrondi dans une politique d’accès : il s’agit d’un écart structurel entre la classification des données que l’organisation croit avoir appliquée et ce que les agents peuvent effectivement atteindre. Les organisations qui gèrent des informations personnelles identifiables (PII), des informations médicales protégées (PHI) ou d’autres catégories de données réglementées sont confrontées à une exposition accrue : une violation de données avérée imputable à un agent accédant à des données hors de son périmètre approuvé déclenche les mêmes obligations de notification et de remédiation qu’une violation initiée par un humain, avec la complexité supplémentaire que la chaîne de décision de l’agent peut être plus difficile à reconstituer que celle d’un acteur humain.

Le problème de la persistance aggrave la situation. Quarante pour cent des développeurs déclarent accorder aux agents un accès persistant à des systèmes et secrets qui reste actif après la fin de la tâche concernée. Dans un environnement bien gouverné, l’accès d’un agent devrait expirer avec la tâche, tout comme le badge d’un prestataire doit être désactivé à la fin de sa mission. Au lieu de cela, les agents conservent souvent indéfiniment des identifiants, ce qui élargit le champ d’impact potentiel en cas de compromission, d’injection de prompt ou d’intégration d’outil mal configurée. La minimisation des données appliquée au niveau des accès des agents — c’est-à-dire n’accorder à chaque agent que l’accès strictement nécessaire aux sources de données pour la tâche en cours, avec expiration automatique à la fin de la tâche — est le mécanisme opérationnel qui permet de combler l’écart d’accès persistant mesuré par 1Password chez 40 % des développeurs.

Ce dernier risque n’est pas non plus théorique. Quarante-sept pour cent des développeurs ont signalé qu’un agent avait effectué une action non prévue après avoir suivi des instructions dissimulées dans une page web, un document, un e-mail ou un résultat d’outil — l’équivalent, pour un agent, d’un clic sur un lien de phishing, sauf que l’agent n’hésite pas comme le ferait un salarié formé. Et 33 % des développeurs travaillant avec des agents déclarent que leur organisation a subi une violation ou un incident de sécurité lié spécifiquement à des identités non humaines sur-privilégiées.

Peut-être que le constat le plus révélateur de toute l’enquête concerne la responsabilité, et non l’accès. Lorsqu’on leur demande qui devrait être responsable lorsqu’un agent cause un préjudice, 65 % des répondants estiment que la responsabilité devrait incomber à une autre personne que celle actuellement désignée. Seuls 5 % estiment que l’agent lui-même devrait être tenu responsable. Autrement dit, les personnes les plus proches de ces systèmes savent déjà que le modèle de responsabilité actuel ne reflète pas la réalité ; elles ne s’accordent simplement pas encore sur l’endroit où doit reposer cette responsabilité. Cet écart entre la responsabilité actuelle et celle que les praticiens estiment légitime constitue, à mon sens, le véritable point saillant des données 1Password — plus encore que les chiffres sur l’accès, car aucun outil supplémentaire ne peut le résoudre à lui seul. Des contrôles d’accès attribués à une politique et à un valideur précis fournissent au moins à l’organisation les preuves nécessaires pour aborder la question de la responsabilité sur des faits, et non sur des suppositions. Un plan de réponse aux incidents documenté, qui pré-attribue explicitement la responsabilité en cas d’incident impliquant un agent — qui enquête sur un événement d’injection de prompt, qui révoque les identifiants de l’agent, qui évalue le périmètre des données pour la notification — transforme l’ambiguïté de la responsabilité documentée par 1Password en une séquence de réponse préétablie et maîtrisée.

Le point de vue du comité de direction : les RSSI n’ont pas de visibilité sur ce qu’ils doivent gouverner

Montons d’un cran, des personnes qui développent les agents aux dirigeants responsables des risques générés par ces agents : le constat ne s’améliore pas — il change simplement de forme.

Le rapport Global CISO Insights 2026 d’Okta, basé sur une enquête auprès de 306 responsables sécurité dans le monde, révèle que 81 % s’inquiètent d’un accès excessif des agents IA. Une large majorité exprime donc une préoccupation. Mais ce qui frappe, c’est le faible nombre de ceux qui se sentent capables d’agir : seuls 47 % se disent confiants dans leur capacité à identifier chaque agent IA présent dans leur environnement, 46 % à contrôler ce que ces agents peuvent accéder, et 45 % à déterminer ce qu’un agent donné est effectivement autorisé à faire. Moins de la moitié, sur chaque dimension de la visibilité opérationnelle de base. Le CISO Dashboard offre la visibilité en temps réel sur tous les accès aux données médiés par l’IA, comblant ainsi ce manque opérationnel — et fournissant aux responsables sécurité l’inventaire unifié et constamment mis à jour des agents, que les données Okta identifient comme manquant dans plus de la moitié des organisations interrogées.

Dans ce contexte, il n’est pas surprenant que les menaces liées à l’IA dominent la liste des préoccupations de ces dirigeants : phishing dopé à l’IA (61 %), agents IA malveillants (49 %), et contournement de l’authentification par deepfake (54 %) figurent parmi les principales craintes. Il ne s’agit pas de risques abstraits ou futurs pour les responsables des programmes de sécurité des entreprises, mais de préoccupations opérationnelles actuelles — et le manque de visibilité mesuré par Okta est précisément ce qui complique leur détection et leur gestion.

Le rapport met également en lumière un problème de culture de gouvernance sous-jacent à la dimension technique. Seuls 31 % des responsables sécurité dans le monde — et à peine 12 % aux États-Unis — déclarent être pleinement alignés avec leur direction générale et leur conseil d’administration sur le niveau de risque IA que l’organisation est prête à accepter. Cet écart se situe au-dessus de la pile technologique. Les personnes qui définissent l’appétence au risque IA et celles qui exécutent les contrôles de sécurité travaillent, dans la plupart des organisations, à partir de deux définitions différentes du risque acceptable, sans qu’aucune réconciliation n’ait encore eu lieu. Une évaluation formelle des risques, qui quantifie l’exposition des agents IA à l’accès aux données en termes business — en cartographiant les catégories de données réglementées accessibles à chaque agent, dans quelles conditions d’accès, avec quelles capacités de révocation — fournit aux responsables sécurité la base factuelle pour combler l’écart d’alignement avec le conseil d’administration mis en évidence par Okta.

Les spécificités opérationnelles relevées par Okta recoupent de près les constats de 1Password côté développeurs. Une organisation sur quatre applique les mêmes politiques de cycle de vie des identités aux agents IA qu’aux utilisateurs humains — ce qui signifie que trois sur quatre ne le font pas, et gèrent donc les identités des agents via un processus distinct, probablement moins rigoureux. Vingt et un pour cent s’appuient sur des identifiants partagés ou des comptes de service à droits étendus pour leurs agents, le schéma exact qui transforme un agent compromis en un risque majeur couvrant tout ce que cet identifiant permet d’atteindre. Et 20 % laissent la gestion des agents à la discrétion des équipes, sans politique organisationnelle cohérente pour l’attribution, la révision ou la révocation des accès. Les programmes de gestion des risques supply chain qui étendent cette gouvernance aux agents IA fournis par des prestataires tiers — et pas seulement à ceux déployés en interne — permettent de couvrir la surface d’identité supply chain créée par cette gestion ad hoc.

Les données internes de Kiteworks le confirment — avec des contrôles mesurés, pas une confiance déclarée

Les deux enquêtes précédentes reposent sur la perception déclarée : le niveau de confiance d’un RSSI, la conscience d’un développeur quant à ce qu’a fait son agent. Ces données sont précieuses, mais la perception et la réalité du déploiement ne coïncident pas toujours. Le Kiteworks 2026 Data Security and Compliance Risk: Annual Survey Report a été conçu pour combler cet écart, en s’appuyant sur des données binaires et vérifiables de déploiement de contrôles, collectées auprès de 459 professionnels de la sécurité et de la conformité dans des organisations de plus de 1 000 salariés, couvrant 10 secteurs et trois régions du monde.

L’enquête introduit deux indicateurs composites. Le Data Security Maturity Score (DSMS) mesure 11 contrôles généraux de sécurité des données — chiffrement, transfert sécurisé de fichiers, intégration SIEM, kill switches, etc. — et affiche une moyenne de 39 sur 100, ce qui signifie que l’organisation type a déployé moins de la moitié des contrôles de sécurité mesurés. Le AI Governance Maturity Score (AIGMS) suit 19 fonctions de gouvernance des données propres à l’IA et affiche une moyenne de 35 sur 100 — soit environ 7 fonctions déployées sur 19. Un troisième indicateur, le Data Security and Compliance Readiness Index (DSCRI), multiplie les deux pour refléter l’effet cumulatif d’une gouvernance faible sur une sécurité moyenne : la moyenne du DSCRI ressort à seulement 16,2 sur 100.

Les conséquences de cet écart ne sont pas théoriques — elles ont été rapportées par les répondants sur les 12 mois précédant l’enquête. Tous répondants confondus, 80 % ont connu au moins un incident de sécurité — général ou spécifique à l’IA — au cours des 12 derniers mois. Soixante-trois pour cent ont subi une conséquence en matière de conformité — audit, plan de remédiation, remontée au conseil, pénalité contractuelle ou enquête réglementaire formelle. Et 65 % ont découvert que des salariés utilisaient des outils IA non approuvés avec des données de l’organisation, un taux d’IA fantôme qui recoupe étroitement les écarts de visibilité sur les accès mesurés par Okta et 1Password selon leurs propres angles.

Ce qui rend les données Kiteworks particulièrement utiles en complément des deux autres rapports, c’est leur granularité sur les contrôles manquants — précisément ceux qui permettraient de combler les écarts décrits par 1Password et Okta.

Où se situe réellement l’écart : purpose binding, kill switches et audit trails

Aucun contrôle de confinement IA mesuré dans l’enquête Kiteworks n’est déployé par plus de 33 % des organisations. Il faut le dire clairement : pour chaque mécanisme technique mesuré visant à limiter ce qu’un agent IA peut faire une fois en production, aucun n’a atteint le tiers du marché.

Le purpose binding — le contrôle qui limite un agent IA à la tâche et au périmètre de données autorisés — n’est déployé que par 26 % des organisations, ce qui signifie que 74 % ne restreignent pas techniquement leurs agents à des tâches et périmètres validés. C’est précisément ce contrôle qui permettrait d’éviter le schéma « agents accédant à des données hors validation » mesuré par 1Password ; sans lui, l’accès effectif d’un agent est limité uniquement par ses capacités techniques, et non par une validation humaine. Les contrôles d’accès appliqués au niveau du contenu — qui évaluent chaque requête d’agent en fonction de la sensibilité du contenu, du rôle de l’agent et du contexte de la tâche — constituent la mise en œuvre technique du purpose binding, qui transforme le périmètre autorisé en contrainte d’exécution plutôt qu’en simple hypothèse documentaire.

La capacité de kill switch — un point de contrôle unique pour couper l’accès d’un agent défaillant sur tous les systèmes — n’est déployée que par 21 % des organisations, laissant 79 % sans moyen automatisé d’interrompre l’accès d’un agent en cas de problème. Cet écart est directement lié au scénario d’injection de prompt documenté par 1Password, où 47 % des développeurs ont signalé qu’un agent avait effectué une action non prévue après avoir suivi des instructions cachées dans un contenu externe : détecter la déviation ne suffit pas si l’on ne dispose pas d’un mécanisme rapide et fiable de révocation des accès une fois l’incident identifié.

La revue humaine préalable à l’accès par un système IA à des données à haut risque n’est déployée que par 30 % des organisations. Les règles DLP spécifiques à l’IA, qui bloquent techniquement les données sensibles à destination d’outils IA non approuvés, sont en place dans 28 % des cas. Les journaux d’accès IA transmis à une plateforme SIEM, prérequis pour détecter tout comportement anormal d’un agent, ne sont présents que dans 33 % des organisations. Produire un audit trail IA complet — le registre permettant de répondre à la question « quel agent a accédé à quoi, et quand ? » — est encore plus difficile : seuls 27 % y parviennent en un jour ouvré, et à peine 17 % en une heure. La moitié des organisations ne peuvent pas produire ce registre en une journée ouvrée.

Chacun de ces chiffres correspond directement à un écart décrit sous un autre angle dans les deux autres enquêtes. Le constat d’Okta selon lequel seuls 46 % des RSSI se sentent capables de contrôler les accès des agents est le miroir du taux de 26 % de déploiement du purpose binding mesuré par Kiteworks. Le constat de 1Password selon lequel 40 % des développeurs accordent un accès persistant au-delà de la tâche est le symptôme, côté praticiens, du taux de 79 % d’absence de kill switch. Il ne s’agit pas de trois problèmes distincts, mais d’un même écart fondamental, mesuré de trois façons différentes, et d’ampleur comparable. Les organisations soumises à des obligations de conformité réglementaire — HIPAA, RGPD, CMMC — doivent considérer ces taux de déploiement de contrôles comme une référence sectorielle : le chiffre de 26 % pour le purpose binding signifie que 74 % des organisations du secteur exploitent des agents IA qui seront évalués par les régulateurs selon les mêmes cadres de contrôle d’accès que pour les utilisateurs humains, sans les contrôles techniques permettant de le démontrer.

Gouverner les agents comme vous gouvernez déjà les personnes

La réaction instinctive de nombreuses organisations face à de telles données est de traiter la gouvernance des agents IA comme une discipline à part entière — une filière parallèle de politiques, d’outils et de responsabilités, conçue spécifiquement pour les identités non humaines. J’ai assisté à suffisamment de présentations vantant une nouvelle « couche de gouvernance IA » pour être sceptique face à cette approche, et les données confortent ce scepticisme : cette réaction est compréhensible, mais elle explique aussi en partie l’existence de l’écart. Le constat d’Okta selon lequel une organisation sur quatre seulement applique la même politique de cycle de vie des identités aux agents qu’aux utilisateurs humains n’est pas une preuve que les agents ont besoin de leur propre règlement. C’est la preuve que la plupart des organisations n’appliquent pas encore le règlement qu’elles ont déjà.

Chacun des contrôles manquants mis en lumière par ces données — purpose binding, kill switches, audit trails disponibles en moins d’une heure, RBAC et ABAC appliqués de façon cohérente, enforcement du zéro trust au point d’accès — est un contrôle que les organisations matures appliquent déjà aux utilisateurs humains de contenu sensible. L’écart mesuré par 1Password, Okta et Kiteworks n’est pas que les agents IA manquent d’un modèle de gouvernance, mais que le modèle existant pour les personnes n’a pas encore été étendu, techniquement et systématiquement, à toutes les identités — humaines ou agents — qui accèdent à des données sensibles. Les cadres de gouvernance des données qui traitent les identités d’agents IA comme une classe gouvernée, de l’attribution initiale à la fin de la tâche et à l’expiration des identifiants — soumises aux mêmes politiques de cycle de vie que les comptes humains — permettent de combler l’écart de cycle de vie des identités mesuré par Okta dans trois organisations sur quatre.

C’est le principe du Control Plane de Kiteworks : un environnement gouverné unique où chaque demande d’accès, qu’elle provienne d’une personne, d’une application ou d’un agent IA, est évaluée selon la même politique d’accès basée sur des attributs, consignée dans le même audit trail et soumise au même mécanisme de révocation. Lorsqu’un agent IA se connecte via le Secure MCP Server, son accès au contenu gouverné est limité à chaque requête, et non accordé de façon persistante après la fin de la tâche — ce qui répond directement au schéma d’accès persistant mesuré par 1Password chez 40 % des développeurs. Kiteworks Compliant AI applique le purpose binding et la minimisation des données au niveau des politiques, afin que la portée effective d’un agent corresponde à ce qui a réellement été validé, et non à ce qu’il est techniquement capable d’atteindre — le contrôle précisément absent dans 74 % des organisations selon l’enquête Kiteworks.

Rien de tout cela ne remplace la pile IAM déjà en place dans l’organisation, et cela ne résout pas la question de la responsabilité soulevée par les répondants de 1Password — il s’agit là d’une décision organisationnelle, non technique. Ce qu’apporte une couche gouvernée d’échange sécurisé de données, c’est la preuve : un registre unique, attribuable et auditable de ce que chaque identité, humaine ou agent, a réellement fait avec du contenu sensible, produit en quelques minutes au lieu d’être demandé et attendu pendant une semaine. Ce registre permet aussi de répondre enfin à la question d’alignement du conseil d’administration soulevée par Okta avec des données factuelles, et non des estimations — car le risque approuvé par le conseil et les accès effectivement accordés sont, pour la première fois, exprimables dans les mêmes termes. Le CISO Dashboard met en avant ce registre unifié des accès agents et humains en temps réel, offrant à la direction sécurité une vision actualisée et continue qui fonde la discussion d’alignement avec le conseil sur des faits actuels, et non sur des estimations décalées.

Pour en savoir plus sur la gouvernance des accès aux données par les agents IA avec la même rigueur que pour les utilisateurs humains, réservez votre démo sans attendre !

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 en matière de 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é.