Entra Agent ID explained: who gets to create AI agents?

AI agents need to sign in somewhere. Until recently they did that as a service principal or, worse, as a regular user account. Microsoft Entra Agent ID gives them an identity of their own. The part that decides how well you control them is small and easy to miss: the blueprint, and who is allowed to create one.

Key Takeaways

• Entra Agent ID adds identity objects built for AI agents. A blueprint is the template, an agent identity is the identity one concrete agent runs as
• One blueprint can sit behind many agents. Conditional Access, disabling and permission changes applied to the blueprint reach all of them
• Per Microsoft Learn, users can create blueprints by default. The setting Users can create agent blueprints controls that
• Whoever creates a blueprint becomes its owner, and owners can create agent identities without an Agent ID role
• Published research so far (Silverfort, Datadog) shows how an over-powerful Agent ID role or a blueprint with an attacker-added credential can be abused. Both are disclosed findings, not attacks in the wild
• My recommendation for most tenants: set the toggle to No on purpose, and give the Agent ID Developer role to named people

What Entra Agent ID is, in plain words

An AI agent acts on its own. It reads mail, calls APIs, creates tickets. To do that it has to authenticate, and the identity it uses decides what you can see and control.

Microsoft’s key concepts page is blunt about the old options. A regular user account is not recommended for agents: Conditional Access built for humans doesn’t apply correctly, ID Protection detections are degraded, and governance can remove the agent’s access by mistake. A traditional service principal is also not recommended, because it has no enforced sponsor, no agent-aware audit entries and no blueprint-managed lifecycle.

Entra Agent ID adds objects made for this job:

Object	What it is	Closest comparison
Agent identity blueprint	The template for one kind of agent. Holds the credentials used to get tokens, plus shared settings	An app registration
Blueprint principal	The blueprint’s presence in your tenant. It requests tokens, creates agent identities and shows up in the audit log	A service principal
Agent identity	The identity one concrete agent runs as	One instance
Agent’s user account	Optional, 1:1 with an agent identity, only for systems that insist on a user object	A user account

Why the blueprint is the control point

All agent identities in a tenant are created from a blueprint. Learn’s own example: one “Sales Assistant Agent” blueprint, deployed for North America, South America, enterprise, SMB and startups. In the Entra admin center they all show up as Sales Assistant Agents. That lets an administrator apply a Conditional Access policy to every one of them, disable all of them, or revoke a permission for all of them.

That works in your favor when someone has designed the blueprint. It works against you when nobody did. A blueprint is also where the credentials live. According to Learn, OAuth permissions granted to a blueprint are granted to all agent identities created from it. So the blueprint is where one decision, or one mistake, multiplies.

I read the blueprint as the real unit of trust in Agent ID. The agent identities are the visible part. The blueprint decides what they can all do, and it decides how many of them can exist.

The setting: Users can create agent blueprints

Microsoft Learn states that by default, users in your organization can create agent identity blueprints. The switch lives in the Entra admin center under Entra ID > Users > User settings: Users can create agent blueprints. Set it to No and creation is limited to admin roles, in practice Agent ID Developer and Agent ID Administrator.

Microsoft’s documentation is not fully consistent here. The page “How are agent identities created?” still lists the Agent ID Developer or Agent ID Administrator role as a requirement for creating a blueprint and does not mention the setting at all. The settings page, the page on creating a blueprint and MC1506733 all describe open creation as the default when Users can create agent blueprints is on. That is a reason to read the actual value in your tenant instead of trusting either page.

Two details make this more than a convenience setting:

• The creator of a blueprint automatically becomes owner of the blueprint and of its principal
• Owners can create agent identities for that blueprint without holding an Agent ID role

So the toggle is not about who may click a wizard. It decides who gets to start a chain of identities that you will later have to govern: someone creates a blueprint, becomes its owner, and can mint agent identities from it. That is a delegation decision. I’d treat it like I treat “Users can register applications”: a default you choose, not one you inherit.

When I would leave it on

• A dedicated development or test tenant where nothing production-grade is reachable
• A deliberate innovation program, where every blueprint has an owner you can name and a review date

When I would switch it off

• Any production tenant where nobody has decided yet who builds agents
• Tenants with sensitive data in Microsoft 365, where an agent with a broad Graph permission is a real exposure
• Tenants that have to answer an auditor’s question: who created this identity, and who approved it?

For most tenants I work with, the answer is the second list. Set the toggle to No, create a group for the people who build agents, and assign them the Agent ID Developer role. According to Microsoft’s role definition, that role can create a blueprint and its principal and is added as owner. It can also configure federated identity credentials on a blueprint, so it is not a harmless role. Adding secrets or certificates needs the Agent ID Administrator role. That role is privileged and manages the whole lifecycle, so keep that group small.

