AI agents built on Copilot Studio, Foundry and third-party frameworks are being created faster than identity teams can register them, and most still authenticate as ordinary app registrations or borrowed user accounts. Microsoft Entra Agent ID adds first-class identity objects for agents: blueprints that define a kind of agent, agent identities that are special service principals without credentials of their own, optional agent user accounts, and mandatory human sponsors. Conditional Access, ID Protection, entitlement management and the sign-in and audit logs then understand that the caller is an agent. This guide walks through the object model, the admin roles, the token flows, logging and a hardening baseline, using Microsoft Learn as the source for every product behaviour. It is for Entra administrators, identity governance owners and the platform teams publishing agents into a Microsoft tenant. Feature status and licensing change quickly in this area, so check the linked pages before relying on a detail.
Key takeaways
- Agent identities hold no credentials. The blueprint holds the credential and obtains tokens on the agent identity's behalf through federated identity credentials, so credential hygiene is a blueprint problem.
- Sponsors are required at creation. Every agent identity and blueprint must have a human or supported group sponsor, and sponsorship moves to the manager when a sponsor leaves.
- Each token subject needs its own policy. Conditional Access treats agent identities, agent users and delegated users as separate targets; a policy on one does not cover the others.
- High privilege is blocked by design. Microsoft blocks roles such as Global Administrator and permissions such as Application.ReadWrite.All for agent identities.
- Logs are tagged, not separated. Agent activity appears under existing audit categories with an agentType field and a blueprintId, and Graph activity logs need a join to tell agents apart.
How identity and access work in Microsoft Entra Agent ID
Microsoft defines agent identities as identity accounts in Entra ID that give AI agents unique identification and authentication, distinct from human users and from conventional application identities. The model has four objects.
| Object | What it is | Credentials | agentType in logs |
|---|---|---|---|
| Agent identity blueprint | Reusable template for a kind of agent: name, publisher, offered roles and the Graph permissions its agents receive. Analogous to an app registration. | Federated identity credentials, certificates or client secrets | agenticApp |
| Agent identity blueprint principal | The service principal representing the blueprint in a tenant | Inherited from the blueprint | agentIdentityBlueprintPrincipal |
| Agent identity | A special service principal created from the blueprint; the identity the agent acts as. Object ID and app ID are the same value. | None of its own; authenticates through federated identity credentials issued by the blueprint | agenticAppInstance |
| Agent's user account (optional) | A user object decorated as an AI agent, paired one-to-one with an agent identity, for systems that need a user (for example a mailbox) | Obtained through the agent identity | agentIDuser |
Agents operate in three modes, each with its own flow in Microsoft's protocol documentation:
- Autonomous: the agent acts as its own service principal using app-only tokens and permissions assigned to the agent identity (Graph permissions, Azure RBAC roles, Entra directory roles or app roles).
- Interactive (delegated): the agent acts for a signed-in user through an on-behalf-of exchange. The token subject is the user and the actor is the agent identity; the agent can only use rights the user has and has delegated.
- Agent user account: the agent acts as the user principal created for it, for workloads such as a mailbox or Teams presence.
Every flow is multi-stage: the blueprint authenticates, then impersonates the agent identity. Microsoft states that all agent entities are confidential clients, that interactive /authorize flows are not supported for any agent entity, and that managed identities are the preferred blueprint credential, with client secrets not to be used in production. Agent identities are single-tenant; blueprints can be multitenant, and a multitenant blueprint added to another tenant creates tenant-local agent identities there.
Third-party agents, for example ones running on AWS or n8n, can be integrated through the Microsoft Entra ID Auth SDK sidecar or workload identity federation, according to Microsoft's overview. For the general governance principles behind this model, see the Identity Governance for AI Agents Guide; for how Entra compares with AWS and Google, see Cloud Agent Identity Services Compared.
Licensing in one paragraph
Microsoft states that Entra Agent ID itself is available to all Entra customers. Microsoft Agent 365, which lets agents work across Microsoft 365 services, is licensed per user. Extending Entra security features (Conditional Access for agents, entitlement management for agents, ID Protection for agents) requires Agent 365: included in Microsoft 365 E7, or Agent 365 plus at least Entra P1 or Microsoft 365 E3 according to the Conditional Access and governance pages. The ID Protection page says the Agent 365 requirement for risky agents is "starting soon". Confirm the current terms on Microsoft's pricing page before budgeting.
Admin roles and privileged access
Three kinds of people can change an agent, and Microsoft deliberately gives them different powers.
| Relationship | Who can hold it | Can do | Cannot do |
|---|---|---|---|
| Owner (technical) | Users including guests, and service principals; not groups | Edit settings and authentication properties, manage credentials, add owners and sponsors, disable, re-enable, delete, restore, hard-delete; create agent identities from a blueprint they own | Optional; no stated maximum |
| Sponsor (business) | Users including guests; dynamic security or Microsoft 365 groups and assigned Microsoft 365 groups (not role-assignable or assigned security groups) | Disable, soft-delete, change sponsors, request access packages, extend or let assignments expire | Change application settings, re-enable or restore |
| Manager | Individual users, set on the agent's user account | Request access packages for the agent user, see the agent in the admin centre | Modify or delete the agent |
- Sponsor rules: a sponsor is required when creating agent identities and blueprints (blueprint principals are exempt). If a delegated caller names no sponsor, the caller becomes the sponsor; an app-only creator must set one. Limits are 100 sponsors per agent identity or blueprint with no more than five groups, and five sponsors for an agent user account.
- Directory roles: the Agent ID Administrator role manages agent objects. Owners of a blueprint can create agent identities from it with delegated permissions such as
AgentIdentity.Create.Allwithout holding an admin role, so blueprint ownership is itself a privileged grant. - Built-in privilege limits: Microsoft's FAQ states that highly privileged directory roles including Global Administrator, Privileged Role Administrator and User Administrator are blocked for agent identities; agent identities cannot join role-assignable groups; and
Application.ReadWrite.All,RoleManagement.ReadWrite.All,User.ReadWrite.AllandDirectory.AccessAsUser.Allcannot be granted. - No administrative units: agent identities, blueprints and blueprint principals cannot be added to AUs, so the
ownersproperty is the only way to delegate management of a subset of agents. - Consent: the admin consent workflow does not work for agent permission requests; users must ask a tenant admin to grant permissions directly. Risk-based step-up applies to agent consent and has no workaround.
Integrations, API tokens and service accounts
The blueprint is the credential holder for every agent created from it, which concentrates risk in one place.
| Blueprint credential | Microsoft guidance | When to use |
|---|---|---|
| Managed identity used as a federated identity credential | Preferred; the managed identity token is the blueprint's credential | Agent runtime hosted in Azure |
| Federated identity credential from an external issuer | Supported | Agents running on another cloud or in Kubernetes with an OIDC issuer |
| Certificate | Supported; recommended over secrets | Self-hosted runtimes without federation |
| Client secret | Not for production | Short-lived development only |
Practical points for integration teams:
- Use the SDK, not hand-built exchanges. Microsoft recommends the Entra ID Auth SDK sidecar or Microsoft.Identity.Web rather than implementing the multi-stage exchanges manually.
- Scale limits: for non-Microsoft management platforms using app-only permissions, the FAQ gives a limit of 250 agent identities per blueprint, and blueprints can use no more than 95% of the tenant's resource quota. Microsoft-owned platforms and delegated calls are exempt from the 250 limit.
- Permissions through access packages: entitlement management can grant agent identities group memberships, OAuth API permissions and Entra roles with approval and expiry. The agent can request programmatically through
accessPackageAssignmentRequest, a sponsor can request for it, or an admin can assign directly. Expiry is the main defence against permission creep. - API keys bypass the model: Conditional Access does not apply when an agent uses an API key instead of Entra tokens. Inventory agents that call Microsoft or third-party services with static keys and move them to Entra-issued tokens or a vault. See the Credential Vaulting for AI Agents Guide.
Platform-specific configuration for Copilot Studio agents is covered in Securing Microsoft Copilot Studio Agents Guide; Microsoft states that each Copilot Studio agent receives an agent identity and that the creating user is recorded as sponsor.
Conditional Access for agents
Conditional Access is evaluated when Entra issues or refreshes a token, and each token has one subject. Microsoft's guidance translates into three policy targets:
- Agent identities and blueprints for app-only access. A blueprint-level policy covers all current and future agents of that kind.
- Agent users under Assignments > Users, agents, or workload identities > Agents. Policies scoped through the ordinary Users assignment, including All users, do not apply to agent user accounts.
- Users and groups for delegated access, where the policy applies to the signed-in user rather than the agent.
Custom security attributes on agent identities can be used to target policies, which then follow new agents automatically. Documented gaps: policies do not apply to the blueprint's Graph token used to create agents, to the intermediate exchange at the "AAD Token Exchange Endpoint: Public" resource, or when security defaults are enabled. See the Conditional Access Guide for policy design in general.
Logging and detection
| Source | What to look for | Notes |
|---|---|---|
| Sign-in logs | agentSignIn event type; filters Agent type (Agent ID user, Agent Identity, Agent Identity Blueprint, Not Agentic) and Is Agent | Agent sign-ins can appear across four sign-in log types because agents use delegated and app-only flows; Reports Reader is the minimum role |
| Audit logs, ApplicationManagement | Add application (blueprint), Add service principal (agent identity), updates and deletes | Filter on agentType in initiatedBy, targetResources and the new auditActivityPerformer; correlate with blueprintId |
| Audit logs, UserManagement | Add user with agentType agentIDuser | Agent user creation and changes |
| Microsoft Graph activity logs | Requests where AppId is an agent identity, or UserId is an agent user | Not separated from other identities; join with sign-in logs on correlation ID or with a list of agent object IDs |
| ID Protection, risky agents | Detections such as unfamiliarResourceAccess, signInSpike, entraDirectoryReconnaissance, suspiciousCredentialUsage | Microsoft says these are currently offline detections and mostly apply to autonomous activity; in OBO flows risk is attributed to the user |
To receive the newer enum values in Graph responses, send the header Prefer: include-unknown-enum-members. The Risky Agents report offers Confirm compromise (sets risk to High and triggers risk-based block policies), Confirm safe, Dismiss and Disable. Build a Conditional Access policy that blocks High agent risk before you need it. For behavioural detection beyond Microsoft's detections, see the AI Agent Behaviour Baselining and Anomaly Detection Guide.
Metrics:
- Registration coverage: agents in production that authenticate through Agent ID rather than plain app registrations or shared user accounts.
- Sponsor health: agent identities whose sponsors are all active employees (target 100%).
- Policy coverage: blueprints and agent users covered by at least one Conditional Access policy, including a High-risk block.
- Expiring access: share of agent permissions granted through access packages with an end date.
- Orphans: agent user accounts whose agent identity or blueprint has been deleted.
- Secret use: blueprints with client secrets (target zero in production).
Hardening baseline
- Discover first. Use the Agent identities view and sign-in filters to list agents already created by Copilot Studio, Foundry or Microsoft's own agents, and separately list app registrations that are really agents.
- Define blueprint ownership. One owning team per blueprint, recorded owners, no individual developers as sole owners.
- Fix blueprint credentials. Move to managed identity or external federation; remove client secrets from production blueprints.
- Assign sponsors deliberately. Use a dynamic group where a team, not one person, is accountable; check that sponsor transfer to manager produces a sensible owner.
- Pilot Conditional Access on one blueprint (use report-only mode first where your tenant offers it for agent policies), then enforce. Add agent-user policies separately and a block for High agent risk.
- Grant through access packages with approval and expiry instead of direct permission grants.
- Wire up logs to your SIEM with the agentType and blueprintId fields and test by creating and deleting a test agent identity.
- Plan deletion. Deletion is not supported in the admin centre; use Graph or Entra PowerShell. Soft-deleted objects can be restored for 30 days. Deleting an agent identity leaves its agent user account in place, unable to authenticate, so remove it explicitly.
Rollback: disabling an agent identity or blueprint is the fast containment action; owners can re-enable, sponsors cannot. Disabling at blueprint level affects every agent of that kind, which is useful in an incident and disruptive by mistake. See the AI Agent Kill Switch and Containment Guide.
Small versus large tenants: a small tenant with a few Copilot Studio agents mainly needs sponsors, a High-risk block and log forwarding. A large tenant with custom platforms needs blueprint design standards, access package catalogues per business area and custom security attributes so that policies follow agents automatically.
Framework mapping
| Framework | Reference | Agent ID feature |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-2 Account Management, IA-4 Identifier Management | Blueprints, sponsors, lifecycle and deletion |
| NIST SP 800-53 Rev. 5 | IA-9 Service Identification and Authentication, IA-5 Authenticator Management | Credential-less agent identities, blueprint federation |
| NIST SP 800-53 Rev. 5 | AC-6 Least Privilege, AC-6(5) Privileged Accounts | Blocked roles and permissions, expiring access packages |
| NIST SP 800-53 Rev. 5 | AU-2 Event Logging, AU-6 Audit Record Review | agentSignIn, agentType, blueprintId |
| NIST CSF 2.0 | PR.AA-01, PR.AA-05, DE.CM-03 | Managed identities, enforced authorisations, monitoring |
| CIS Controls v8.1 | Control 5 Account Management, Control 6 Access Control Management | Inventory and least privilege for agent accounts |
| ISO/IEC 27001:2022 Annex A | 5.16 Identity management, 5.18 Access rights, 8.15 Logging | Identity lifecycle, access grants and logs for agents |
Common misconfigurations
- Policies scoped to All users only: agent user accounts are not covered by the Users assignment, so a tenant can believe it enforces Conditional Access on agents while agent users are untouched.
- Client secrets on blueprints: one leaked secret lets an attacker obtain tokens for every agent identity created from that blueprint.
- Sponsor as a formality: the developer is recorded as sponsor by default and nobody reviews the agent when they move teams. Sponsorship moving to a manager who has never heard of the agent is not accountability.
- Orphaned agent users: deleting the agent identity leaves the user account, which may still hold mailbox data and group memberships.
- Agents outside Agent ID: agents running on plain app registrations or shared service accounts get none of the agent-specific policies or log tags. See the OWASP Agentic Top 10 ASI03 Guide on identity and privilege abuse.
- Assuming risk detections are real time: Microsoft states the agent detections are currently offline, so pair them with near-real-time SIEM rules.
Practitioner checklist
- List every agent identity, blueprint and agent user with owner, sponsor and purpose.
- Move all production blueprints to managed identity, federation or certificates; remove client secrets.
- Confirm each agent identity and blueprint has an active sponsor; prefer dynamic groups for team ownership.
- Create Conditional Access policies for blueprints, for agent users (Agents assignment) and a block for High agent risk.
- Grant agent permissions through access packages with approval and an end date.
- Forward sign-in, audit and Graph activity logs to the SIEM with agentType and blueprintId parsed.
- Write a deletion runbook using Graph or Entra PowerShell that also removes the agent user account.
- Review agents that still use API keys or plain app registrations and plan their move to Agent ID.
Standards and references
- Microsoft Learn: What are agent identities
- Microsoft Learn: Agent identities in Microsoft Entra Agent ID
- Microsoft Learn: Microsoft Entra Agent ID authentication protocols
- Microsoft Learn: Administrative relationships for agent IDs
- Microsoft Learn: Conditional Access for agents
- Microsoft Learn: Governing agent identities
- Microsoft Learn: Sign-in and audit logs for agents
- Microsoft Learn: ID Protection for risky agents
Related NHI Mgmt Group resources: Identity Governance for AI Agents Guide · Agent Identity and Access Guide · Entra ID Security Guide · Cloud Agent Identity Services Compared