Pendant des années, les équipes de sécurité informatique ont structuré leurs programmes autour d’un principe simple : si vous contrôlez les identités, vous maîtrisez le risque. Les employés s’authentifient auprès de fournisseurs d’identité. Les comptes de service relient les systèmes. Les clés API permettent aux charges de travail de communiquer avec les services cloud et les bases de données.
Les acteurs étaient très prévisibles. En conséquence, le modèle de gouvernance et de sécurité des identités s’est calqué sur cette prévisibilité. Aujourd’hui, ce principe est remis en cause.
Les agents IA sont entrés dans les entreprises discrètement. Ils résument des réunions, rédigent des courriels et aident les employés à trouver des informations. La plupart des équipes de sécurité ne se sont pas préoccupées d’eux dans un premier temps. Ils ressemblaient à des outils de productivité, car c’était exactement leur fonction.
Ensuite, les organisations les ont connectés à des services métier critiques comme Salesforce, Snowflake, GitHub, Jira, des bases de données de production et des environnements cloud. Désormais, ces agents récupèrent des informations, déclenchent des flux de travail, mettent à jour des enregistrements, écrivent et déploient du code, et effectuent des actions à travers de multiples systèmes.
Parfois, ils agissent pour le compte d’un humain. Parfois, ils opèrent de façon autonome. Et parfois, il est difficile de déterminer qui est à l’origine de l’action.
Cela transforme les agents IA en bien plus que de simples outils. Ils deviennent des identités à part entière, et la majorité des entreprises ne possèdent aucun modèle de sécurité ou de gouvernance pour les gérer.
Ce schéma se répète dans toutes les organisations. Une nouvelle couche d’identité se construit au-dessus de l’infrastructure existante, sans quasiment aucun des contrôles que les équipes identité ont mis en place au cours de la dernière décennie. Un agent peut être créé par une équipe, utilisé par une autre, connecté à cinq applications différentes, et il fonctionne avec des identifiants qui étaient prévus pour un objectif totalement distinct.
Il obtient des accès étendus dès le départ car quelqu’un avait besoin qu’il fonctionne et ne voulait pas ralentir le processus. Le résultat est une prolifération d’acteurs très privilégiés mais peu visibles, que la plupart des équipes de sécurité ne peuvent pas inventorier, et encore moins superviser.
Les agents IA créent, utilisent et renouvellent des identités à la vitesse de la machine, ce qui dépasse les capacités des contrôles IAM traditionnels.
Selon une enquête de 2026 commandée par Token Security, 82 % des organisations ont découvert au moins un agent IA créé à l’insu des équipes de sécurité, d’informatique ou de gouvernance au cours de l’année écoulée. Dans 41 % des cas, cette situation s’est produite à plusieurs reprises.
La conversation sur la sécurité a pris une mauvaise direction. La majeure partie de l’attention portée à la sécurité de l’IA s’est concentrée sur les risques liés aux modèles, comme l’injection d’invites, les contournements de restrictions ou les sorties non sécurisées. Bien que ces aspects fassent partie intégrante de l’écosystème de l’IA agentique, ils ne donnent pas une image complète de la situation pour les équipes de sécurité. L’élément le plus important qu’elles doivent connaître est le suivant : à quoi l’agent peut-il réellement accéder ?
Un agent qui résume une documentation publique présente un rayon d’impact limité. Un agent connecté aux dossiers clients, au code source, aux systèmes financiers et à des identifiants cloud de niveau administrateur constitue un problème tout à fait différent.
Une mauvaise instruction, une session compromise, un plugin malveillant ou une intégration mal configurée peuvent transformer un agent trop permissif en une voie pour l’exfiltration de données, des actions destructrices ou des mouvements latéraux à travers des systèmes qui n’étaient pas censés être connectés.
Ce risque n’est plus théorique. 65 % des organisations ont subi un incident de sécurité impliquant un agent IA l’année dernière, et 61 % d’entre elles ont signalé une exposition ou une mauvaise manipulation de données sensibles.
Pour reprendre le contrôle, il faut d’abord obtenir de la visibilité. Les équipes de sécurité ont besoin de découvrir les agents IA et de les inventorier. Cette démarche doit aller au-delà des simples noms et plateformes pour répondre aux questions essentielles.
Qui est le propriétaire de cet agent ? Qui peut l’invoquer ? À quels systèmes est-il connecté ? Quels identifiants utilise-t-il ? Que peut-il lire, écrire, supprimer ou exécuter dans chaque application cible ?
Cette tâche est plus complexe qu’il n’y paraît, car la surface d’exposition n’est pas évidente. Une équipe de sécurité peut savoir qu’un assistant commercial existe sur une plateforme IA, mais elle ignore qu’il fonctionne avec un compte de service Snowflake qui dispose de privilèges d’administrateur. Elle peut connaître l’existence d’un agent de codage installé sur les postes des développeurs, sans savoir quels secrets, dépôts et pipelines d’intégration continue il peut atteindre.
L’agent lui-même ne représente qu’une partie du tableau. Tout ce que les identités de l’agent peuvent toucher constitue la véritable surface d’exposition.
Le deuxième élément est l’intention. La sécurité et la gouvernance ne peuvent pas reposer uniquement sur des permissions avec les agents IA. Elles doivent tenir compte de l’objectif de l’agent. Un agent de préparation commerciale n’a besoin que d’un accès en lecture aux enregistrements du CRM. Il ne doit pas pouvoir supprimer des tables de base de données.
Un agent de flux de travail financier doit seulement lire les factures. Il ne doit pas pouvoir créer de nouveaux utilisateurs privilégiés. Lorsque l’on comprend la tâche qu’un agent est censé accomplir, on peut évaluer si ses permissions correspondent à ce périmètre. Dans la pratique actuelle, c’est rarement le cas. C’est dans cet écart que réside le risque réel, et il ne fait que s’élargir avec le temps à cause de la dérive des politiques de moindre privilège.
Une fois que l’intention est comprise, la mise en application devient possible. Les permissions peuvent être ajustées pour correspondre à l’objectif réel de l’agent. Les comptes de service trop permissifs peuvent être corrigés. Les identifiants inutilisés peuvent être renouvelés ou supprimés. Les connexions risquées peuvent être identifiées avant qu’elles ne se transforment en incidents.
Ce qui bloque la plupart des équipes, c’est que rien de tout cela n’est un exercice ponctuel. Une revue d’accès ou un audit peut donner une impression de progrès, mais ils ne fournissent qu’une validation à un instant T et un faux sentiment de sécurité. La raison est que les agents évoluent, les instructions sont mises à jour, la base d’utilisateurs change et les intégrations se développent.
Un agent qui a commencé comme un outil interne restreint peut finir par être connecté à des systèmes qu’il n’était pas conçu pour toucher. Cela n’arrive pas parce qu’une décision erronée a été prise, mais parce que personne ne surveillait lorsque le périmètre s’est étendu.
C’est pourquoi la gouvernance doit être continue. Elle doit repérer les agents qui commencent à accéder à des applications en dehors de leur schéma habituel, qui utilisent des identifiants inattendus ou qui effectuent des actions qui ne correspondent pas à leur objectif déclaré.
Les entreprises qui réussiront avec l’IA ne seront pas celles qui bloqueront complètement les agents. Ce seront celles qui les rendront gouvernables et qui favoriseront une innovation sécurisée en matière d’IA. Cela signifie les traiter comme des identités de premier plan, avec des propriétaires désignés, des contrôles d’accès, de comportement, de risque et de cycle de vie.
Les agents IA deviennent des initiés privilégiés. Les programmes de sécurité et de gestion des identités doivent désormais rattraper leur retard, avant que ces initiés ne deviennent des chemins d’attaque invisibles.