L’accès des agents IA dépasse la responsabilité
Vos agents IA ont déjà accès aux dossiers clients, à la propriété intellectuelle sensible et aux fichiers RH. Lorsqu’un agent agit de façon malveillante, il peut être difficile pour votre organisation de déterminer qui en porte la responsabilité.
C’est le constat préoccupant dressé par l’enquête de 1Password sur l’adoption des agents IA, menée auprès de 1 000 employés à temps plein aux États-Unis, travaillant dans des entreprises de 250 salariés ou plus, répartis à parts égales entre équipes IT, sécurité et développeurs. L’enquête a été réalisée du 26 mai au 3 juin 2026. 71 % des répondants déclarent que les agents IA ont accès aux données clients, à la propriété intellectuelle sensible ou aux informations RH de leur entreprise, mais seuls 35 % affirment gérer ces agents via les processus existants de gestion des identités et des accès.
L’accès est la partie visible de tous. La question la plus difficile est celle que posera un régulateur, un auditeur ou un avocat après un incident : qui a autorisé cet accès, selon quelle politique, et où se trouve la preuve ? L’équipe en charge des identités peut vous dire qui. Seul un contrôle au niveau des données peut indiquer ce qui a été consulté, quand, selon quelle politique, et fournir la preuve correspondante. Kiteworks secure data exchange repose sur cette distinction, et c’est le prisme appliqué à l’analyse de cette enquête.
Les chiffres méritent d’être examinés de près, car le point intéressant n’est pas le nombre d’agents ayant accès aux données, mais le manque d’accord sur la responsabilité qui leur incombe.
Résumé des points clés
1. L’accès a dépassé la notion de propriété.
71 % des employés américains interrogés déclarent que les agents IA peuvent accéder aux données clients, à la propriété intellectuelle sensible ou aux informations RH, mais la responsabilité de ces agents est dispersée entre équipes, utilisateurs et dirigeants.
2. La responsabilité reste floue.
65 % estiment qu’une autre personne que celle actuellement désignée devrait être responsable, ce qui fait de la responsabilité des agents une décision de gouvernance non résolue, et non un simple organigramme.
3. Les programmes d’identités ne couvrent qu’une partie du problème.
Seuls 35 % gèrent les agents via les processus existants de gestion des identités et des accès, et 21 % n’ont formalisé aucune approche pour l’accès agentique.
4. Les identifiants sont le point faible silencieux.
86 % signalent des problèmes liés aux identifiants pour les identités non humaines, et 27 % déclarent un incident ou une faille de sécurité liée à des droits excessifs.
5. Les régulateurs exigent des preuves, pas des intentions.
Le contrôle qui compte doit prouver quel humain a délégué à quel agent, quelles données ont été consultées, selon quelle politique, et cette preuve doit pouvoir être produite à la demande.
L’enquête a mesuré la perception des employés, pas les incidents
Avant de bâtir un programme sur un chiffre, il faut savoir ce qu’il mesure. L’enquête 1Password a interrogé 1 000 employés américains sur ce qu’ils observent dans leur entreprise. Tous les chiffres sont auto-déclarés, l’échantillon est limité aux États-Unis, et 1Password commercialise des solutions de gestion des identités et des secrets, donc ses conclusions orientent vers sa propre catégorie de produits. Un RSSI sceptique doit le lire ainsi.
Cela ne rend pas les données inutiles, mais indicatives. Et c’est suffisant si la tendance se retrouve dans d’autres études indépendantes, ce qui est le cas plus loin dans cet article. L’enquête distingue aussi clairement son échantillon : 500 développeurs et 500 répondants IT et sécurité, ce qui permet la comparaison la plus révélatrice du rapport. Les développeurs, qui conçoivent et déploient les agents, sont plus nombreux à signaler des failles de sécurité dans la gestion des agents (67 %) que les équipes IT et sécurité (57 %).
Lisez bien cela : ceux qui travaillent au plus près des agents voient plus de failles que ceux chargés de les sécuriser. Ce n’est pas un problème technologique, mais un problème de visibilité, et c’est le premier point que teste un auditeur.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
La gouvernance reste à l’état de brouillon, l’accès est déjà en production
Commençons par l’adoption. Près de la moitié des développeurs (46 %) déclarent utiliser des agents IA en production aujourd’hui, et 45 % supplémentaires s’attendent à le faire d’ici deux ans. Les agents ne sont pas de simples pilotes dans un bac à sable : ils sont intégrés aux workflows, et l’enquête montre qu’ils accèdent aux données qui engagent la responsabilité de l’entreprise en cas de fuite.
Sur l’ensemble des 1 000 répondants, 62 % signalent des failles de sécurité dans la gestion des agents. Derrière ce chiffre, un autre indicateur plus discret : 33 % des répondants IT et sécurité ignorent combien d’identités non humaines ou d’agents sont utilisés dans leur entreprise. Impossible de gouverner un inventaire qu’on ne sait pas compter, ni de produire un audit sur un acteur jamais enregistré.
Vient ensuite le déficit de processus. Seuls 35 % gèrent les agents IA via les processus existants de gestion des identités et des accès, et 21 % n’ont pas encore formalisé d’approche pour la gestion de l’accès agentique.
C’est ici que le cadrage prend tout son sens. Les agents constituent une seconde catégorie d’identités, opérant aux côtés des utilisateurs humains. Le modèle de gouvernance doit couvrir les deux sous une même politique, et non gérer un programme humain et un programme agent distinct et plus léger. Un modèle d’accès basé sur les rôles conçu pour les employés suppose une personne capable de discernement. Un agent n’en a aucun. Il accède à tout ce qui lui est permis, à la vitesse de la machine, d’où la pertinence de l’accès basé sur les attributs évalué à chaque requête, bien plus adapté que des rôles statiques. Pour la même raison, la gouvernance des données IA doit partir de la donnée, pas du modèle. Les équipes sécurité qui abordent le problème sous l’angle de la sécurité du modèle posent la mauvaise question à la mauvaise personne, comme développé dans why AI agents break traditional security models.
La responsabilité incombe au plus proche, pas au véritable propriétaire
Les données sur la responsabilité devraient intéresser tout Chief Compliance Officer. Les répondants ont été interrogés sur la personne effectivement responsable des actions des agents. La réponse la plus fréquente : le responsable d’équipe ou de département (24 %). Viennent ensuite l’utilisateur de l’agent (19 %), la direction de l’entreprise (17 %) et l’équipe sécurité (13 %). 5 % estiment que l’agent lui-même est responsable.
Arrêtons-nous sur ce dernier chiffre : environ 1 répondant sur 20 travaille dans une organisation où la responsabilité incombe à un logiciel. Aucun régulateur, tribunal ou conseil d’administration n’accepte cette réponse, car un logiciel ne peut être sanctionné, poursuivi ou auditionné.
La répartition entre les autres réponses révèle le vrai problème : aucun responsable unique ne se dégage. Et lorsque 1Password demande si la personne actuellement responsable est la bonne, 65 % répondent qu’il faudrait quelqu’un d’autre. C’est un vide de responsabilité, qui se crée facilement lorsqu’une fonction accorde l’accès et qu’une autre assume le risque. Cela fait écho à the authority gap in AI workflows, où l’autorité déléguée n’est jamais formalisée.
Chez ces répondants, la propriété de la sécurité IA reste indéterminée. N’attendez donc pas qu’un organigramme règle la question. Considérez l’ambiguïté comme un problème à résoudre, en désignant explicitement un responsable pour chaque agent.
Le cadre réglementaire est simple et doit guider vos priorités. Les régulateurs réglementent la donnée, pas les modèles. Par exemple, la Security Rule d’HIPAA impose aux entités concernées et à leurs partenaires de désigner un identifiant unique pour chaque utilisateur et de mettre en place des contrôles d’audit enregistrant et examinant l’activité sur les systèmes contenant des informations médicales protégées électroniques. Aucune exemption IA n’existe. Selon moi, un agent qui lit un dossier patient doit être identifiable et traçable comme une infirmière. Un programme de conformité HIPAA incapable d’attribuer l’accès d’un agent présente un manque de preuve dès la première plainte. Le test pratique est celui décrit dans you cannot govern what you cannot attribute.
Les identifiants sont le point faible silencieux
Les agents s’authentifient via des identifiants, et l’enquête montre que ces identifiants sont gérés comme toute tâche imprévue par une équipe débordée. 86 % des répondants signalent des problèmes liés aux identifiants pour les identités non humaines, et 27 % déclarent un incident ou une faille de sécurité causé par des droits excessifs sur ces identités.
Le constat est encore plus sévère côté développeurs : parmi les 500 développeurs, 40 % accordent aux agents un accès persistant à des systèmes ou à des identifiants, 24 % codent en dur les identifiants, et 20 % partagent les identifiants via Slack ou e-mail. 43 % n’utilisent pas de gestionnaire de secrets ou de coffre-fort dédié.
Ce dernier point mérite l’attention, car il met en lumière la faiblesse d’une politique sans contrôle effectif. Beaucoup d’équipes disposent d’un coffre-fort, mais aussi d’un raccourci. Lorsqu’un agent détient un identifiant persistant copié dans un message il y a des mois, le contrôle d’accès sur le papier et celui en pratique divergent, et seul ce dernier apparaîtra dans les journaux d’audit. C’est la même faille décrite dans permissions do not determine what AI should be allowed to use : ce qu’un agent est autorisé à consulter et ce qu’il devrait pouvoir utiliser sont deux questions distinctes.
Les responsables conformité doivent s’en préoccuper pour une raison précise : une identité non humaine surdotée peut compromettre la minimisation des données dès qu’elle accède à plus d’informations que nécessaire, et cela se fait silencieusement, sans plainte utilisateur pour l’alerter.
Les recherches indépendantes confirment la tendance
Une seule enquête éditeur ne suffit pas. Trois autres sources vont dans le même sens, même si deux d’entre elles émanent aussi de fournisseurs.
Commençons par le point de vue RSSI. L’enquête de Vorlon auprès de RSSI, couverte par IT Brief UK, a interrogé 500 RSSI américains d’organisations de 500 salariés ou plus sur l’année 2025. 30,8 % signalent une exfiltration non autorisée de données via des intégrations SaaS-AI, et 86,8 % déclarent que la visibilité sur les échanges de données entre outils IA et applications SaaS reste limitée avec leurs outils actuels. Vorlon vend une plateforme de sécurité écosystémique, donc ces chiffres doivent être lus comme issus d’un fournisseur. Mais la question de la visibilité reste pertinente.
Ce constat de visibilité fait écho aux données 1Password, mais vu d’un autre poste dans l’entreprise. Les RSSI signalent un manque de visibilité sur les échanges de données entre outils IA et applications SaaS, tandis que les répondants 1Password décrivent une responsabilité dispersée pour les agents. Deux symptômes d’une faille structurelle, même si les objets mesurés diffèrent.
Regardons maintenant le point de vue des praticiens selon Kiteworks. Le rapport annuel Kiteworks Data Security and Compliance Risk : 2026 a recueilli les réponses de 459 professionnels de la sécurité, de la conformité et de la technologie au deuxième trimestre 2026, toutes auto-déclarées. 65 % ont découvert des employés utilisant des outils IA non approuvés avec des données de l’organisation, et seulement 30 % disposent d’un kill switch IA ou d’une capacité de désactivation d’agent formalisée. Shadow AI et agents non gouvernés sont deux facettes d’un même problème : outils autorisés ou non, tous accèdent à des données que personne n’a cartographiées.
Enfin, prenons le point de vue gouvernemental. Le 20 août 2026, le National Cyber Security Centre britannique a publié un article de blog, Managing the cyber risk of agentic AI. Il recommande d’attribuer à chaque agent une identité unique, de limiter la durée de vie des identifiants, de désigner des individus ou groupes responsables de l’activité IA agentique lorsque des conséquences graves sont possibles, de définir les situations où un agent doit s’arrêter et demander une validation humaine, et de rendre les journaux immuables autant que possible. Il précise aussi que les organisations doivent pouvoir interrompre immédiatement l’activité d’un agent. Je considère cette liste comme une checklist de preuves. Chaque point correspond à une question qu’un régulateur peut poser.
Pourquoi l’identité seule ne suffit pas à produire la preuve
L’identité répond bien à une question : qui ou quoi fait la demande ? Auditeurs et régulateurs en posent quatre : qui a délégué, quelles données ont été consultées, selon quelle politique, et pouvez-vous le prouver ? La première relève de l’identité. Les trois autres sont du ressort de la donnée. C’est le point développé dans identity knows who, data knows what, et c’est pourquoi une organisation peut disposer d’un programme IAM irréprochable et échouer à fournir une preuve.
La liste de souhaits issue de l’enquête confirme ce manque. Lorsqu’on leur demande ce dont ils ont besoin pour élargir l’usage des agents, 53 % veulent une responsabilité claire pour chaque action d’agent, 52 % souhaitent une vue centralisée des accès humains et agents, et 51 % réclament une traçabilité complète. Seuls 5 % n’expriment aucun besoin. Ces trois attentes ont un point commun : aucune ne concerne un meilleur modèle. Toutes relèvent du contrôle de la preuve et de l’attribution.
C’est l’argument architectural en faveur d’une gouvernance au niveau de la donnée. Kiteworks Compliant AI régit les interactions des agents avec les données réglementées au niveau de la donnée, pas du modèle. L’application des règles ne dépend donc pas d’un prompt, d’un filtre de sécurité ou d’un framework d’agent particulier. Chaque interaction passe quatre points de contrôle : l’agent s’authentifie via OAuth 2.0 et est lié à l’humain qui a délégué le workflow ; l’accès est évalué selon l’identité de l’agent, la classification des données et le contexte ; les données sont protégées par un chiffrement validé FIPS 140-3 en transit et au repos ; enfin, chaque interaction est inscrite dans un journal d’audit infalsifiable, avec attribution complète, transmis en temps réel au SIEM.
Le Kiteworks Secure MCP Server applique la même logique aux clients IA tels que Claude et Copilot. Chaque requête est évaluée selon des contrôles basés sur les rôles et les attributs, afin que le client IA ne reçoive que les données autorisées par la politique, et que chaque accès à un fichier, opération sur un dossier ou extraction de données soit autorisé, contrôlé et journalisé. L’authentification OAuth 2.0 permet à chaque opération IA d’hériter des autorisations de l’utilisateur, plaçant humain et agent sous une même politique et un même journal d’audit. Le moteur de politique de données rend cette politique unique applicable sur tous les canaux, et les journaux d’audit la rendent lisible par un régulateur.
Le principe de conception est la parité. Une gouvernance qui couvre les humains mais pas les agents laisse une population croissante de consommateurs de données hors du champ de la preuve. Une gouvernance qui ne couvre que les agents, sans les humains qui leur délèguent, rompt la chaîne de responsabilité. Les deux échouent au même audit.
Ce qu’il faut changer avant la prochaine demande d’audit
Aucun de ces points ne nécessite un nouvel outil avant de nécessiter une décision. Commencez par les décisions, car la technologie ne fait qu’appliquer ce qui a été écrit.
Désignez un responsable pour chaque agent. Les 65 % qui estiment qu’un autre devrait être responsable révèlent que l’attribution n’a jamais été faite : faites-la. Le responsable peut être un rôle plutôt qu’une personne, mais il doit être nommé et identifiable par un régulateur. C’est aussi le point de départ du zero trust pour l’IA générative : aucun agent n’est digne de confiance par défaut, et chaque agent doit être rattaché à un humain responsable.
Recensez vos agents. Si un tiers de vos équipes IT et sécurité ignore combien d’agents et d’identités non humaines existent, l’inventaire est la première étape. Incluez les identifiants détenus par chaque agent et leur emplacement.
Placez les agents sous la même gouvernance des identités et des accès que les humains, avec des identifiants à durée de vie courte et aucun secret persistant dans les outils de messagerie. Ajoutez ensuite des politiques au niveau de la donnée, pour que l’identité contrôle l’entrée et la politique contrôle la sortie.
Testez le kill switch. Seuls 30 % des répondants à l’étude Kiteworks en disposent. Un contrôle jamais testé n’est qu’une hypothèse. Faites un exercice qui arrête un agent et mesurez le temps nécessaire pour retrouver précisément les données consultées.
Enfin, entraînez-vous à répondre à une demande de preuve. Choisissez un agent, une semaine, une question type régulateur, et produisez l’enregistrement. Si l’exercice prend des semaines, vous avez identifié la faille avant l’examinateur.
Le constat est cohérent à travers l’enquête, la recherche RSSI et les recommandations du NCSC : l’accès a pris de l’avance, la responsabilité suit. Les organisations qui combleront cet écart seront celles qui traiteront l’accès agentique comme une activité gouvernée, attribuable et traçable dès la première requête.
Pour en savoir plus sur la gouvernance de l’accès aux données par les agents IA dans des environnements réglementés, réservez votre démo personnalisée dès maintenant.
Foire aux questions
En général, non. Les régulateurs imposent des obligations liées à la donnée et à l’organisation qui la détient, qu’un humain ou un agent consulte l’enregistrement. Par exemple, la Security Rule d’HIPAA exige une identification unique des utilisateurs et des contrôles d’audit, sans exception pour l’IA. Un agent qui accède à des informations médicales protégées électroniques doit donc être traçable. Considérez les agents comme une seconde catégorie d’identités, sous le même modèle de gouvernance, et cartographiez leur activité avec les mêmes preuves GRC que pour les utilisateurs humains.
L’enquête montre que les organisations n’ont pas tranché ce point. Les répondants citent le responsable d’équipe (24 %), l’utilisateur (19 %), la direction (17 %) et l’équipe sécurité (13 %), et 65 % estiment qu’un autre responsable serait plus approprié. L’approche la plus solide consiste à désigner un propriétaire pour chaque agent avant son déploiement, et à relier l’agent à l’humain qui lui a délégué son workflow. Kiteworks Compliant AI associe chaque agent à l’humain qui l’a autorisé et consigne les interactions dans un journal d’audit avec attribution complète, rendant le responsable visible dès le départ.
Considérez-la comme une indication, pas comme une preuve. L’enquête 1Password est auto-déclarée, ne concerne que des employés américains et provient d’un fournisseur de solutions de gestion des identités et des secrets. Sa valeur réside dans le fait que d’autres sources, comme l’étude RSSI de Vorlon et l’article du NCSC britannique sur l’IA agentique, vont dans le même sens. Bâtissez votre programme sur votre propre inventaire et vos tests de preuve, et utilisez l’enquête pour justifier leur mise en œuvre. Une approche zero trust data exchange repose sur la vérification, pas sur la confiance, ce qui vaut autant pour la recherche que pour l’accès.
En partie. Seuls 35 % des répondants gèrent les agents via les processus IAM existants, et l’identité répond à la question « qui fait la demande », mais pas à « quelles données un agent peut-il utiliser et dans quel but ». Étendez la gouvernance des identités aux agents, puis ajoutez des politiques évaluées à chaque requête selon la classification des données et le contexte, pour que l’agent ne reçoive que les données strictement nécessaires. La règle HIPAA du minimum nécessaire est un bon modèle pour ce principe. Le Kiteworks Secure MCP Server montre comment appliquer ce contrôle à chaque requête devant les clients IA.
Vous devez pouvoir démontrer quel humain a délégué à l’agent, quelles données il a consultées, quelle politique l’a autorisé, si les données étaient chiffrées, et fournir un journal infalsifiable de chaque opération. Entraînez-vous à produire ce dossier et chronométrez-vous. Selon l’enquête, 51 % souhaitent une traçabilité complète pour élargir l’usage des agents, ce qui constitue un bon standard. Commencez par vérifier que vos journaux d’audit enregistrent l’activité des agents avec la même attribution que celle des humains, puis entraînez-vous à répondre à la demande.
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
AI Governance Gap : 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é.