Microsoft Entra Agent ID Setup Guide

Last Updated on July 4, 2026 by Arnav Sharma

AI agents now act inside tenants with the same reach as employees, yet most were stood up as ad-hoc service principals with no consistent governance. This Microsoft Entra Agent ID setup guide walks through the full path: standing up an agent identity blueprint, using that blueprint to create agent identities, wiring up authentication, and hardening everything before agents reach production. Microsoft Entra Agent ID is the identity platform purpose-built to represent AI agents, and it extends the controls you already run for human identities (Conditional Access, Identity Protection, audit logs) to every agent in your Entra ID tenant. If you have been creating agents by hand and want a repeatable model, this is the foundation. Treat this as your working guide to Microsoft Entra agent identities: it shows where agent identities in a Microsoft Entra ID tenant come from, how creating Entra agent identities actually works, and how to keep them governed.

The shift matters because agent security has historically been an afterthought. An agent built in Copilot Studio or wired up through a custom app registration often ended up as a raw service principal with broad permissions and no sponsor. The blueprint model fixes that by giving you one template, consistent credentials, and central policy enforcement across many instances of an AI agent.

What Microsoft Entra Agent ID Is and Why It Changes Agent Security

Microsoft Entra Agent ID introduces a new identity type designed to represent AI agents as first-class principals in Microsoft Entra ID. Instead of scattering agents across unmanaged service principals, you define their agent identity creation logic once and provision from it. Centralising that agent identity creation step is what makes governance at scale realistic, because every instance follows the same rules when agents are created.

The agent identity blueprint, principal, and agent identity model

Three objects work together, and getting the relationship right up front saves a lot of confusion later.

• Agent identity blueprint: an object in Microsoft Entra ID that serves as a template for creating agent identities. The blueprint records shared characteristics so that all agent identities created using the blueprint have a consistent configuration. It also holds the credentials, the granted permissions, and the policies that apply to every agent identity created from it.
• Agent identity blueprint principal: the object that represents the presence of an agent identity blueprint within a specific tenant. When an agent identity blueprint is added to a tenant, Microsoft Entra creates a corresponding principal object. The relationship is conceptually similar to an app registration and its enterprise application. Token issuance and audit logging both reference this principal, so every action the blueprint takes is traceable. Before you use the agent in production, this principal is what gives you that accountability.
• Agent identity: a special service principal that an AI agent uses to authenticate. Each agent identity has an object ID generated by Microsoft Entra, a display name, and a sponsor who is accountable for the agent. Importantly, the agent identity has no credential of its own. Unlike a managed identity in Azure, where the platform manages the credential lifecycle on a resource, an agent identity’s authentication is brokered entirely by its parent blueprint, and an agent user account can be created from an agent identity when a system strictly requires a user object.

The blueprint serves four jobs at once. It is a template, a special identity type that can provision or deprovision agent identities, a credential container, and a management container for policy. A blueprint can perform exactly one operation in the tenant: provision or deprovision agent identities. That deliberate narrowness is a security property, not a limitation.

Why agent identities have no credentials of their own

This is the single concept most teams get wrong. An agent identity does not store a secret or certificate. Credentials used to authenticate an agent identity are configured on the agent identity blueprint instead. When an AI agent wants to perform an operation, the credentials configured on the blueprint are used to request an access token from Microsoft Entra ID, and the subject of that access token is the agent identity.

Agent identities authenticate using federated identity credentials issued by the blueprint. The blueprint holds the credential, acquires the token, and the agent identity is the thing the token represents. Because credentials live on the blueprint and not on each instance, rotating a secret or revoking a certificate is a single operation that covers every agent identity created from the blueprint. This is also why disabling a blueprint immediately stops all of its agent identities from authenticating.

Prerequisites Before You Create Agent Identities

You cannot create agent identities without the right roles, the right tooling, and consented Microsoft Graph scopes. The roles required to create agent identities are specific, so sort these first or the setup stalls partway through. Once they are in place, you will learn how to create agent identity blueprints and the identities under them in the sections that follow.

Entra roles and permissions matrix

Two Entra roles are central, and two more come into play when you grant Microsoft Graph permissions. Both Agent ID Developer and Agent ID Administrator can create agent identity blueprints and agent identity blueprint principals. The distinction shows up around credentials and consent.

Capability	Least privileged role required
Create agent identity blueprints and blueprint principals	Agent ID Developer or Agent ID Administrator
Configure federated identity credentials on a blueprint	Agent ID Developer (federated only)
Add a secret or certificate credential to a blueprint	Agent ID Administrator
Grant Microsoft Graph application permissions	Privileged Role Administrator
Grant Microsoft Graph delegated permissions	Cloud Application Administrator or Application Administrator

