Recently I was chatting with a colleague whose organisation had gone, shall we say, a little enthusiastic with AI agents. They had a Copilot Studio agent handling HR queries, a Foundry agent processing invoices, a couple of custom Python agents doing data analysis, and (my personal favourite) an agent that nobody could quite remember deploying but was definitely still running. When someone asked “who authorised that agent to access your SharePoint?” the room went quiet. That moment right there is why Microsoft Entra Agent ID exists.
Over the past twelve months, Microsoft has shipped an entire identity and access management stack purpose-built for AI agents, and it has landed in two major waves. Wave one at Build 2025 introduced the core Agent ID platform. Wave two at Ignite 2025 added Conditional Access for agents, the Agent Registry, risk management, and the Microsoft Agent 365 control plane. Together they form a comprehensive answer to the question every security team should be asking: how do we apply Zero Trust to things that aren’t human?
This post will walk through the full agent identity lifecycle, from creation to retirement, and cover each of the major components. Let’s dive in!
What Is Entra Agent ID (and Why Do Agents Need Their Own Identity)?
If you’ve worked with Microsoft Entra (formerly Azure AD) for any length of time, you already know the drill for humans: every user gets an identity, that identity is governed by policies, and access is evaluated continuously. The problem is that AI agents don’t fit neatly into the existing identity constructs. They’re not quite users, they’re not quite service principals, and they have behaviours that are genuinely unique: they operate autonomously, they interact with sensitive data at scale, and they can take initiative without a human pressing a button.
Microsoft Entra Agent ID solves this by introducing first-class identity constructs specifically designed for agents. The platform is built on OAuth 2.0 and OpenID Connect (so nothing exotic from a protocol perspective), but it adds agent-specific identity objects that sit alongside your existing user and workload identities.
Here are the key building blocks:
- Agent Identity Blueprint: a reusable template that defines an agent type’s capabilities, permissions, and governance rules. Think of it as the “job description” for a class of agents.
- Agent Identity: an instantiated identity for a specific agent. This is what actually acquires tokens and accesses resources.
- Agent User: a non-human user identity for agents that need to participate in user-like experiences (joining Teams channels, having an email address, being added to groups).
- Agent Resource: an agent acting as the target of another agent’s request, supporting agent-to-agent (A2A) flows.
The important thing to understand is that agent identities don’t use passwords or secrets in the traditional sense. They authenticate using access tokens issued to the platform or service where the agent runs. This is a much cleaner model than the old “create an app registration and hope nobody leaks the client secret” approach. In my opinion, this alone is worth the price of admission.
Note: Entra Agent ID is currently in preview and requires the Frontier program through Microsoft 365 Copilot licensing. Check the getting started guide for current licensing requirements.
The Agent Registry: Finally, an Inventory of Everything
Remember that mystery agent from my opening story? The Agent Registry is Microsoft’s answer to “what agents are actually running in my tenant?”
The registry acts as a centralised metadata repository that delivers a unified view of all deployed agents, whether they were built in Copilot Studio, Microsoft Foundry, or a third-party platform. It even tracks agents that don’t have an Agent ID yet (Microsoft calls these “shadow agents,” which is appropriately ominous).
Key capabilities include:
- Comprehensive inventory: see every agent across Microsoft and non-Microsoft ecosystems in one place
- Rich metadata: who built it, where it runs, what capabilities it has, who sponsors it, and what governance policies apply
- Collection-based policies: group agents into collections and apply discovery and access policies at scale
- Discovery controls: define which agents can find and communicate with other agents (only agents with an Agent ID can discover other agents in the registry)
The registry integrates with the Microsoft Entra Core Directory, so identity and entitlement policies are enforced centrally. Each agent instance has a direct 1:1 relationship with an agent identity, and blueprints can map to multiple agent instances for scalable governance.
This is, in my experience, the single most valuable capability for organisations that have already deployed multiple agents. You can’t secure what you can’t see, and the Agent Registry gives you that visibility.
Conditional Access for Agents: Same Zero Trust, New Identity Type
This is where things get really interesting. Conditional Access for Agent ID extends the exact same Zero Trust controls that protect your human users to AI agents. If you’ve ever configured a Conditional Access policy (and if you’re reading this blog, I’d bet you have), the experience will feel immediately familiar.
Conditional Access evaluates agent access requests in real time and applies when:
- An agent identity requests a token for any resource
- An agent user requests a token for any resource
Policy configuration follows the same four-part structure you already know:
- Assignments: scope to all agent identities, specific agents by object ID, agents grouped by blueprint, or agents filtered by custom security attributes
- Target resources: all resources, specific resources by appId, or agent blueprints (which cascades to child agent identities)
- Conditions: agent risk level (high, medium, low) from ID Protection
- Access controls: block access
Here’s a practical example. Say you want to ensure only HR-approved agents can access HR resources. You would create custom security attributes (e.g., AgentApprovalStatus: HR_Approved), assign them to your approved agents, then create a Conditional Access policy that blocks all agent identities except those with the HR_Approved attribute. Pretty straight forward, and identical in concept to how you’d handle human users.
Be warned: Conditional Access does not apply when an agent identity blueprint acquires a token to create child agent identities, or during intermediate token exchanges at the AAD Token Exchange Endpoint. This is by design, as those flows are scoped to identity creation rather than resource access, but it’s worth understanding the boundary.
Agent Risk Management: ID Protection for Non-Humans
Microsoft Entra ID Protection for agents extends the same risk detection capabilities you know from human identity protection to your agent fleet. The system establishes a baseline for each agent’s normal activity and then continuously monitors for anomalies.
The current risk detections (all offline at this stage) include:
| Detection | What It Catches |
|---|---|
| Unfamiliar resource access | Agent targeted resources it doesn’t usually access |
| Sign-in spike | Unusually high number of sign-ins compared to baseline |
| Failed access attempt | Agent tried to access resources it’s not authorised for |
| Sign-in by risky user | Agent signed in on behalf of a compromised user |
| Admin confirmed compromised | Manual confirmation by an administrator |
| Threat intelligence | Activity matching known attack patterns |
From the Risky Agents report, you can confirm compromise (which automatically sets risk to High and triggers Conditional Access policies), confirm safe, dismiss risk, or disable the agent entirely. You can also query risky agents via the Microsoft Graph API using the riskyAgents and agentRiskDetections collections.
I genuinely love that Microsoft hasn’t tried to reinvent the wheel here. If you already know how ID Protection works for humans, you basically know how it works for agents. Same reports, same actions, same integration with Conditional Access.
Owners, Sponsors, and Managers: Who’s Responsible?
One of the more thoughtful design decisions in Entra Agent ID is the administrative relationships model. Every agent needs clear accountability, and the platform separates this into three distinct roles:
- Owners: technical administrators who handle configuration, credentials, and operational management. Service principals can also be owners, enabling automated management.
- Sponsors: business representatives who are accountable for the agent’s purpose and lifecycle decisions. They can enable/disable agents but can’t modify technical settings. A sponsor is required when creating an agent identity.
- Managers: the person responsible for an agent within the organisational hierarchy. Managers can request access packages for agents that report to them.
This separation of technical and business accountability is something I’ve been advocating for in identity governance for years. It prevents the “the developer who built it left six months ago and nobody knows what it does” scenario that plagues so many organisations.
AI Prompt Shield: Network-Layer Protection
While Entra Agent ID handles identity and access, AI Prompt Shield (part of Global Secure Access) provides network-layer protection against prompt injection attacks. It sits in front of your AI applications and blocks adversarial prompts before they ever reach the model.
Prompt Shield works across any device, browser, or application for uniform enforcement, and comes pre-configured with extractors for major models including ChatGPT, Claude, Gemini, and Deepseek. You can also protect custom JSON-based LLM applications by specifying the URL and JSON path.
The setup is pretty straight forward: create a prompt policy, link it to a security profile, then create a Conditional Access policy targeting Global Secure Access internet traffic. It’s real-time blocking at the network layer, which means no code changes to your applications.
Note: Prompt Shield currently supports only text prompts (no files) and has a 10,000 character limit per prompt. It also requires Microsoft Entra Internet Access licensing.
Microsoft Agent 365: The Governance Control Plane
Wrapping everything together is Microsoft Agent 365, announced at Ignite in November 2025. Agent 365 is the unified control plane that lets you oversee the security of all AI agents across your organisation, regardless of where they were built.
Agent 365 extends your existing Microsoft security stack to agents:
- Entra Agent ID for identity and lifecycle management (everything we’ve covered above)
- Microsoft Purview for DLP enforcement, insider risk management, audit, compliance, retention and deletion policies for agent-generated content, and AI regulation compliance templates
- Microsoft Defender for security posture management and real-time threat protection
- Observability dashboards for tracking every agent’s activity across the fleet
The key value proposition is that you don’t need to learn entirely new tools. Agent 365 integrates with the Microsoft 365 Admin Center, giving IT teams a familiar interface to configure policies, apply Conditional Access, and monitor compliance. As Microsoft’s own blog puts it, the same Zero Trust principles that apply to human employees now apply to AI agents, and you can use the same tools to manage both.
Agent 365 is set to become generally available on May 1, 2026, priced at $15 per user per month. It’s also included in ME7, which provides the most complete experience for scaling agents securely.
Human vs. Agent Identity Controls: A Quick Comparison
To illustrate how comprehensive this is, here’s a side-by-side view:
| Capability | Human Users | AI Agents |
|---|---|---|
| Identity | User account in Entra ID | Agent Identity / Agent User in Entra Agent ID |
| Conditional Access | Risk-based, device-based, location-based policies | Agent risk-based policies, custom security attributes |
| Risk Detection | ID Protection (impossible travel, leaked creds, etc.) | ID Protection for agents (unfamiliar resources, sign-in spikes, etc.) |
| Governance | Lifecycle workflows, access reviews, entitlement management | Sponsor/Owner model, lifecycle workflows, access packages |
| Network Protection | Global Secure Access, web content filtering | AI Prompt Shield, web content filtering for agent traffic |
| Compliance | Purview DLP, insider risk, audit | Purview DLP, insider risk, audit, retention for agent content |
| Inventory | User directory | Agent Registry |
The parity is genuinely impressive. Microsoft hasn’t bolted agent security onto the side of existing tools; they’ve extended the entire stack.
Wrapping Up
The shift from “AI agents are a developer concern” to “AI agents are an identity and governance concern” is one of the most significant security evolutions I’ve seen in the Microsoft ecosystem. Entra Agent ID gives every agent a proper identity. Conditional Access enforces Zero Trust. ID Protection catches anomalies. The Agent Registry provides visibility. And Agent 365 ties it all together in a unified control plane.
If your organisation is deploying agents (or planning to), I’d strongly recommend getting across these capabilities now, even while they’re in preview. The fundamentals of identity governance don’t change just because the identity belongs to a bot rather than a person.
Until next time, stay cloudy!
James Westall 