What the research has shown so far

Agent ID is new, and researchers have already looked at it. Both findings below are disclosed research. I have not found a public report of an attack against Agent ID in the wild.

Silverfort: an agent role that reached beyond agents. Silverfort reported that an account with only the Agent ID Administrator role could take over arbitrary service principals that had nothing to do with agents. The route: become owner, add credentials, authenticate as that principal. Silverfort identified it on February 24, 2026 and reported it to Microsoft on March 1. Microsoft confirmed the behavior on March 26, and the fix was fully rolled out on April 9. Attempts to assign ownership of non-agent service principals with that role are now blocked. Silverfort’s write-up mentions no CVE and says nothing about exploitation in the wild.

Datadog Security Labs: one blueprint, more than one tenant. In a scenario published on June 18, 2026, Datadog showed how an attacker with the Agent ID Administrator role in one tenant could add a credential to a blueprint and use it in a second tenant that trusts the same blueprint. A token exchange then led to an agent holding a strong Graph permission (UserAuthMethod-TAP.ReadWrite.All), which was used to set a Temporary Access Pass on a privileged account. Datadog calls that a full compromise of the second tenant. It is a demonstrated scenario, not an incident.

What I take from both: the risk sits at the same two places every time. Who holds the Agent ID roles, and who controls the blueprint’s credentials. The toggle in this article sits one step earlier: it decides how many people can create blueprints at all.

Two Message Center changes from November 4

Two Message Center posts are relevant here. Search for them in your own Message Center and confirm the dates for your tenant.

• MC1506733: per the message, from November 4, 2026, users without an Entra role can create agent blueprints, unless you set Users can create agent blueprints to No. Learn already describes this as the default, so check the actual value in your tenant before the rollout reaches it
• MC1506728: per the message, from November 4, 2026, AgentIdentity.CreateAsManager is no longer granted automatically to blueprint principals. An admin has to grant it, or creating agent identities without a signed-in user fails with a 403

AgentIdentity.CreateAsManager is the Microsoft Graph permission that lets a blueprint create agent identities in the tenant. Microsoft’s agent identity creation page still describes it as granted automatically, which is the behavior before this change.

I read the two changes as one direction. The first lets you decide who may start a blueprint. The second makes the permission to mint agent identities something an admin hands out on purpose. I can’t tell you that Microsoft made them because of the research above, and I won’t claim it.

What to check this week

1. Read the current value. Entra admin center, Entra ID > Users > User settings, Users can create agent blueprints. Write down what it says
2. Decide who builds agents. Name people or a group. If nobody builds agents yet, that is a reason for No, not for leaving it open
3. Assign Agent ID Developer to that group. Keep Agent ID Administrator to as few people as you can
4. List what already exists. In the admin center, go to Entra ID > Agents > Agent blueprints (Microsoft labels the wizard as preview) and check each blueprint’s owner. A blueprint without a clear owner is the first one to question
5. Find apps that create agent identities without a user. Those are the ones affected by MC1506728. The message points to the audit log: category ApplicationManagement, activity “Add Service Principal”. Check the blueprint’s granted permissions and grant AgentIdentity.CreateAsManager where the creation is legitimate
6. Watch the audit log for blueprint creation, new credentials on blueprints and owner changes. After the research above, these are the events I’d want an alert on

Frequently asked questions

Do I have to use Entra Agent ID? No. It is a framework for tenants that build or run agents. But the creation setting exists in your tenant whether you use it or not, which is why I’d set it deliberately.

Does setting it to No stop people from using agents? No. It limits who can create blueprints. According to MC1506733, it does not block an app or agent from creating identities, existing blueprints are not changed or removed, and who can create agent identities from existing blueprints stays the same.

What is the difference between a blueprint and an agent identity? The blueprint is the template and holds the credentials. The agent identity is what one concrete agent runs as. One blueprint can have many agent identities.

Is Agent ID Administrator a safe role to hand out? It is a privileged role. Silverfort’s research showed what happens when that role reaches further than intended. Microsoft fixed that specific issue, but the lesson holds: keep the role small and watch what it does.

Sources

• Microsoft Learn: Agent identity blueprints, Agent ID key concepts, Create an agent identity blueprint, Restrict who can create applications and agents, Microsoft Entra built-in roles
• Message Center: MC1506733 and MC1506728
• Silverfort research on the Agent ID Administrator role (April 2026)
• Datadog Security Labs, research on cross-tenant abuse of Agent ID blueprints (June 18, 2026)