MC1506733: Entra lets every user create agent blueprints on Nov 4. Turn it off before your app-registration lock gives you false comfort

You locked down Users can register applications years ago, so MC1506733 agent blueprints look like someone else's problem. They aren't. From November 4, a user with no Entra role can create an agent blueprint even in a tenant where that same user can't register an app, because Microsoft built the new setting as a separate switch.

This is the decision we set in a tenant before the default flips: the toggle, the three things it doesn't cover, who should still be allowed to build, and how to confirm next month that nobody quietly turned it back on.

The app-registration lock doesn't reach agent blueprints

MC1506733 says it plainly: default users, meaning anyone without a built-in or custom Entra role, "will be able to create new agent blueprints unless an administrator turns off Users can create agent blueprints." Rollout starts early November and should finish by late November. Microsoft also says the new setting "is independent of Users can register applications. Review both settings separately."

A blueprint is the template that agent identities are created from and authenticate through. It carries the same risks you closed app registrations to avoid: credentials nobody owns, objects nobody can explain, and permissions that outlive the person who asked for them. Microsoft just put it behind a different switch.

What breaks it:

• Set the toggle to No now — Entra admin center > Entra ID > Users > User settings > Default user role permissions. You need at least Cloud Application Administrator. A change made today takes effect when rollout reaches your tenant.
• Look for both names — Message Center and Learn say Users can create agent blueprints. The portal may show Users can register agent identity blueprints. They're the same setting. Don't tell a change board it's missing because the label didn't match.
• Screenshot both rows together — app registrations and agent blueprints, side by side, so the record shows two decisions instead of one.

What No doesn't cover

Setting the toggle to No stops new blueprint creation by default users. It's not a kill switch for agents. Per MC1506733, it doesn't change or remove existing agent blueprints, it doesn't change who can create agent identities from existing blueprints, and it doesn't block an app or an agent from creating identities.

Learn fills in the rest. Owners of a blueprint or its principal can create agent identities for that blueprint without any Agent ID role, and whoever creates a blueprint becomes its owner automatically. Graph clients can also be granted AgentIdentityBlueprint.Create, including as an application permission, so the right service principal can create blueprints with no signed-in user at all.

What breaks it:

• Inventory what already exists under Entra ID > Agents > Agent blueprints before November 4, and note the owner and sponsor on each one.
• Review blueprint owners like app owners — ownership is the permission. A departed or reassigned owner is a standing path to new agent identities.
• Find the apps holding blueprint-create permissions — check enterprise apps for AgentIdentityBlueprint.Create and AgentIdentityBlueprintPrincipal.Create, delegated and application. The toggle does nothing about them.

Who can still register agent identity blueprints

With the toggle on No, admins and users with the Agent ID Developer role can still create blueprints, and so can Agent ID Administrator. Learn separates the two. Agent ID Developer can create blueprints and configure federated identity credentials. Agent ID Administrator is required to add a secret or certificate credential to a blueprint.

Credentials on a blueprint flow to every agent identity built from it, so treat Agent ID Administrator the way you treat Application Administrator: a few named people, eligible rather than active. When the toggle goes to No, someone in the business will want to build an agent the next week. The answer should be a role request with an owner, not a ticket to turn the default back on.

What breaks it:

• Agent ID Developer as a PIM-eligible assignment — named builders activate it with a reason, and it isn't standing access.
• Agent ID Administrator handled like Application Administrator — eligible, with an approver.
• Check PIM eligibility as well as active assignments — a role-assignment query only returns active assignments, so check roleEligibilitySchedules too.

What "good" looks like: the five-move baseline

If you do nothing else before November 4, these five moves turn MC1506733 from a default into a decision:

1. Users can create agent blueprints = No — set it in User settings today, and record who decided and why.
2. Users can register applications reviewed in the same change — two settings, two documented answers.
3. Existing blueprints and owners inventoried — every blueprint has an owner and sponsor you can name.
4. Agent ID Developer and Agent ID Administrator through PIM — eligible assignments for named people, and no standing grants.
5. A monthly read of the setting — GET https://graph.microsoft.com/beta/policies/authorizationPolicy with Policy.Read.All, then check defaultUserRolePermissions.allowedToCreateAgentIdentityBlueprints. It's beta only for now and may be renamed, so run it as a check and don't hard-code a pipeline around it.

None of this needs a new license. It's a user setting, two directory roles, and a Graph read you can paste into a monthly report. A tenant default that flips on November 4 is exactly the kind of drift nobody owns until it bites, which is why our M365 Governance Retainer reviews Microsoft's default changes like MC1506733 every month and sets them on purpose instead of by accident.

The uncomfortable question

Turning the toggle off answers one row of a bigger question: who in this tenant can create an agent identity today, and how would you know if that list grew? Owners, apps with AgentIdentityBlueprint.Create, and active Agent ID role assignments answer the rest.

Pull the blueprint list, the Agent ID role assignments and eligibilities, and the beta authorization policy into one page. If those three don't match what you approved, you already have drift, whether or not the rollout has reached your tenant.

Also on November 4: MC1506728 stops Entra from automatically granting AgentIdentity.CreateAsManager to agent blueprint principals. An agent that creates its own agent identities with app-only authentication and relies on that implicit grant will get a 403 once enforcement reaches your tenant. Find them in Audit Logs (category ApplicationManagement, activity Add Service Principal, initiated by an application), then grant the Microsoft Graph application permission explicitly through admin consent and test before late November.