Gouvernance des agents IA avec Agent 365 et Entra Agent ID

Un agent tourne peut-être déjà dans votre tenant sans que personne n'en soit officiellement responsable : un maker Copilot Studio un peu trop créatif, un connecteur Microsoft Foundry publié avec une identité de projet partagée, ou un vieux principal de service devenu autonome à force d'automatisations empilées. Cet article s'adresse aux administrateurs Microsoft Entra ID et Microsoft 365 qui doivent reprendre la main sur cette population avant qu'elle ne devienne incontrôlable. Vous y trouverez le modèle Microsoft Entra Agent ID, la place réelle de Microsoft Agent 365, et un plan de 30 jours pour transformer une population d'agents anonymes en identités gouvernées.


Pourquoi les agents IA sont un problème d'identité, pas d'application

Toute discussion sur la gouvernance des agents IA finit par retomber sur une évidence que les équipes identité connaissent depuis dix ans : ce qui compte n'est pas ce qu'est un logiciel, mais ce qu'il peut faire. Un agent qui lit des boîtes mail, dépose des documents, ouvre des tickets et écrit à des clients n'est pas une application au sens classique. C'est un collaborateur — infatigable, littéral, sans jugement ni crainte des conséquences, et jusqu'à récemment, sans identité propre.

C'est précisément là que le bât blesse historiquement. Les agents ont emprunté des identités existantes : un principal de service par-ci, un identifiant applicatif stocké dans un fichier de configuration par-là, hérité des permissions de celui qui l'a créé. Résultat classique : sur-permissionné, sous-surveillé, sans propriétaire. Les agents héritent de cette pathologie et y ajoutent l'autonomie. Un compte de service doté de la permission Mail.ReadWrite est déjà un risque ; le même compte doté d'initiative devient une nouvelle catégorie de risque.

La réponse de Microsoft, déployée entre 2025 et 2026, consiste à cesser de traiter les agents comme des applications pour les traiter comme des identités à part entière : des objets d'annuaire avec propriétaire, cycle de vie, accès scopé et conditions de connexion.

Ce qui tourne déjà dans votre tenant, sans que vous le sachiez

Avant le modèle, le recensement inconfortable. Dans un tenant type mi-2026, les agents entrent par au moins cinq portes, la plupart non surveillées :

Ce tableau ne vise pas à faire peur mais à délimiter le périmètre. Les trois premières portes sont gouvernables avec le modèle décrit dans cet article. La quatrième relève d'un durcissement classique des identités de charge de travail sur les principaux de service et les inscriptions d'applications. La cinquième est un problème de poste de travail — inventaire logiciel Microsoft Defender, stratégie Intune — qui mérite un traitement séparé.

Le modèle Entra Agent ID : quatre objets, un humain responsable

Microsoft Entra Agent ID introduit quatre types d'objets. Les noms sont longs, le modèle sous-jacent est net :

Deux propriétés portent l'essentiel du poids de gouvernance. D'abord, l'héritage descend du blueprint : les permissions et les politiques Conditional Access appliquées au niveau du blueprint atteignent chaque identité d'agent qui en est issue. Vous gouvernez ainsi toute une plateforme d'agents avec une seule politique, plutôt que de courir après chaque individu. Ensuite, chaque identité d'agent peut avoir un sponsor : un humain nommé, responsable de son cycle de vie et de ses décisions d'accès.

Les plateformes se branchent déjà sur ce modèle. Microsoft Foundry auto-provisionne blueprints et identités à la création et à la publication d'un agent. Copilot Studio assigne automatiquement des identités d'agent, une capacité documentée comme préversion dans la documentation Microsoft Learn sur l'utilisation des identités Entra dans Copilot Studio. Les développeurs Teams gèrent leurs blueprints dans le portail développeur. La direction est sans ambiguïté : l'identité d'agent devient la plomberie par défaut, et les tenants qui apprennent ce modèle maintenant gouverneront par politique quand les autres gouverneront par archéologie.

