Entra Agent ID: every user will be able to create agent blueprints. Should you let them?

On October 13, Microsoft published a message center post that went somewhat unnoticed: MC1506733, “Review who can create agents in Microsoft Entra”. Starting November 4, 2026, any user in your tenant will be able to create agent blueprints in Entra ID, without an admin role. The setting exists, but it is on by default.

In this article, I explain what an agent blueprint is, what this change actually opens up, and how to take back control before it reaches your tenant.

What is an agent blueprint?

With Microsoft Entra Agent ID, Microsoft created an identity type dedicated to AI agents, separate from users and app registrations. Each agent (Copilot Studio, Microsoft Foundry, Agent 365, or a custom agent built with the Microsoft 365 Agents SDK) gets its own agent identity, visible in sign-in and audit logs.

These identities are never created on their own: they all come from an agent identity blueprint. The blueprint is at once:

• a template: it holds the description, app roles, verified publisher and authentication settings shared by every agent created from it;
• a credential holder: the secret, certificate or, preferably, managed identity that lets agents obtain tokens is configured on the blueprint;
• an identity in its own right, with a single job: creating or deleting agent identities, thanks to the special Microsoft Graph permission AgentIdentity.CreateAsManager.

The blueprint also declares inheritable permissions: when an admin consents to a permission on the blueprint, all of its agent identities inherit it. And if you disable a blueprint, none of its agents can authenticate anymore.

In short, a blueprint is to an AI agent what an app registration is to an application, with the added ability to mass-produce identities.

Copilot Studio uses a single global blueprint, “Microsoft Copilot Studio agent identity blueprint”, and each agent gets a child identity from it. The change discussed here mostly concerns blueprints created by users: agents built with the SDK, the Agent 365 CLI or directly with Microsoft Graph.

What changes on November 4

Microsoft is adding a new setting to the default user role permissions: “Users can create agent blueprints”.

	Setting set to Yes (default)	Setting set to No
Who can create a blueprint?	All users, no role needed	Agent ID Developer and Agent ID Administrator roles (and authorized admins)
Existing blueprints	Unchanged	Unchanged
Creating identities from an existing blueprint	Blueprint owners	Blueprint owners

The timeline:

• October 13, 2026: MC1506733 published;
• right now: the setting is visible and a value of No will be honored;
• November 4, 2026: worldwide rollout starts;
• late November 2026: rollout complete.

Important: this setting is independent of “Users can register applications”. If you blocked app registrations years ago, like many tenants, that does not protect you: you need to set both.

Why I turn it off

Microsoft rightly points out that a blueprint grants no data access on its own: permissions always require consent. But several details make the default questionable.

• The creator becomes the owner. They can manage the blueprint’s credentials, add more, change its configuration and create as many agent identities as they want, without any Agent ID role.
• Those rights stick. Turning the setting off later takes nothing away from users who have already created blueprints.
• User consent does the rest. If your users can still consent to apps themselves, an agent created by a user can get delegated permissions on their mail, files or calendar without any admin involvement.
• A compromised account benefits too. As with app registrations, creating an object that can hold secrets and obtain tokens is a classic persistence technique for an attacker.
• Nobody will clean up for you. We’ve seen what Teams created without governance looks like; orphaned agent identities would be far more of a problem.

Very few users have a legitimate need to create a blueprint: they are developers, and they can be given a dedicated role.

Turn the setting off

In the Entra admin center

1. Sign in to the Microsoft Entra admin center as a Global Administrator or Privileged Role Administrator.
2. Go to Entra ID > Users > User settings.
3. Under Default user role permissions, set “Users can create agent blueprints” to No.
4. Save.

If the option doesn’t show up yet, reload the page without cache (Ctrl + F5). The change takes about a minute to appear.

With PowerShell (Microsoft Graph beta)

The setting is stored in the tenant’s authorization policy as allowedToCreateAgentIdentityBlueprints. For now it is only exposed in the beta API and isn’t documented yet: the name may change before the rollout completes.

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

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

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

While you’re there, check allowedToCreateApps (app registrations), which should also be False.

Give the right to the right people

For teams that actually build agents, assign the Agent ID Developer role:

1. As a Privileged Role Administrator, open Entra ID > Roles & admins.
2. Search for Agent ID Developer and select Add assignments.
3. Add the relevant developers, preferably as an eligible assignment with Privileged Identity Management, so they only activate the role when they need it.

This role can create, read, update and delete blueprints and add federated credentials to them. Adding a secret or certificate remains reserved for Agent ID Administrator, which nudges people toward managed identities, which are safer.

Inventory existing blueprints

Before closing the door, check who has already walked through it. This query lists every blueprint in the tenant with its owners:

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

Focus on blueprints owned by standard users. In the admin center, Entra ID > Agents > Agent blueprints gives the same list, and each blueprint’s Access > Granted permissions tab shows the permissions granted.

Going forward, watch the Entra audit logs (category ApplicationManagement, activity Add service principal): an application-type actor creating an agent identity means an agent is producing its own identities.

Lock down consent

This is the real safeguard. A blueprint without permissions is useless; a blueprint with free user consent is not.

• In Entra ID > Enterprise apps > Consent and permissions, restrict user consent (no consent, or only verified publishers for low-risk permissions).
• Turn on the admin consent workflow, so users request approval instead of hitting a wall.

The other change: no more automatic grant of AgentIdentity.CreateAsManager

Microsoft is using these announcements to fix another behavior. Until now, a blueprint’s service principal automatically received, without approval, the Graph permission AgentIdentity.CreateAsManager, which lets it create agent identities without a signed-in user.

That automatic grant is going away:

• admins can grant this permission explicitly since October 16, 2026 (Enterprise apps > the app > Security > Permissions, then tenant-wide admin consent, with at least the Cloud Application Administrator role);
• existing blueprints and identities are not deleted, and agents that get this right from a directory role are not affected;
• however, an app that relied only on the automatic grant will get a 403 Forbidden error when it tries to create an identity, once the change reaches your tenant.

If your developers have agents that create their own identities, warn them and grant the permission before they discover the error in production.

Licensing

Creating blueprints and agent identities requires no additional license. To apply Conditional Access, ID Protection or identity governance to agents, you need Microsoft Agent 365 on top of at least Entra ID P1. In other words, creation is free and open to everyone by default, but governance costs money: one more reason to restrict creation.

My checklist

• “Users can create agent blueprints” set to No before November 4, 2026
• “Users can register applications” set to No
• Agent ID Developer role assigned to agent developers, eligible through PIM
• Inventory of existing blueprints and review of their owners
• User consent restricted and admin consent workflow enabled
• AgentIdentity.CreateAsManager permission granted explicitly to the blueprints that need it
• Alert on agent identity creation in the audit logs
• Test after rollout: an account with the Agent ID Developer role can create a blueprint, a standard account cannot

What I recommend doing this week

1. Set the setting to No: it’s a switch, five minutes, and it will apply as soon as the rollout reaches you.
2. Run the blueprint inventory to find out whether users have already created any, with Copilot Studio, Foundry or the SDK.
3. Check user consent: that’s what turns a harmless blueprint into access to your data.