Tes équipes déploient de plus en plus d’agents IA — agents Copilot, agents personnalisés construits sur Foundry, automatisations agentiques diverses. Et depuis cette année, Microsoft ne les traite plus comme de simples comptes de service génériques : ils ont leur propre statut d’identité dans Entra ID, avec des contrôles de sécurité dédiés. Si tu gères l’identité et les accès dans ton organisation, voici ce qui a changé concrètement, et comment t’en servir pour garder la main sur ces nouveaux comptes.
Les agents IA ont désormais leur propre compte dans Entra ID
Un agent IA qui agit pour ton compte — qui lit des données, déclenche des actions, appelle des API — a besoin d’une identité au même titre qu’un utilisateur ou qu’un compte de service. Microsoft formalise ça sous la notion d’« identité d’agent » (agent identity) dans Entra ID : un objet distinct, qui peut être ciblé, gouverné et sécurisé avec les mêmes outils que ceux que tu utilises déjà pour les comptes humains — mais avec quelques mécanismes spécifiques, pensés pour le cycle de vie particulier de ces agents.
Conditional Access s’étend aux comptes d’agents
Passée en disponibilité générale en juin 2026, l’extension des protections Conditional Access aux comptes d’agents te permet désormais de :
- cibler précisément les comptes d’agents, en incluant ou excluant des agents individuels, ou en les regroupant dynamiquement via des attributs de sécurité personnalisés (custom security attributes) ;
- te protéger contre une activité d’agent à risque, en appliquant des politiques Conditional Access basées sur un score d’Agent Risk, sur le même principe que le risque de connexion pour les utilisateurs ;
- exiger des appareils conformes pour les agents qui tournent sur des points de terminaison managés, y compris Windows 365 pour les agents, garantissant que les agents ne s’exécutent que depuis des environnements conformes à tes exigences ;
- appliquer des filtres de plateforme d’appareil et de conditions réseau aux agents, sur la base de l’état de l’appareil et des emplacements réseau de confiance.
Concrètement, ça veut dire que tu peux désormais écrire une politique Conditional Access du type « tout compte d’agent taggé Team=Finance via attribut de sécurité personnalisé doit s’exécuter depuis un appareil conforme et se voit bloqué si son score de risque dépasse un certain seuil » — exactement le type de granularité que tu appliques déjà à tes comptes utilisateurs à privilèges. La documentation officielle détaille la configuration complète via le centre d’administration Entra ou Microsoft Graph.
Qui est responsable de l’agent ? Le sponsor et les Lifecycle Workflows
Un compte orphelin, sans humain responsable, est un vrai risque d’audit — c’était déjà vrai pour les comptes de service classiques, ça l’est encore plus pour des agents autonomes. Depuis mai 2026, Entra ID Governance permet de gérer le cycle de vie du sponsor d’une identité d’agent directement via les Lifecycle Workflows :
- chaque identité d’agent doit être rattachée à un sponsor humain, responsable de son accès et de son cycle de vie ;
- si ce sponsor quitte l’organisation, le parrainage de l’agent est automatiquement transféré à son manager, sans intervention manuelle ;
- les workflows incluent des tâches de notification aux co-sponsors et aux managers en cas de changement imminent de sponsor.
Résultat : tu ne te retrouves jamais avec un agent qui continue d’accéder à des ressources sensibles alors que la personne qui en était responsable a quitté l’entreprise depuis six mois. Le détail de la mise en place est documenté dans le guide « Agent identity sponsor tasks in Lifecycle Workflows ».
Mise en pratique : par où commencer
- Fais l’inventaire des identités d’agents déjà présentes dans ton tenant (centre d’administration Entra ou requêtes Microsoft Graph).
- Définis des attributs de sécurité personnalisés pour classer tes agents par équipe, criticité ou niveau de risque acceptable — c’est ce qui te permettra de les cibler finement en Conditional Access.
- Crée une politique Conditional Access dédiée aux comptes d’agents, distincte de celle de tes utilisateurs, avec des exigences adaptées (conformité d’appareil, score de risque).
- Mets en place un Lifecycle Workflow de gestion de sponsor, pour garantir qu’aucun agent ne se retrouve durablement sans responsable humain identifié.
FAQ
Un agent IA a-t-il vraiment besoin d’un compte Entra ID séparé ?
Dès qu’un agent agit de façon autonome — au-delà d’un simple appel API ponctuel avec les droits de l’utilisateur qui l’invoque — le traiter comme une identité à part entière permet de lui appliquer une gouvernance et une traçabilité propres, plutôt que de le confondre avec un compte de service générique ou avec les droits d’un utilisateur humain.
Est-ce que ça s’applique uniquement aux agents personnalisés, ou aussi à Copilot ?
Le modèle d’identité d’agent d’Entra ID est pensé comme un socle commun, que l’agent provienne de Copilot Studio, de Foundry, ou d’un développement interne. Vérifie toujours la documentation spécifique au produit agent que tu utilises, les modalités d’activation peuvent varier.
Que se passe-t-il si un agent n’a plus aucun sponsor identifiable ?
C’est précisément ce que le mécanisme de transfert automatique vers le manager du sponsor est censé éviter. En dernier recours, configure une politique d’alerte ou de désactivation automatique pour les agents qui resteraient sans sponsor valide au-delà d’un délai que tu définis.
Cette extension de Conditional Access vient compléter le changement d’enforcement que l’on avait couvert dans notre article sur Conditional Access et le changement d’enforcement de juin 2026 — les deux s’appuient sur la même mécanique de politiques, appliquée cette fois à une nouvelle catégorie d’identités. Et si tes agents tournent sur des appareils managés, ça vaut aussi le coup de relire notre article sur le bundling Intune dans M365 E3/E5, pour t’assurer que la conformité d’appareil exigée par ces nouvelles politiques est bien couverte par ta licence actuelle.
Laisser un commentaire