Où se situe Microsoft Agent 365, et ce qu'il coûte réellement

Si Entra Agent ID est la couche identité, Microsoft Agent 365 est le plan de contrôle au-dessus : l'inventaire des agents à travers l'environnement, leurs permissions, leur comportement et leur activité en un seul endroit, chaque agent portant en dessous son propre Entra Agent ID. Microsoft a annoncé la disponibilité générale de Microsoft Agent 365 dans un billet de blog Microsoft Security publié le 1er mai 2026.

La licence, à ce stade, se lit par capacité et non comme un interrupteur unique :

En clair : ne présumez pas que « nous avons P1 » débloque toute la pile de gouvernance des agents. L'inventaire et la sponsorisation coûtent de l'attention ; l'automatisation, le risque et le plan de contrôle coûtent une licence.

Sponsors et accès : la discipline qui fait tenir l'ensemble

Voici la décision de conception qui mérite d'être défendue en revue d'architecture : une identité d'agent porte toujours un sponsor humain, et quand ce sponsor quitte l'organisation, la sponsorisation est transférée automatiquement à son manager. Les Lifecycle Workflows peuvent notifier co-sponsors et managers autour de cette transition, selon la documentation Microsoft Learn sur les tâches de sponsor d'identité d'agent.

Quiconque a géré des identités plus d'un an sait pourquoi c'est important. L'objet le plus dangereux d'un annuaire n'est pas le compte sur-permissionné, c'est le compte orphelin : l'automatisation que personne ne possède, qui fait quelque chose que personne ne se rappelle, que personne n'ose désactiver car le dernier à comprendre est parti depuis longtemps. La règle du sponsor, appliquée dès la naissance et transférée au départ, rend cet état structurellement impossible.

