What is Microsoft Entra Agent ID?

Why did Microsoft build an identity system for AI agents?

Announced at Microsoft Build in May 2025 and now generally available, Entra Agent ID is Microsoft's answer to a problem every large organization is now hitting: AI agents are multiplying faster than any identity type before them, and most of them are invisible to the identity team. IDC, in a Microsoft-sponsored forecast, projects 1.3 billion AI agents in use by 2028. Each one holds credentials, calls APIs, and acts on data, which makes it a non-human identity with real blast radius.

Before Agent ID, agents typically ran on borrowed credentials: a maker's user account, a shared service principal, or an embedded API key. That pattern created unattributable activity and unchecked agent sprawl. Agent ID's core move is to make each agent a first-class directory object, so the same admin surface that answers who has access for employees can answer it for agents.

How does Entra Agent ID work?

Agent ID introduces a purpose-built identity construct, the agent identity, a special type of service principal created from an agent identity blueprint rather than a reused user account or a hand-configured generic service principal. Agent identities are created from blueprints, templates that define security posture and support parent-child relationships, so a fleet of related agents inherits consistent policy instead of being configured one at a time. This matters because AI agent identity differs from both human and workload identity: agents act autonomously, delegate to other agents, and change behavior with their instructions.

Registration is automatic for Microsoft's own builders: an agent created in Copilot Studio or Azure AI Foundry is assigned an Entra identity with no extra work from the developer. Agents built elsewhere, on platforms such as AWS Bedrock or n8n, can be brought under the same directory through an SDK sidecar or through workload identity federation, which exchanges the agent's native credential for Entra tokens without long-lived secrets.

What security controls does it extend to agents?

The design principle is reuse: the controls enterprises already apply to users are extended to agent identities rather than rebuilt. That gives identity teams a familiar toolkit for a new identity class, and it puts agent activity into the same logs their SIEM already ingests, a prerequisite for identity threat detection and response to cover agents at all.

• Conditional Access: adaptive policies decide whether an agent can authenticate, based on risk signals and policy, the same engine used for zero trust identity decisions on humans
• Identity Protection: risk detection flags anomalous or compromised agents so they can be blocked or remediated
• Identity Governance: access reviews, entitlement management, and lifecycle workflows apply least privilege to agent permissions and retire agents that are no longer needed
• Sign-in and audit logs: agent authentications are attributable to a specific agent identity rather than a shared account, though sign-in logs do not record every downstream action an agent takes
• Network controls: web and AI gateway policies restrict where agents can reach

How does it relate to open standards like OAuth, MCP, and A2A?

Agent ID is built on standard protocols rather than a proprietary auth scheme. Agents authenticate with OAuth 2.0, and the platform supports the Model Context Protocol and the Agent2Agent protocol for tool access and agent-to-agent communication. That matters because the riskiest agent behaviors, calling tools through MCP servers and delegating work to other agents, are exactly where MCP security gaps and confused deputy failures show up. Anchoring those flows to a directory-issued identity gives each hop an auditable principal.

Microsoft has also worked with the OAuth community on extensions for agent scenarios, including flows where an agent acts on behalf of a user with the user's identity carried in the token chain. For how that delegation chain should work in general, vendor-neutral terms, see AI agent delegation.

What does Entra Agent ID not cover?

Agent ID is a directory and policy layer, and its automatic coverage is strongest inside Microsoft's own ecosystem. Understanding its boundaries helps teams plan the rest of their agentic AI security program rather than assume the directory solves it.

• Agents built outside Microsoft platforms require deliberate integration work; nothing forces an unregistered agent to appear in the directory, so shadow AI remains a discovery problem
• An identity entry proves who an agent is, not whether what it is doing right now is sane; runtime behavior analysis is a separate layer
• Advanced protections are tied to licensing tiers, including Microsoft Agent 365 and Entra ID P1 or P2, so coverage depends on what the organization has purchased
• Agents still need governed access to secrets and third-party APIs, which keeps secrets management and API credential hygiene in scope
• Multi-cloud and multi-IdP estates need an answer for agents anchored in other directories

What should security teams do with it?

For Microsoft-centric organizations, the practical starting point is inventory: enable agent identity creation in the platforms where employees are already building agents, then review what appears in the directory. From there, apply the same discipline used for other non-human identities across the NHI lifecycle: assign owners, scope permissions, set expiration and review cycles, and alert on anomalous sign-ins. Treat the directory listing as the foundation of AI governance, not the finish line, and pair it with runtime monitoring for what agents actually do with the access they hold.

Frequently asked questions

Related terms