Vos agents autonomes tournent déjà en production—s’authentifiant auprès d’API, accédant aux données critiques, déclenchant des flux de travail avec de vrais identifiants. Et tout cela se passe presque entièrement en dehors de votre cadre de gouvernance des identités. Ce fossé architectural est désormais un blocage opérationnel, pas une question de conformité.
Vos agents autonomes sont déjà en production. Une enquête menée en janvier 2026 par la Cloud Security Alliance montre que 67 % des organisations exécutent des agents d’automatisation de tâches, 52 % déploient des agents de récupération de données, et un tiers ont des agents de génération de code modifiant activement l’infrastructure. Ces agents s’authentifient auprès des API d’entreprise, assument des rôles IAM, parcourent le stockage cloud et invoquent des flux de travail—tout cela en dehors des programmes de gouvernance conçus pour contrôler précisément ce type d’accès.
Le problème est structurel, pas accidentel. L’architecture d’identité traditionnelle a été construite pour les utilisateurs humains ou les comptes machines statiques. Les agents ne sont ni l’un ni l’autre. Ce sont des systèmes éphémères et conscients du contexte qui délèguent leur propre autorité, raisonnent sur ce qu’il convient de faire ensuite, et prennent des décisions autonomes à grande échelle. Vos outils IAM ne peuvent pas les voir. Vos cycles de révision d’accès ne les atteignent jamais. Vos identifiants ne sont liés à aucun propriétaire dans votre catalogue IGA. En moyenne, seuls 47 % des agents d’entreprise sont activement surveillés ou sécurisés. Les autres ? Opérant sans visibilité.
Pourquoi les passerelles seules ne suffiront pas.
J’observe régulièrement les équipes construire une infrastructure de passerelle sophistiquée—serveurs MCP, courtiers de jetons, wrappers API—avant d’établir l’identité des agents. Ça finit toujours mal. Une passerelle sans identité en amont est un checkpoint sans registre. Vous pouvez enregistrer ce qu’un agent a essayé de faire, mais vous ne pouvez pas prouver qui l’a autorisé à le faire, tracer la décision jusqu’à un humain, ou révoquer son accès de manière crédible quand quelque chose tourne mal. Pire encore : 63 % des organisations ne peuvent pas appliquer des limitations de finalité sur leurs agents. Elles savent ce que l’agent devrait faire, mais manquent des contrôles techniques pour empêcher d’autres actions.
Voici un scénario concret : imaginons une PME de logistique de 40 personnes exécutant un agent autonome de traitement de factures. Il s’authentifie avec des identifiants provisionnés il y a six mois—personne ne se souvient par qui ou pour quel périmètre. L’agent a un accès permanent à l’ERP comptable, aux emails et au système de demandes de frais. Un jour, une attaque par injection de requête le trompe et l’entraîne à transférer toutes les factures en attente vers le compte d’un concurrent. Votre passerelle a enregistré les appels API. Vos alertes se sont déclenchées. Mais comme l’agent n’a pas d’entrée d’identité formelle dans votre IGA, aucun dossier d’approbation et aucune autorisation par action, vous ne pouvez pas révoquer les identifiants en secondes. Vous devez retracer les logs, trouver l’infrastructure-as-code qui l’a provisionné, reconstruire l’agent et le redéployer. C’est des heures de récupération, pas des minutes.
L’industrie ne converge que maintenant sur ce qui doit arriver en premier. L’infrastructure d’identité d’agent comporte six niveaux, et la plupart des entreprises n’en ont qu’un ou deux en production. Niveau un : un catalogue d’identités qui suit chaque agent—son nom, propriétaire, objectif, périmètres enregistrés et étape du cycle de vie. Niveau deux : émission de jetons OAuth ou OIDC, de sorte que les agents s’authentifient en utilisant des protocoles standard, pas des identifiants permanents. Niveau trois : autorisation par action, où chaque invocation d’outil est contrôlée individuellement, pas un périmètre global. Niveau quatre : provisionnement de credentials juste-à-temps, où l’agent reçoit l’accès uniquement pour l’action spécifique qu’il s’apprête à effectuer. Niveau cinq : audit au moment de l’exécution, capturant non seulement ce qui s’est passé mais pourquoi—quelle décision humaine a autorisé cet agent à faire cela à ce moment précis. Niveau six : plans de révocation et réponse aux incidents.
La plupart des PME ne sont nulle part au niveau trois. Nombreuses ne sont pas arrivées au niveau un.
Ce que cela signifie pour la planification du déploiement.
Si vous construisez un agent pour la production, l’identité et l’attribution de l’agent sont désormais un prérequis obligatoire, pas un raffinement futur. Commencez avant de construire la logique de l’agent. Mappez les identifiants dont il a besoin, créez une entrée d’identité dans votre catalogue IGA (même si votre outil IGA ne supporte pas officiellement les agents—utilisez les attributs personnalisés et les workflows manuels), et concevez votre authentification de sorte que chaque action soit individuellement délimitée. Cela ne nécessite pas des outils révolutionnaires. Cela nécessite de la discipline architecturale.
Les fournisseurs le savent. Les modèles d’agents contraints dominent en production précisément parce qu’ils vous forcent à délimiter l’accès avant le déploiement. Microsoft Entra propose désormais Agent ID comme classe d’identité distincte. Okta supporte la délégation OAuth 2.1 pour les agents. Delinea et les fournisseurs de matériel intègrent l’autorisation attestée par l’humain—de sorte que chaque action à haut risque effectuée par un agent est traçable jusqu’à une décision humaine vérifiée.
Ce qui tue les déploiements d’agents n’est pas la complexité technique. C’est la dette architecturale. Vous ajouterez des passerelles et des contrôles API plus tard. Commencez maintenant avec l’identité.
Identité d’agent ou passerelle : quelle est la différence réelle ?
Pourquoi une passerelle seule ne suffit-elle pas ?
Une passerelle contrôle l’accès aux données. L’identité contrôle qui demande cet accès et pourquoi il devrait être autorisé à le faire. Sans identité en amont, une passerelle est médico-légale—elle enregistre et rejette—mais pas préventive. Vous ne pouvez pas révoquer l’accès d’un agent si vous ne savez pas qui il est ou ce qu’il a été autorisé à faire. Une passerelle plus l’identité est préventive : elle lie chaque action à une décision, chaque décision à un propriétaire, et chaque propriétaire à des pistes d’audit.
Quel est le risque si nous sautons l’identité d’agent et allons directement au confinement ?
Dérive des identifiants. Quand les identifiants d’un agent ne sont pas formellement enregistrés, ils vivent dans l’infrastructure-as-code, les variables d’environnement, ou les notes de quelqu’un. Personne ne se souvient de l’accès prévu. Personne ne le recertifie. Des mois plus tard, l’agent utilise des permissions dont il n’a plus besoin, ou l’accès a été accordé pour des flux de travail qui n’existent plus. Un attaquant qui compromet un identifiant d’agent peut assumer son identité et invoquer des outils que l’agent n’était pas censé avoir. Sans catalogue d’identité et limitation par action, vous n’avez aucun moyen de détecter que l’agent agit de manière anormale.
Pouvons-nous utiliser notre plateforme IAM existante pour les agents ?
Partiellement. La plupart des plateformes d’identité d’entreprise—Okta, Microsoft Entra, PingIdentity—peuvent désormais émettre des jetons pour les agents et intégrer les flux OAuth. Mais elles n’ont pas été conçues pour les modèles d’autorisation éphémères et dépendants du contexte que les agents exigent. Vous aurez besoin d’extensions d’attributs personnalisés, d’automatisation de workflows, ou d’une couche d’identité d’agent dédiée par-dessus. Le test architectural est simple : votre catalogue IGA peut-il répondre avec autorité, dès maintenant, « Quels agents existent, qui les possède, et que sont-ils autorisés à faire ? » Si non, vous avez besoin de plus qu’un simple émetteur de jetons.
Sources
- Agentic AI Identity Security: Closing the Gaps Agents Exploit
- AI Agent Identity for Enterprise Security at Scale | Okta
- Who owns AI agent access? At most companies, nobody knows – Help Net Security
- Identity for AI Agents and Agentic Authentication 2026
- AI agent security: the complete enterprise guide for 2026 | MintMCP Blog
- 7 Best AI Agent Authentication Platforms (2026) – Arcade.dev
0 Comments