Les entreprises reconstruisent la gestion des identités pour les agents IA, pas pour les humains
Dans une entreprise typique aujourd'hui, les agents IA et autres identités non humaines dépassent en nombre les comptes des employés humains par une large marge — certaines équipes de sécurité rapportent des ratios allant jusqu'à 45 pour 1, certaines citant des chiffres proches de 80 pour 1. Ce n'est pas un problème hypothétique du futur. C'est l'état actuel de l'identité dans toute organisation ayant adopté l'IA agentique pour ne serait-ce qu'une fraction de ses flux de travail, et cela révèle une faiblesse structurelle dans la façon dont les entreprises sécurisent l'accès à leurs systèmes.
La gestion traditionnelle des identités et des accès (IAM) a été construite autour d'une unité simple et stable : l'employé humain. Une personne est embauchée, reçoit un rôle, se voit accorder un accès lié à ce rôle, et finit par partir, moment où l'accès est révoqué. Les agents IA brisent chaque partie de ce modèle. Ils apparaissent et disparaissent en quelques secondes, représentent souvent plusieurs équipes ou flux de travail à la fois, sont fréquemment déployés par des équipes d'ingénierie ou de produit sans que l'IT en ait connaissance, et agissent à la vitesse machine sur bien plus de systèmes qu'un humain n'en touche en une journée.
Pourquoi les privilèges permanents sont le vrai risque
Le mode de défaillance central est ce que les équipes de sécurité appellent les privilèges permanents — des droits d'accès larges et persistants accordés une fois et laissés en place indéfiniment parce que les réviser est contraignant. Pour un employé humain, les privilèges permanents constituent déjà un risque connu ; les audits révèlent régulièrement des comptes avec des accès dont personne ne se souvient avoir accordé. Pour un agent IA qui fonctionne en continu et peut être manipulé par injection de prompt ou un appel d'outil compromis, les privilèges permanents transforment une seule faille exploitée en une porte ouverte sur tous les systèmes que cet agent peut toucher.
Ce phénomène est aggravé par ce que les praticiens appellent le shadow AI : des agents et outils d'automatisation déployés en dehors de la gouvernance formelle, souvent par des équipes cherchant à avancer vite, qui obtiennent un accès direct à des données sensibles sans jamais apparaître dans un inventaire central des identités. Un agent dont personne dans l'équipe sécurité ne connaît l'existence ne peut être ni surveillé, ni limité en débit, ni arrêté rapidement en cas de problème.
Ce qu'exige réellement la gestion des identités agentiques
Les fournisseurs de sécurité et architectes d'entreprise qui convergent vers une solution aboutissent à quelques pratiques concrètes, pas à un produit miracle unique :
Découverte continue. Chaque agent IA, les systèmes auxquels il se connecte, et les permissions qu'il détient actuellement doivent être visibles en temps réel — pas audités trimestriellement. Les agents créés et détruits en quelques minutes rendent un inventaire statique inutile presque immédiatement.
Accès éphémère et juste-à-temps. Plutôt que d'émettre une clé API ou des identifiants de compte de service à longue durée de vie, les agents devraient recevoir des jetons à courte durée de vie et à portée limitée, générés au moment de l'utilisation et expirant automatiquement. Cela réduit la fenêtre d'opportunité d'un attaquant en cas de fuite d'identifiants.
Autorisation granulaire. Le contrôle d'accès basé sur les rôles (RBAC), la norme pour l'IAM humain, est trop grossier pour des agents prenant des milliers de petites décisions dépendantes du contexte. Les modèles de contrôle d'accès basés sur les attributs (ABAC) ou les relations (ReBAC) permettent aux permissions de dépendre des données spécifiques, de la tâche et du contexte de risque de chaque action, pas seulement d'une étiquette de rôle statique.
Autorité déléguée et vérifiable cryptographiquement. Lorsqu'un agent agit au nom d'un utilisateur ou d'un autre système, cette délégation doit être explicite et prouvable — généralement via des standards comme l'échange de jetons OAuth 2.0 ou la fédération d'identité de charge de travail — afin qu'un agent compromis ne puisse pas usurper silencieusement une identité à privilèges plus élevés.
Auditabilité complète. Chaque action qu'un agent entreprend doit pouvoir être retracée jusqu'à une identité vérifiable et une chaîne de délégation ininterrompue. Lorsqu'un incident survient, les équipes de sécurité doivent pouvoir répondre en quelques minutes, pas en quelques jours, à la question de savoir quel agent a fait cela, sous l'autorité de qui, avec quelles permissions.
Le paysage des fournisseurs est encore en train de se structurer
Des fournisseurs d'identité comme SailPoint, Okta et CyberArk ont tous lancé ou annoncé des outils spécifiquement destinés aux identités non humaines et agentiques au cours de la dernière année, généralement sous des appellations comme IAM agentique ou tissu d'identité. Aucun de ces produits ne remplace entièrement un déploiement IAM centré sur l'humain — la plupart des entreprises font fonctionner les deux systèmes en parallèle, ce qui crée en soi un risque d'intégration et de cohérence. La réalité pratique pour la plupart des équipes de sécurité aujourd'hui est une mosaïque : IAM existant étendu avec des politiques spécifiques aux agents, gestion des secrets resserrée pour émettre des identifiants à courte durée de vie, et nouvelles couches de surveillance ajoutées pour détecter les comportements anormaux des agents en temps réel.
Ce que cela signifie si vous déployez des agents IA
Si votre organisation déploie des agents IA pour le support client, l'assistance au code, l'analyse de données ou tout autre flux de travail, traitez l'identité comme une exigence dès le premier jour, pas comme une adaptation ultérieure. Avant qu'un agent ne passe en production, il devrait avoir une identité enregistrée, des identifiants à portée et durée limitées, un responsable tenu pour compte de son comportement, et une journalisation capturant chaque action qu'il entreprend et chaque système qu'il touche. Sauter cette étape pour aller plus vite ne fait pas gagner de temps — cela ne fait que déplacer le coût de l'ingénierie vers la réponse aux incidents, et cette facture a tendance à arriver au pire moment possible.