Entra Agent ID : tous les utilisateurs pourront créer des agent blueprints, faut-il les laisser faire ?

Le 13 octobre, Microsoft a publié un message du centre de messages qui est passé un peu inaperçu : MC1506733, « Review who can create agents in Microsoft Entra ». À partir du 4 novembre 2026, n’importe quel utilisateur de votre locataire pourra créer des agent blueprints dans Entra ID, sans rôle d’administration. Le réglage existe, mais il est activé par défaut.

Dans cet article, j’explique ce qu’est un agent blueprint, ce que ce changement ouvre réellement, et comment reprendre la main avant qu’il n’arrive dans votre locataire.

Un agent blueprint, c’est quoi ?

Avec Microsoft Entra Agent ID, Microsoft a créé un type d’identité dédié aux agents IA, distinct des utilisateurs et des inscriptions d’applications. Chaque agent (Copilot Studio, Microsoft Foundry, Agent 365, ou un agent maison développé avec le Microsoft 365 Agents SDK) reçoit sa propre identité d’agent, visible dans les journaux de connexion et d’audit.

Ces identités ne sont jamais créées seules : elles naissent toutes d’un agent identity blueprint. Le blueprint est à la fois :

• un modèle : il porte la description, les rôles d’application, l’éditeur vérifié et les paramètres d’authentification partagés par tous les agents créés à partir de lui ;
• un porteur d’identifiants : c’est sur le blueprint qu’on configure le secret, le certificat ou, de préférence, l’identité managée qui permet aux agents d’obtenir des jetons ;
• une identité à part entière, avec un rôle unique : créer ou supprimer des identités d’agents, grâce à la permission Microsoft Graph spéciale AgentIdentity.CreateAsManager.

Le blueprint déclare aussi les permissions héritables : quand un administrateur consent à une permission sur le blueprint, toutes ses identités d’agents en héritent. Et si on désactive un blueprint, aucun de ses agents ne peut plus s’authentifier.

Pour résumer, un blueprint est à un agent IA ce qu’une inscription d’application est à une application, avec en plus la capacité de fabriquer des identités à la chaîne.

Copilot Studio utilise un blueprint global unique, « Microsoft Copilot Studio agent identity blueprint », dont chaque agent reçoit une identité enfant. Le changement dont on parle ici concerne surtout les blueprints créés par les utilisateurs : agents développés avec le SDK, la CLI Agent 365 ou directement avec Microsoft Graph.

Ce qui change le 4 novembre

Microsoft ajoute dans les autorisations de rôle utilisateur par défaut un nouveau paramètre : « Users can create agent blueprints ».

	Paramètre à Oui (valeur par défaut)	Paramètre à Non
Qui peut créer un blueprint ?	Tous les utilisateurs, sans rôle	Rôles Agent ID Developer et Agent ID Administrator (et administrateurs habilités)
Blueprints existants	Inchangés	Inchangés
Création d’identités depuis un blueprint existant	Propriétaires du blueprint	Propriétaires du blueprint

Le calendrier :

• 13 octobre 2026 : publication de MC1506733 ;
• dès maintenant : le paramètre est visible et une valeur à Non sera prise en compte ;
• 4 novembre 2026 : début du déploiement mondial ;
• fin novembre 2026 : déploiement terminé.

Point important : ce paramètre est indépendant de « Les utilisateurs peuvent inscrire des applications ». Si vous avez bloqué les inscriptions d’applications depuis des années, comme beaucoup de locataires, ça ne vous protège pas : il faut régler les deux.

Pourquoi je le désactive

Microsoft rappelle, à juste titre, qu’un blueprint ne donne accès à aucune donnée à lui seul : les permissions doivent toujours faire l’objet d’un consentement. Mais plusieurs détails rendent la valeur par défaut discutable.

