Entra agent blueprints: restrict who can create them

What changed

A new default user permission is arriving in Microsoft Entra: Users can create agent blueprints.

• From 4 November 2026, default users (anyone with no built-in or custom Entra role) can create agent blueprints and their identities, unless an admin turns the setting off.
• Rollout starts early November worldwide and is expected to complete by late November.
• You can set it now, but it does not take effect until the rollout reaches your tenant.

With the setting at No:

• Default users can’t create new agents.
• Users with the Agent ID Developer role can.
• Supported administrators can.

What does not change:

• Existing agent blueprints stay as they are.
• Who can create agent identities from existing blueprints is unchanged.
• Apps and agents are not blocked from creating identities.
• Platform requirements in Microsoft Foundry and Security Copilot (licences, Azure subscriptions) still apply on top.

Who is impacted

You should care if any of these are true:

• You restrict Users can register applications today and assumed that covers agents. It doesn’t.
• You have no agent governance yet, or it lives in a slide deck.
• You run Microsoft Foundry or Security Copilot and expect business users to experiment.
• You have regulatory or audit requirements around non-human identities.

If you are happy for every user to create agent identities in your directory, you can leave the default. Make that a recorded decision, not an accident.

Why it matters

• Identity sprawl: every blueprint and agent identity is another non-human identity to own, review and eventually clean up.
• Default-open: the new permission ships enabled. Doing nothing means saying yes.
• Separate control: it is independent from Users can register applications, so your existing app registration lockdown does not carry over.
• Timing: the change lands in a rollout window, not on a single date. Setting it early is the only way to be sure you are covered on day one.

Decide now

Situation	Suggested setting
App registration already restricted to admins/developers	No, to match
Regulated or security-sensitive tenant	No
Small tenant, agent building is genuinely everyone’s job	Yes, with periodic review
Unsure, no agent governance in place	No, then open up deliberately

Who should keep the ability:

• Engineers and makers who build agents as part of their role.
• Platform or AI teams running a sanctioned agent programme.
• Give these people the Agent ID Developer role, ideally through a group and PIM, rather than leaving the door open for everyone.

---

Runbook: restrict agent creation and keep a controlled path

1. Record the current state

   In the Microsoft Entra admin center, go to Entra ID > Users > User settings and note the values for:

   • Users can register applications
   • Users can create agent blueprints (if already visible)

   Capture a screenshot for the change record.

2. Set up the controlled path first

   Before restricting, make sure builders aren’t blocked:

   • Create a group for agent developers (or reuse an existing developer group).
   • Assign the Agent ID Developer role to it. Use PIM eligibility if you have Entra ID P2.
   • Tell the team how to request access.

   Verify in Microsoft’s docs whether the role can be assigned to a role-assignable group in your tenant.

3. Turn off default user creation

   1. Sign in to the Microsoft Entra admin center as at least a supported administrator.
   2. Go to Entra ID > Users > User settings.
   3. Under Default user role permissions, set Users can create agent blueprints to No.
   4. Select Save.

   Remember this won’t take effect until the rollout reaches your tenant.

4. Review the app registration setting separately

   While you are on the page, decide on Users can register applications on its own merits. The two settings are independent; don’t assume one implies the other.

5. Communicate

   Tell makers and app teams:

   • What changed and when.
   • That existing blueprints are unaffected.
   • How to get the Agent ID Developer role.

---

Checks

Before 4 November:

• ✓

  Users can create agent blueprints is set to No (or Yes, with a recorded decision).

• ✓

  Agent ID Developer role is assigned to a group, not ad hoc to individuals.

• ✓

  Users can register applications has been reviewed as a separate decision.

After the rollout completes (late November):

• ✓

  Setting still shows the value you saved.

• ✓

  A test default user cannot create a new agent blueprint.

• ✓

  A user with Agent ID Developer can create one.

• ✓

  Existing blueprints have been inventoried, each with an owner.

• ✓

  Entra audit logs reviewed for agent blueprint and identity creation since rollout began.

For the audit log review, filter the Entra audit logs for agent-related creation activity and check who created what. Exact activity names and categories for Agent ID are worth confirming in Microsoft’s docs, as they may differ from classic application events.

Rollback

Set Users can create agent blueprints back to Yes and save. Nothing is deleted by turning the setting off or on: existing blueprints and agent identities are untouched either way.

Common pitfalls

• Assuming the date is the date. Rollout runs early to late November. Set it now; don’t wait for 4 November.
• Assuming app registration covers it. Users can register applications = No does not restrict agent blueprints.
• Restricting without a path. Turn it off before giving builders Agent ID Developer and you’ll get shadow requests and frustrated teams.
• Forgetting existing blueprints. The setting only affects new creation. Anything created before you changed it still needs an owner and a review.
• Expecting it to block everything. Apps and agents can still create identities, and creating identities from existing blueprints is unchanged.
• Treating Foundry or Security Copilot access as the control. Licences and subscriptions are a separate gate, not a substitute for this setting.