Côté opérationnel, les sponsors gèrent leurs agents depuis le portail Mon compte (activer, désactiver, consulter l'activité et le cycle de vie) et demandent l'accès en leur nom depuis le portail Mon accès. Le détail complet des rôles est décrit dans la documentation Microsoft Learn sur les relations administratives des identités d'agent (propriétaires, sponsors, managers).

Les blueprints fixent le plafond, les packages d'accès expirent

L'accès des agents fonctionne à deux niveaux. Au niveau du blueprint, les identités d'agent naissent avec des permissions héritées limitées : c'est l'endroit naturel pour fixer un plafond, par exemple ce qu'un agent Copilot Studio d'un environnement donné peut toucher. Traitez la revue de ces permissions héritables comme une revue de permissions API sur une inscription d'application, car c'est fonctionnellement ce qu'elle est.

Au niveau de l'identité, les octrois individuels passent par la gestion des droits d'accès (entitlement management) : les mêmes packages d'accès utilisés pour les humains et les invités, désormais assignables aux identités d'agent, avec un scope explicite « tous les agents ». La documentation Microsoft Learn sur les packages d'accès pour identités d'agent détaille les trois voies de demande possibles : l'agent demande lui-même de façon programmatique, le sponsor demande en son nom (le point d'équilibre opérationnel, avec contexte métier et piste d'audit), ou un administrateur assigne directement.

Conditional Access et Identity Protection étendus aux agents

Dernière couche : les conditions sur la manière dont les agents se connectent. Les politiques Conditional Access peuvent cibler les identités d'agent, évaluer leur contexte et leur risque — y compris le risque d'identité d'agent remonté par Entra ID Protection — et surtout être appliquées au niveau du blueprint, si bien que chaque identité créée à partir de ce blueprint hérite de la politique dès sa naissance. Le détail est dans la documentation Microsoft Learn sur Conditional Access pour les agents et sur Identity Protection pour les agents (agents à risque).

Pour une équipe réduite, reprenez le schéma de votre baseline Conditional Access humaine : démarrez petit, en mode rapport seul là où c'est possible, en scopant sur les blueprints plutôt que sur des identités individuelles. Si Identity Protection pour les agents est licenciée (Entra ID P2 en préversion), commencez par un blocage basé sur le risque en mode rapport avant l'application. Sinon, posez des frontières explicites d'autorisation ou de blocage pour les identités et ressources approuvées. Gardez en tête une limite structurelle : les politiques scopées sur un blueprint couvrent les identités d'agent, pas les comptes utilisateur agent, et Conditional Access ne protège que les chemins d'accès qui passent réellement par Microsoft Entra ID. Un agent qui atteint une ressource via une clé API ou une authentification hors Entra reste hors de ce périmètre.

Mise en œuvre : recenser les principaux de service hérités avant Agent 365

Pour les surfaces natives d'Agent ID — blueprints et identités d'agent créés par Copilot Studio ou Foundry — l'inventaire reste aujourd'hui une opération de portail, via le centre d'administration Entra, car les API sont encore en préversion et trop instables pour un script de production fiable. En revanche, la quatrième porte du tableau plus haut — les principaux de service hérités qui pilotent déjà des workloads IA sans identité d'agent dédiée — se prête parfaitement à un inventaire scripté via le module Microsoft Graph PowerShell.

Module requis : Microsoft.Graph (sous-module Microsoft.Graph.Applications), version 2.x ou supérieure. Installation : Install-Module Microsoft.Graph -Scope CurrentUser. Permission minimale : Application.Read.All en lecture seule, avec un rôle Entra de type Global Reader ou Cloud Application Administrator. Sortie : un fichier CSV listant les principaux de service sans propriétaire déclaré ou porteurs d'une permission Microsoft Graph sensible, base de départ de la colonne « legacy » de votre recensement à cinq colonnes.

1# Connexion avec le scope minimal nécessaire pour une lecture seule
2Connect-MgGraph -Scopes "Application.Read.All", "Directory.Read.All"
3 
4# Permissions Microsoft Graph considérées comme sensibles pour un agent autonome
5$permissionsSensibles = @(
6    "Mail.ReadWrite", "Mail.Send", "Sites.FullControl.All",
7    "Files.ReadWrite.All", "User.ReadWrite.All", "Directory.ReadWrite.All"
8)
9 
10# Récupère tous les principaux de service de type Application
11$servicePrincipals = Get-MgServicePrincipal -All -Property "Id,DisplayName,AppId,ServicePrincipalType,Tags" |
12    Where-Object { $_.ServicePrincipalType -eq "Application" }
13 
14$resultats = foreach ($sp in $servicePrincipals) {
15 
16    # Propriétaires déclarés : leur absence est un signal d'objet potentiellement orphelin
17    $proprietaires = Get-MgServicePrincipalOwner -ServicePrincipalId $sp.Id -ErrorAction SilentlyContinue
18 
19    # Permissions applicatives accordées à ce principal de service en tant que client
20    $assignations = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id -ErrorAction SilentlyContinue
21 
22    $permissionsAccordees = @()
23    foreach ($assignation in $assignations) {
24        # Résout le nom lisible de la permission à partir du rôle applicatif de la ressource cible
25        $ressource = Get-MgServicePrincipal -ServicePrincipalId $assignation.ResourceId -ErrorAction SilentlyContinue
26        $role = $ressource.AppRoles | Where-Object { $_.Id -eq $assignation.AppRoleId }
27        if ($role) { $permissionsAccordees += $role.Value }
28    }
29 
30    [PSCustomObject]@{
31        NomAffiche           = $sp.DisplayName
32        AppId                = $sp.AppId
33        NombreProprietaires  = ($proprietaires | Measure-Object).Count
34        SponsorManquant      = ($proprietaires | Measure-Object).Count -eq 0
35        PermissionsSensibles = ($permissionsAccordees | Where-Object { $_ -in $permissionsSensibles }) -join ", "
36    }
37}
38 
39# N'exporte que les principaux de service à risque : sans propriétaire OU avec permission sensible
40$resultats |
41    Where-Object { $_.SponsorManquant -or $_.PermissionsSensibles -ne "" } |
42    Export-Csv -Path ".\census-agents-legacy.csv" -NoTypeInformation -Encoding UTF8
43 
44Write-Host "Recensement terminé : $($resultats.Count) principaux de service analysés, export dans census-agents-legacy.csv"

Dépannage : erreurs fréquentes

• Insufficient privileges to complete the operation : le compte connecté n'a pas Application.Read.All ni de rôle suffisant. Reconnectez-vous avec Connect-MgGraph -Scopes en ajoutant le scope manquant, ou faites consentir un administrateur global.
• 429 Too Many Requests sur un tenant volumineux : le SDK gère une partie du retry automatiquement, mais au-delà de quelques milliers de principaux de service, ajoutez un Start-Sleep court dans la boucle si le throttling persiste.
• $ressource.AppRoles vide pour des applications Microsoft first-party : comportement normal, ces applications ne publient pas toujours leurs rôles applicatifs au même endroit. Filtrez sur $sp.Tags ou sur l'AppId pour les exclure du recensement si elles polluent le résultat.
• Get-MgServicePrincipalOwner renvoie une erreur pour un objet partiellement supprimé (soft-deleted) : -ErrorAction SilentlyContinue couvre le cas, mais ces objets zombies sont eux-mêmes un signal à consigner dans le recensement.

Plan de déploiement sur 30 jours pour une équipe réduite

Le livrable au jour 30 n'est pas un programme de gouvernance achevé. C'est une population comptée, un humain responsable par agent, un plafond d'accès et une règle écrite pour le prochain agent. Cela suffit à devancer la quasi-totalité des autres tenants.

Pièges à éviter et prochaines étapes

Quelques erreurs reviennent systématiquement chez les tenants qui découvrent leur population d'agents en 2026 :

• Traiter la gouvernance des agents comme de la gouvernance applicative. La question n'est pas « ce logiciel est-il sûr », mais « que peut faire ce collaborateur, qui en répond, et quand son accès expire-t-il ». Mauvais cadre, mauvais contrôles, mauvais propriétaire.
• Attendre que la plateforme soit stabilisée pour commencer. Le modèle est stable même là où des fonctionnalités sont en préversion : identité, sponsor, accès scopé, expiration. Les tenants qui adoptent la discipline maintenant activeront l'automatisation plus tard ; les autres referont le recensement sur une population dix fois plus grande.
• Laisser « le service IT » sponsoriser tout le monde. Un sponsor qui ne sait pas à quoi sert l'agent ne peut pas prendre de décisions sur son cycle de vie. La sponsorisation appartient au propriétaire métier ; l'IT possède le cadre.
• Ignorer les principaux de service hérités. Les agents les plus risqués de la plupart des tenants sont nés avant que le mot « agent » n'existe. S'il s'authentifie, détient des permissions et agit de façon autonome, il appartient au recensement.
• Accorder un accès permanent parce que les packages semblent bureaucratiques. La boucle expiration-renouvellement est le meilleur contrôle de toute la plateforme ; la contourner pour gagner cinq minutes reconstitue exactement le problème que ce modèle vise à résoudre.
• Oublier l'angle multitenant. Les principaux de blueprint arrivent dans votre tenant comme les applications multitenant. Les MSP et toute organisation consommant des agents tiers doivent revoir les blueprints entrants avec la même méfiance que les consentements d'application.
• N'achetez pas Microsoft Agent 365 pour quatre agents, et ne bloquez pas la création d'agents à l'échelle du tenant en première intention : le métier contournera via des comptes personnels et des outils fantômes, transformant un problème de gouvernance en problème de visibilité.

FAQ éclair

Si votre organisation dépasse déjà la page unique de tableur pour son recensement d'agents, c'est le signal pour évaluer Microsoft Agent 365 comme plan de contrôle plutôt que de continuer à gouverner à la main. Sinon, lancez le recensement des quatre surfaces cette semaine et nommez un sponsor pour chaque agent trouvé avant d'ajouter la moindre nouvelle automatisation.