• Le créateur devient propriétaire. Il peut gérer les identifiants du blueprint, en ajouter d’autres, modifier sa configuration et créer autant d’identités d’agents qu’il veut, sans aucun rôle Agent ID.
• Ces droits restent acquis. Désactiver le paramètre plus tard ne retire rien aux utilisateurs qui ont déjà créé des blueprints.
• Le consentement utilisateur fait le reste. Si vos utilisateurs peuvent encore consentir eux-mêmes à des applications, un agent créé par un utilisateur peut obtenir des permissions déléguées sur ses mails, ses fichiers ou son calendrier, sans qu’un administrateur intervienne.
• Un compte compromis en profite aussi. Comme pour les inscriptions d’applications, créer un objet capable de porter des secrets et d’obtenir des jetons est une technique de persistance classique pour un attaquant.
• Le ménage ne se fera pas tout seul. On a vu ce que donnent les équipes Teams créées sans gouvernance ; des identités d’agents orphelines seraient beaucoup plus gênantes.

Très peu d’utilisateurs ont un besoin légitime de créer un blueprint : ce sont des développeurs, et ils peuvent recevoir un rôle dédié.

Désactiver le paramètre

Dans le centre d’administration Entra

1. Connectez-vous au centre d’administration Microsoft Entra avec un compte Administrateur général ou Administrateur de rôle privilégié.
2. Allez dans Entra ID > Utilisateurs > Paramètres utilisateur.
3. Dans Autorisations de rôle utilisateur par défaut, passez « Users can create agent blueprints » à Non.
4. Enregistrez.

Si l’option n’apparaît pas encore, rechargez la page sans cache (Ctrl + F5). La modification met environ une minute à s’afficher.

En PowerShell (Microsoft Graph beta)

Le paramètre est stocké dans la stratégie d’autorisation du locataire, sous le nom allowedToCreateAgentIdentityBlueprints. Il n’est pour l’instant exposé que dans l’API beta et n’est pas encore documenté : le nom peut évoluer d’ici la fin du déploiement.

Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

# Valeur actuelle
$permissions = (Get-MgBetaPolicyAuthorizationPolicy).DefaultUserRolePermissions
$permissions.AdditionalProperties['allowedToCreateAgentIdentityBlueprints']

# Désactivation
$body = @{
    defaultUserRolePermissions = @{
        allowedToCreateAgentIdentityBlueprints = $false
    }
}
Invoke-MgGraphRequest -Method PATCH `
    -Uri "https://graph.microsoft.com/beta/policies/authorizationPolicy/authorizationPolicy" `
    -Body $body

Profitez-en pour vérifier au même endroit allowedToCreateApps (inscriptions d’applications), qui devrait lui aussi être à False.

Donner le droit aux bonnes personnes

Pour les équipes qui développent réellement des agents, attribuez le rôle Agent ID Developer :

1. Avec un compte Administrateur de rôle privilégié, ouvrez Entra ID > Rôles et administrateurs.
2. Recherchez Agent ID Developer et sélectionnez Ajouter des affectations.
3. Ajoutez les développeurs concernés, de préférence en affectation éligible avec Privileged Identity Management, pour qu’ils n’activent le rôle que lorsqu’ils en ont besoin.

Ce rôle permet de créer, lire, modifier et supprimer des blueprints et d’y ajouter des identifiants fédérés. L’ajout d’un secret ou d’un certificat reste réservé à Agent ID Administrator, ce qui pousse à utiliser des identités managées, plus sûres.

Inventorier les blueprints existants

Avant de fermer la porte, regardez qui l’a déjà franchie. Cette requête liste tous les blueprints du locataire avec leurs propriétaires :

Connect-MgGraph -Scopes "Application.Read.All"

$uri = "https://graph.microsoft.com/v1.0/applications/microsoft.graph.agentIdentityBlueprint" +
       "?`$select=id,appId,displayName,createdDateTime&`$expand=owners"