A practical note on accountability: every agent identity blueprint must have a sponsor, which is the user or supported group accountable for the agent. An owner is recommended on top of that, since the owner is the user or service principal that can make changes to the blueprint. Blueprint creators are automatically set as owners of both the blueprint and the associated agent identity blueprint principal.

Tooling and Microsoft Graph scopes

If you create agent identities programmatically, the client you use (PowerShell or a dedicated app registration) must be authorised with the right delegated permissions. Connect with explicit scopes rather than relying on a generic sign-in token.

Connect-MgGraph -Scopes "AgentIdentityBlueprint.Create", `
  "AgentIdentityBlueprint.AddRemoveCreds.All", `
  "AgentIdentityBlueprint.ReadWrite.All", `
  "AgentIdentityBlueprintPrincipal.Create", "User.Read"

One trap worth flagging: Azure CLI tokens carry Directory.AccessAsUser.All, which the Agent Identity APIs reject with a 403. Use Connect-MgGraph with explicit delegated scopes in PowerShell, or a dedicated app registration with client credentials in code. Do not use az login tokens for Agent ID provisioning.

How to Create an Agent Identity Blueprint

There is more than one way to create the blueprint, and the method you pick shapes how repeatable your rollout is. The admin center is fastest for a first agent; Microsoft Graph and PowerShell give you a fully configured blueprint in one workflow.

Method 1: Microsoft Entra admin center wizard

The Microsoft Entra admin center wizard is the quickest route. It creates both the agent identity blueprint and its blueprint principal automatically, and it assigns the name, owners, and sponsors as you go.

1. Sign in to the Microsoft Entra admin center.
2. Browse to Entra ID, then Agents, then Agent blueprints.
3. Start the wizard to create the blueprint. Set a display name and assign owners and sponsors.
4. After the blueprint exists, open its detail pages to configure credentials, identifier URIs, scopes, or permissions.

The wizard is deliberately light. To configure credentials, identifier URIs, scopes, or permissions, you use the Microsoft Graph API or PowerShell, or you configure them after creation through the blueprint’s detail pages in the admin center.

Method 2: Microsoft Graph API and PowerShell

To create the blueprint programmatically and fully configure it (credentials, identifier URIs, scopes, and the blueprint principal) in a single repeatable workflow, use Microsoft Graph. Provisioning in Entra using Graph is the approach to standardise on once you are past your first agent, because you can check the definition into source control and create agent identity blueprints the same way every time.

The blueprint needs an OAuth client ID, which is a unique ID used to request access tokens from Microsoft Entra ID, a credential used to request those tokens, and the AgentIdentity.CreateAsManager Microsoft Graph permission that lets the blueprint create agent identities in the tenant.

The @odata.type and OData-Version pitfall

This is the detail most third-party walkthroughs omit, and it silently breaks setups. When you POST to create the blueprint or an agent identity, both the @odata.type property and the OData-Version: 4.0 header are required. Without them, the Graph API creates a standard application instead of an agent identity blueprint, and you will not find out until provisioning fails later. Always set the OData header explicitly when you create an agent identity blueprint using Microsoft Graph.

How to Create Agent Identities From the Blueprint

Once the blueprint and its principal exist, creating agent identities is a small, repeatable step. You are no longer defining configuration, you are instantiating it. Each new AI agent instance becomes its own agent identity that inherits the blueprint’s permissions and policies.

In PowerShell, you create an agent identity by POSTing to the service principals endpoint with the agent identity type and a reference to the blueprint app ID:

$agentBody = @{
  "@odata.type"             = "Microsoft.Graph.AgentIdentity"
  "displayName"             = "Agent-FinanceReconBot"
  "agentIdentityBlueprintId"= "<BLUEPRINT_APP_ID>"
  "[email protected]"     = @("https://graph.microsoft.com/v1.0/users/<SPONSOR_USER_ID>")
}

$agentIdentity = Invoke-MgGraphRequest -Method POST `
  -Uri "https://graph.microsoft.com/beta/serviceprincipals/Microsoft.Graph.AgentIdentity" `
  -Headers @{ "OData-Version"="4.0"; "Content-Type"="application/json" } `
  -Body ($agentBody | ConvertTo-Json -Depth 5) -OutputType PSObject

A few rules to keep in mind when agent identities are created:

• An agent identity is a service principal, and it does not have a backing application object.
• An agent identity cannot have its own credential. It inherits authentication from the blueprint through impersonation.
• Provision a unique identity per agent instance. Sharing identities between agents destroys traceability and prevents you from disabling one agent without affecting others.
• A single blueprint principal can create and manage its own agent identities autonomously, up to a documented maximum per principal, which is why blueprint design should anticipate how many instances of an AI agent you expect.

For low-code scenarios, Microsoft Copilot Studio and other Microsoft 365 product integrations create the blueprint and the associated agent identity for you, so the first agent often appears without a manual Graph call. Even then, the same blueprint model applies underneath.

How Agent Identity Authentication Works (Tokens and Credentials)

Understanding the token flow is what lets you reason about agent security and troubleshoot failures. The flow is short but specific.

1. An AI agent needs to act, so it automatically requests an access token. The credential that backs the request lives on the agent identity blueprint, never on the agent identity.
2. The blueprint uses its configured credential to request an access token from Microsoft Entra ID.
3. Microsoft Entra ID issues the token. The subject of the access token is the agent identity, so downstream systems see the specific agent, not the blueprint. The agent identity’s object ID is what appears in the token and in your audit trail.
4. The agent receives the access token and attaches it to its call to Microsoft Graph or another API.

There are two patterns layered on this flow. Autonomous agents acquire app-only tokens (sometimes called agent tokens) and act on their own. Interactive agents are called with a user token and acquire a user token on behalf of the signed-in user, using delegated permissions, where the subject is the user and the actor is the agent identity. The credential types you can configure on the blueprint include client secrets, certificates, and a federated identity credential that uses workload identity federation to establish trust without storing a secret at all.

When you grant Microsoft Graph delegated permissions or application permissions to the blueprint, those grants flow to every agent identity created from that blueprint. That inheritance is powerful and dangerous in equal measure, which is why least privilege belongs in the setup, not in a later cleanup.

Comparison Table: Four Ways to Create Agent Identities

Choosing the right creation channel up front avoids rework. Use the admin center to learn and to handle one-off agents, and move to Graph or templates once you need repeatability.

Method	Best for	Configures credentials in one pass	Repeatable / source-controllable
Microsoft Entra admin center wizard	First agent, one-off creation, UI-driven setup	No, configure afterwards	No
Microsoft Graph API	Programmatic, fully configured blueprint and principal	Yes	Yes
PowerShell, Azure CLI, or Bicep	Automated, repeatable provisioning at scale	Yes	Yes
Copilot Studio and Microsoft 365 integrations	Low-code and fully managed agent creation	Handled automatically	Partial

The decision usually comes down to scale and auditability. A security team that treats agent configurations as code will standardise on Graph or Bicep, check blueprint definitions into source control, and reserve the admin center for inspection and break-glass changes.

Governance and Hardening for Agent Identities at Scale

Creating the identity is the easy part. The reason to use Microsoft Entra Agent ID at all is that it lets you govern agents with the same machinery you use for people. Build these controls in during setup.

Conditional Access and Identity Protection

Because policy applies at the blueprint, you can target Conditional Access policies at an agent identity blueprint and have them take effect for all agent identities created from that blueprint. That is the right altitude for enforcement: you are not chasing individual agents, you are governing the template. Identity Protection for agents extends risk-based controls to these identities as well, so anomalous agent sign-ins surface alongside human ones in the same signals you already monitor.

Disabling a blueprint is your fastest containment lever. Because it stops every associated agent identity from authenticating, a compromised blueprint can be quarantined in one action.

Least privilege, naming, and lifecycle

A handful of operational habits keep agent identities from becoming the next source of sprawl:

• Least privilege: grant only the permissions each agent needs, scoped to specific API resources or sites. Avoid broad grants for convenience, because every permission on the blueprint propagates to all of its agent identities.
• Standardise naming: prefix display names with the owning department or function, for example Agent-HROnboardingBot, so the registry stays legible as you create multiple agent identities.
• Sponsor and owner discipline: confirm the sponsor is the human accountable for the agent and that an owner is assigned before the agent goes live.
• Production handshake: before a new agent reaches production, have an identity admin verify the blueprint, consented permissions, Conditional Access coverage, and group membership.
• Lifecycle cleanup: when an agent is decommissioned, delete the associated agent identity blueprint. Deleting the blueprint triggers automatic cleanup of its child agent identities and any agent user accounts.

Treat the blueprint as the unit of governance and identity governance becomes tractable. Plan the blueprint before deploying agents, define required settings and permissions in it up front, and you avoid the ad-hoc service principal pattern that created shadow AI in the first place. For the authoritative object schema and current API surface, Microsoft Learn remains the reference to check as the platform evolves.