L'agent IA qui travaille pour vous a probablement plus d'accès que vous

L'IA ne fait pas le travail du représentant. C'est un outil que le représentant utilise. Mais cet outil finit par avoir plus d'accès au système que la personne pour laquelle il travaille. Cet écart, un humain avec un accès limité utilisant une non-human identity avec un accès plus large, devient la forme normale du déploiement de l'IA en entreprise, et presque personne ne le vérifie comme on vérifierait les permissions d'une personne.

Rapport Netwrix 2026 sur la sécurité des données et de l'identité, basé sur une enquête auprès de 2 317 responsables de la sécurité et des TI, met des chiffres derrière ce phénomène. 72 % des organisations déclarent que le risque d'exposition des données liées à l'identité a augmenté. 58 % affirment que plus d'identités ont désormais accès aux données d'entreprise qu'auparavant. 41 % utilisent déjà une IA agentique en production, ces agents agissant au nom des humains contre des données sensibles. Les identités non humaines ne sont pas un problème futur. Elles sont déjà majoritaires dans de nombreux environnements.

La partie qui n'apparaît pas dans une revue d'accès

La plupart des programmes de gouvernance de l'identité ont été construits autour d'un rythme joiner-mover-leaver. Quelqu'un commence, son accès grandit ou change, et finalement il part et son accès est révoqué.Les comptes de service, les clés API, les certificats et les jetons d'automatisation ne suivent pas ce schéma. Ils sont créés lors d'un déploiement, hérités du modèle le plus rapide à mettre en place, puis laissés à l'abandon car personne ne gère le suivi.

Le rapport le confirme. Seulement 19 % des organisations déclarent gérer pleinement les identités non humaines. 76 % ne peuvent pas révoquer immédiatement l'accès permanent lorsqu'il n'est plus nécessaire. 64 % disposent d'un accès surprovisionné à au moins certaines données critiques. Mettez cela ensemble et vous obtenez une population d'identifiants plus grande que la main-d'œuvre humaine, plus difficile à suivre et rarement revue.

Il existe une version spécifique de ce problème qui mérite d'être soulignée : l'authentification basée sur les certificats devient le principal mécanisme de confiance pour les agents d'IA et l'automatisation, mais la plupart des organisations ont peu de visibilité sur l'infrastructure des certificats qui la sous-tend. Des modèles mal configurés, des droits d'inscription trop permissifs et des relations de confiance héritées dans Active Directory Certificate Services peuvent permettre à un attaquant d'usurper une identité privilégiée sans jamais toucher à un mot de passe.

Pourquoi c'est un problème de gestion du changement, pas seulement d'identité

Voici l’élément qui est souvent oublié. Les permissions d’un compte de service, la chaîne de confiance d’un certificat, la portée d’une clé API, rien de tout cela ne se trouve uniquement dans une plateforme d’identité. Cela réside dans les fichiers de configuration, les clés de registre, les magasins de certificats et les tâches planifiées sur les systèmes réels où le compte opère. Lorsqu’une obligation réglementaire change, qu’il s’agisse d’une nouvelle exigence PCI DSS, d’un contrôle NIST mis à jour ou d’une révision NERC CIP, la revue des accès et l’étape de révocation sont censées se produire ensemble. En pratique, c’est le côté identité qui attire l’attention tandis que le côté configuration dérive silencieusement en arrière-plan.

Cette dérive est exactement l’endroit où se cachent les modifications non autorisées. Une clé de registre qui accorde à un compte de service des droits d’inscription plus larges que nécessaire. Un fichier de configuration qui pointe encore vers une intégration désaffectée. Un modèle de certificat modifié il y a six mois que personne n’a signalé pour révision. Aucun de ces éléments n’apparaît dans un tableau de certification d’accès. Ils apparaissent lorsque quelqu’un regarde ce qui a réellement changé sur le système.

Surveiller les systèmes au lieu de simplement la liste

C'est ici que la surveillance de l'intégrité des fichiers et la gestion de la configuration de sécurité prennent toute leur importance. Netwrix Change Tracker ne gère pas les identités, mais il surveille les systèmes sur lesquels ces identités et leurs informations d'identification résident. Il établit une base de référence des fichiers de configuration, des clés de registre et des paramètres système, puis signale en temps réel toute modification qui s'écarte de cette base. Lorsqu'une règle de changement planifié existe, qu'elle soit liée à une fenêtre de correctif ou à une demande ServiceNow approuvée, les modifications correspondantes sont automatiquement filtrées. Il reste alors l'activité non planifiée : la modification du registre non approuvée, le changement de configuration sans demande correspondante, la dérive qui resterait autrement inaperçue jusqu'à ce qu'un audit ou un incident oblige quelqu'un à enquêter.

Ce modèle en boucle fermée, qui compare les modifications observées avec celles approuvées via des intégrations ITSM comme ServiceNow, BMC Remedy et Cherwell, offre aux équipes de sécurité et de conformité ce que la seule revue d'accès ne peut pas : un enregistrement au niveau système de ce qui s'est réellement passé, quand cela s'est produit et si cela était attendu. Combiné à plus de 250 rapports de conformité préconçus alignés sur des cadres comme PCI DSS, NIST, HIPAA et DISA STIG, cet enregistrement transforme le "nous pensons que nos contrôles fonctionnent" en preuve qu'un auditeur peut réellement vérifier.

Le représentant est toujours blâmé

Si cette intégration Salesforce est compromise, ou si l'assistant extrait discrètement des données en dehors de son périmètre prévu, le rapport d'incident ne nommera pas le fournisseur d'IA. Il nommera le compte qui s'est authentifié, ainsi que la personne à qui ce compte est rattaché. La gouvernance Identity peut définir la politique sur ce que ce compte est autorisé à toucher. Elle ne peut pas vous dire, seule, ce qui a réellement changé dans le système mardi dernier. C'est une question différente, et quelqu'un doit toujours surveiller la réponse.