Microsoft Entra Agent ID : gouverner l'identité de vos agents IA

L'agent que personne n'a enregistré

C'est un samedi. Un maker bien intentionné ouvre Copilot Studio, relie un agent à une bibliothèque SharePoint et à une table Dataverse, puis le publie sur Microsoft Teams pour que quelques collègues l'essaient. Le lundi, l'agent répond aux questions en utilisant des données que le maker pouvait lire, mais que les personnes qui discutent avec lui n'étaient jamais censées voir. Personne ne l'a approuvé. Personne ne sait qu'il existe. Il n'apparaît dans aucun inventaire, et aucune policy ne s'applique à lui.

C'est le problème du shadow agent, et ce n'est pas une histoire de négligence. C'est une histoire d'identité manquante. Pendant des années, un agent IA qui devait atteindre un système d'entreprise empruntait une identité : un service principal ici, une connection reference là, un token limité à ce que le maker possédait. Quand un acteur n'a pas d'identité propre, il n'y a rien à quoi rattacher une policy, rien à auditer, rien à révoquer. On ne peut pas gouverner ce qu'on ne peut pas nommer.

Microsoft Entra Agent ID répond à ce manque. Il donne à chaque agent une identité gérée dans l'annuaire qui contient déjà vos utilisateurs, de sorte que le modèle de gouvernance appliqué aux personnes commence à s'appliquer aux agents.

Ce qu'est vraiment Entra Agent ID

Microsoft Entra Agent ID est un framework d'identité et de sécurité qui étend Microsoft Entra aux agents IA. Plutôt que d'emprunter un service principal, un agent reçoit un construct d'identité conçu pour les acteurs non humains. La plateforme introduit quatre nouveaux types d'objets : un agent identity blueprint, un blueprint principal, une agent identity et un agent user. Le blueprint fonctionne comme un modèle. Il permet à une organisation d'appliquer une fois des règles Conditional Access, des permissions et des contrôles de gouvernance, et de faire hériter automatiquement chaque instance d'agent actuelle et future. Désactiver ou révoquer une classe entière d'agents devient une seule opération.

Le changement concret pour les équipes Power Platform arrive dans les produits connectés. Copilot Studio crée automatiquement un Microsoft Entra Agent ID pour chaque nouvel agent, après le déploiement de la création automatique en juillet 2026. Quand vous construisez votre premier agent après ce déploiement, Copilot Studio ajoute à votre tenant un blueprint nommé "Microsoft Copilot Studio agent identity blueprint", et chaque agent identity est créé comme un enfant de celui-ci.

Ce que cela débloque

Dès qu'un agent a sa propre identité, la surface de gouvernance qui existe déjà pour les utilisateurs devient disponible pour les agents.

Les permissions de connecteur deviennent visibles comme API permissions. Quand un maker publie un agent Copilot Studio, chaque connecteur Power Platform utilisé par l'agent est rattaché à son Entra Agent ID comme permission d'application programming interface (API). Un administrateur Entra ou Microsoft 365 voit désormais ce qu'un agent peut appeler sans jamais ouvrir le Power Platform admin center. Ces scopes ne remplacent pas vos garde-fous existants : ils sont revalidés au runtime contre les Advanced Connector Policies et la Data Loss Prevention (DLP), et ne peuvent donc pas servir à contourner une policy déjà en place.

Conditional Access peut cibler les agents. Comme ces scopes de connecteur sont des permissions de premier ordre sur l'identité de l'agent, vous pouvez exiger une network location, une conformité d'appareil ou des conditions basées sur le risque avant qu'un token ne soit émis pour une ressource précise. Conditional Access (CA) pour les agents requiert Microsoft Entra ID Plan 1 ou Plan 2 et une licence Microsoft Agent 365 par utilisateur, l'application de la licence arrivant bientôt.

L'audit et le cycle de vie suivent. Microsoft Entra ID journalise l'activité d'authentification des agents, donc les événements de sign-in sont visibles dans l'admin center. Chaque agent identity requiert un sponsor humain responsable de son objet et de son accès, et si un sponsor part, la sponsorship est transférée automatiquement à son manager. L'accès est accordé via les mêmes access packages d'entitlement management que pour les personnes, offrant un accès limité dans le temps, auditable et avec workflows d'approbation.

La nuance qui compte : disponibilité générale ne veut pas dire "tout marche partout"