$report = while ($uri) {
    $page = Invoke-MgGraphRequest -Method GET -Uri $uri -Headers @{ "OData-Version" = "4.0" }
    foreach ($bp in $page.value) {
        [pscustomobject]@{
            DisplayName = $bp.displayName
            AppId       = $bp.appId
            Created     = $bp.createdDateTime
            Owners      = ($bp.owners | ForEach-Object { $_.userPrincipalName ?? $_.displayName }) -join '; '
        }
    }
    $uri = $page.'@odata.nextLink'
}
$report | Sort-Object Created | Export-Csv .\AgentBlueprints.csv -NoTypeInformation -Encoding UTF8

Concentrez-vous sur les blueprints possédés par des utilisateurs standards. Dans le centre d’administration, Entra ID > Agents > Agent blueprints donne la même liste, et l’onglet Access > Granted permissions de chaque blueprint montre les permissions accordées.

Pour la suite, surveillez les journaux d’audit Entra (catégorie ApplicationManagement, activité Add service principal) : un acteur de type application qui crée une identité d’agent signale un agent qui fabrique ses propres identités.

Verrouiller le consentement

C’est le vrai garde-fou. Un blueprint sans permissions ne sert à rien ; un blueprint avec le consentement libre des utilisateurs, si.

• Dans Entra ID > Applications d’entreprise > Consentement et autorisations, limitez le consentement utilisateur (aucun consentement, ou seulement les éditeurs vérifiés pour des permissions à faible risque).
• Activez le workflow de consentement administrateur, pour que les utilisateurs demandent une validation au lieu de se heurter à un refus.

L’autre changement : la fin de l’octroi automatique d’AgentIdentity.CreateAsManager

Microsoft profite de ces annonces pour corriger un autre comportement. Jusqu’ici, le principal de service d’un blueprint recevait automatiquement, sans approbation, la permission Graph AgentIdentity.CreateAsManager, qui lui permet de créer des identités d’agents sans utilisateur connecté.

Cet octroi automatique disparaît :

• les administrateurs peuvent accorder cette permission explicitement depuis le 16 octobre 2026 (Applications d’entreprise > l’application > Sécurité > Autorisations, puis consentement administrateur à l’échelle du locataire, avec au minimum le rôle Administrateur d’applications cloud) ;
• les blueprints et identités existants ne sont pas supprimés, et les agents qui tirent ce droit d’un rôle d’annuaire ne sont pas concernés ;
• en revanche, une application qui comptait uniquement sur l’octroi automatique recevra une erreur 403 Forbidden lorsqu’elle tentera de créer une identité, une fois la modification appliquée à votre locataire.

Si vos développeurs ont des agents qui créent leurs propres identités, prévenez-les et accordez la permission avant qu’ils ne découvrent l’erreur en production.

Côté licences

La création de blueprints et d’identités d’agents ne demande aucune licence supplémentaire. Pour appliquer aux agents l’accès conditionnel, ID Protection ou la gouvernance des identités, il faut Microsoft Agent 365 en plus d’Entra ID P1 au minimum. Autrement dit, la création est gratuite et ouverte à tous par défaut, mais la gouvernance est payante : une raison de plus pour restreindre la création.

Ma check-list

• « Users can create agent blueprints » à Non avant le 4 novembre 2026
• « Les utilisateurs peuvent inscrire des applications » à Non
• Rôle Agent ID Developer attribué aux développeurs d’agents, éligible via PIM
• Inventaire des blueprints existants et revue de leurs propriétaires
• Consentement utilisateur restreint et workflow de consentement administrateur activé
• Permission AgentIdentity.CreateAsManager accordée explicitement aux blueprints qui en ont besoin
• Alerte sur les créations d’identités d’agents dans les journaux d’audit
• Test après le déploiement : un compte avec le rôle Agent ID Developer peut créer un blueprint, un compte standard ne le peut pas

Ce que je vous conseille de faire cette semaine

1. Passez le paramètre à Non : c’est un interrupteur, cinq minutes, et il sera pris en compte dès que le déploiement arrivera chez vous.
2. Lancez l’inventaire des blueprints pour savoir si des utilisateurs en ont déjà créé, avec Copilot Studio, Foundry ou le SDK.
3. Contrôlez le consentement utilisateur : c’est lui qui transforme un blueprint inoffensif en accès à vos données.