Entra agent blueprints: what changes on 4 November 2026 and what to do before

· 6 min read

On this page

TL;DR #

  • What: from 4 November 2026, every user without an Entra role can create agent identity blueprints in your tenant. The new setting is on by default.
  • When: rollout starts 4 November and should be complete worldwide by late November 2026 (Message Center MC1506733).
  • What to do: set Users can create agent blueprints to No under Default user role permissions. You can save it today; it takes effect when the rollout reaches your tenant.
  • What it does not do: a blueprint on its own gives no access to company data. Permissions and consent stay separate.
  • The change most posts skip (MC1506728, same day): blueprints no longer get AgentIdentity.CreateAsManager automatically. Agents that create child identities without a signed-in user will start failing with a 403 unless you grant it.

What is changing #

Microsoft adds a new switch to the default user role permissions: Users can create agent blueprints. It ships switched on. Microsoft announced it on 13 October in MC1506733, titled “Action may be required: Review who can create agents in Microsoft Entra”.

Today, creating a blueprint needs the Agent ID Developer or Agent ID Administrator role. After the rollout, any member user without a built-in or custom role can create one, and becomes its owner.

The change only covers new blueprints. It does not touch existing blueprints, and it does not change who can create agent identities from a blueprint that already exists.

What a blueprint is, and what it is not #

A blueprint is the template and authentication foundation for agent identities. Think of it as the application object; the agent identities created from it are the service principals that actually sign in.

Creating a blueprint does not give a user or an agent access to mail, files or any other company data. Resource permissions and consent remain separate steps, and the sensitive ones still need someone with privileged access.

So this is not an instant data-exposure risk. The real cost is sprawl: blueprints nobody approved, owned by people who may leave, with no clear purpose on record. That is the same governance debt many tenants already carry from Users can register applications being left on for years.

Turn it off in the Entra admin center #

  1. Sign in to the Microsoft Entra admin center as at least a Cloud Application Administrator.
  2. Go to Entra ID > Users > User settings.
  3. Under Default user role permissions, find the blueprint setting. It sits just below Users can register applications.
  4. Set it to No and select Save.

The label differs per source. Message Center calls it Users can create agent blueprints; many tenants show Users can register agent identity blueprints. Same setting.

While you are there, check Users can register applications as well. It is a separate switch, and turning off one does not affect the other.

Check and set it with PowerShell #

In Graph the setting is defaultUserRolePermissions.allowedToCreateAgentIdentityBlueprints on the authorization policy. For now it only appears on the beta endpoint; v1.0 does not return it yet.

Check the current value:

Connect-MgGraph -Scopes Policy.Read.All

$policy = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/beta/policies/authorizationPolicy/authorizationPolicy"

$policy.defaultUserRolePermissions.allowedToCreateAgentIdentityBlueprints

Turn it off:

Connect-MgGraph -Scopes Policy.ReadWrite.Authorization

$body = @{
  defaultUserRolePermissions = @{
    allowedToCreateAgentIdentityBlueprints = $false
  }
} | ConvertTo-Json

Invoke-MgGraphRequest -Method PATCH `
  -Uri "https://graph.microsoft.com/beta/policies/authorizationPolicy/authorizationPolicy" `
  -Body $body -ContentType "application/json"

Run the check again afterwards. False means the change is saved. Because this is a beta property, re-test the script before you build automation on it.

The second change: no more automatic CreateAsManager #

A second Message Center post from the same day, MC1506728, tightens something in the opposite direction. It follows the same schedule, but it is a separate change with its own impact. Until now, a new blueprint’s service principal silently received the permission to create and manage child agent identities without a signed-in user. Microsoft removes that automatic grant from 4 November. At the time of writing, Microsoft Learn still describes the grant as automatic and non-revocable; MC1506728 is the source for the change.

After enforcement, an agent that creates child identities app-only needs the Microsoft Graph application permission AgentIdentity.CreateAsManager, granted explicitly by an admin. Without it, those requests fail with 403 Forbidden. This applies to existing deployments too, not just new ones. Agents that rely on a directory role for this keep working.

To find out whether you are affected:

  1. In Entra ID > Audit logs, filter on category ApplicationManagement and activity Add service principal.
  2. Look for events where the actor is an application and the target is an agent identity.
  3. For each blueprint involved, open it under Entra ID > Agents > Agent blueprints and check Granted permissions for other authorization.
  4. Only where it is really needed, grant AgentIdentity.CreateAsManager through admin consent or an app role assignment, and test before enforcement reaches you.

The permission can be granted since 16 October; attempts before that date returned an error.

Should you turn it off? #

For most organisations, yes. Not because a blueprint is dangerous on its own, but because owner-less identities are the hardest thing to clean up later. Turning it off makes blueprint creation a role you hand out, instead of a default everyone has.

With the switch on No, these can still create blueprints:

  • Users with the Agent ID Developer role
  • Users with the Agent ID Administrator role
  • Administrators with the right built-in roles

That gives you a clean path: assign Agent ID Developer to the teams that build agents, ideally through PIM, and record an owner and purpose for every blueprint. AI adoption should run through a designed path, not through a permissive default.

Checklist before 4 November #

  • Decide who may create agent blueprints
  • Set Users can create agent blueprints to No (portal or Graph beta)
  • Review Users can register applications while you are there
  • Assign Agent ID Developer to the teams that need it
  • Check audit logs for agents that create child identities app-only
  • Grant AgentIdentity.CreateAsManager only where needed, and test

Sources #