C'est ici que des attentes réalistes comptent. Microsoft Entra Agent ID comme plateforme d'identité est en disponibilité générale, et disponible pour tous les clients Microsoft Entra. C'est un vrai jalon. Mais la disponibilité générale décrit la couche d'identité, pas chaque mécanique d'application au-dessus, et la distinction est facile à manquer.

Les agents atteignent les ressources via deux flux différents, dont la maturité dans l'outillage n'est pas identique.

• On-behalf-of (OBO), aussi appelé delegated access. Un utilisateur connecté autorise l'agent, et l'agent agit avec l'identité et les permissions de cet utilisateur. Comme l'utilisateur est le sujet du token, les policies Conditional Access ciblent ici les utilisateurs et groupes, pas l'agent, et s'appuient sur les contrôles CA matures que vous exploitez déjà.
• Autonome, aussi appelé client credentials ou app-only. Aucun utilisateur n'est présent. L'agent s'authentifie comme lui-même, donc le sujet du token est l'identité de l'agent, et Conditional Access cible directement l'agent.

Les deux flux sont documentés et supportés, et Microsoft fournit des templates CA pour chacun. Le piège est que plusieurs des contrôles qui rendent les policies d'agents autonomes utiles restent étiquetés Preview dans le policy builder : l'assignation "All agent users", la condition "Agent risk" pilotée par Entra ID Protection, et la condition "Agent execution environments" qui limite les vérifications de conformité d'appareil aux agents s'exécutant réellement sur un endpoint géré. La conformité d'appareil elle-même n'est aujourd'hui évaluée que pour les agents sur Windows 365 Cloud PCs for Agents, car c'est là qu'existe l'enrollment Intune. Et les contrôles conçus autour d'un humain, comme le multifactor authentication, n'ont simplement aucun utilisateur à challenger dans un flux autonome.

Au-dessus de la couche d'identité se trouve Microsoft Agent 365, la couche opérationnelle qui permet aux agents de travailler dans Microsoft 365 comme des teammates. Plusieurs de ses capacités, dont l'onboarding d'agents avec leur propre identité dans l'expérience d'administration Microsoft 365, sont encore livrées via le programme Frontier preview plutôt qu'en disponibilité générale. Le résumé honnête pour un décideur est donc celui-ci : la fondation d'identité est prête pour la production, l'histoire d'audit et de cycle de vie est réelle, et les expériences plus avancées d'application autonome et de teammate arrivent par étapes.

Une checklist pour les leads CoE

Si vous pilotez un Center of Excellence (CoE), l'arrivée des identités d'agents est l'occasion de refermer l'angle mort du shadow agent avant qu'il ne s'élargisse. Une séquence pragmatique :

1. Confirmez la création automatique d'identité par environnement. Validez que les nouveaux agents Copilot Studio reçoivent un Entra Agent ID et localisez le blueprint Copilot Studio dans votre tenant, pour savoir où atterrissent les nouvelles identités.
2. Inventoriez avant d'appliquer. Utilisez l'Entra admin center et Microsoft Graph pour lister les agent identities existantes. Rappelez-vous que les agents antérieurs au déploiement apparaissent encore comme app registrations durant la transition, donc examinez les deux.
3. Assignez un sponsor humain à chaque agent. La sponsorship est l'ancre de responsabilité. Assurez-vous qu'aucune agent identity n'est orpheline, et appuyez-vous sur le transfert automatique sponsor vers manager pour maintenir une supervision continue.
4. Mappez les policies Conditional Access aux flux d'agents. Démarrez les policies OBO contre les utilisateurs et groupes, où les contrôles sont matures. Pilotez d'abord les policies d'agents autonomes en mode report-only, vu le statut Preview de plusieurs conditions.
5. Reliez cela à votre DLP existante. Les scopes de connecteur sur une agent identity sont revalidés contre la DLP et les Advanced Connector Policies au runtime. Traitez l'agent identity comme une couche de visibilité ajoutée à la DLP que vous exploitez déjà, pas comme un remplacement.

Le shadow agent du samedi matin ne disparaît pas parce qu'un nouveau produit est sorti. Il disparaît quand chaque agent que votre organisation construit a un nom dans l'annuaire, un sponsor qui en répond, et une policy qui décide de ce qu'il peut toucher. Entra Agent ID rend cela possible aujourd'hui. Le travail d'en faire une habitude vous revient.