Microsoft Entra Agent ID is a dedicated identity layer for AI agents, currently in public preview, that assigns each agent its own unique identity inside Microsoft Entra and subjects it to the same Conditional Access policies, identity governance workflows, and risk detection systems that apply to human users. Announced at RSAC 2026, it is the identity foundation of Microsoft Agent 365 and the first major cloud IAM platform to create a dedicated identity type specifically for autonomous AI agents, rather than shoehorning them into service accounts or managed identities.
The distinction matters more than it sounds. Service accounts were designed for predictable, pre-programmed integrations. AI agents are autonomous, non-deterministic, and capable of spawning sub-agents. Treating them like service accounts is like issuing a driver’s license to a self-driving car fleet and hoping the DMV paperwork covers it.
Why Existing Identity Models Fall Short
The 2026 Microsoft Digital Defense Report found that 97% of organizations experienced an identity or network access incident in the past year, and 70% of those involved AI-related activity. The root cause is straightforward: most organizations authenticate their AI agents with static API keys or shared credentials that were never designed for autonomous systems.
A service account assumes one identity maps to one application performing a predictable set of operations. An AI agent might process a customer refund at 9:00 AM, analyze financial data at 9:01, and spin up three sub-agents to handle parallel tasks at 9:02. Each of those sub-agents needs its own scoped access. Static credentials cannot express that. Service principals in Entra ID come closer, but they lack agent-specific metadata, discovery mechanisms, and the behavioral risk signals needed to detect when an agent goes off-script.
The CSA/Strata survey of 285 security professionals found that only 18% of security leaders are highly confident their current IAM can handle agent identities. The other 82% know something is broken. Entra Agent ID is Microsoft’s bet on what the fix looks like.
The Three Problems Agent ID Solves
Traditional IAM frameworks fail for agents in three specific ways. Agent identities do not persist like user identities (agents spin up and terminate constantly). Agent permissions cannot be static (the same agent needs different access depending on what it is doing). And agent risk cannot be assessed the same way as user risk (you cannot send an MFA prompt to a Python process).
Entra Agent ID addresses each one directly: ephemeral but trackable identities, just-in-time scoped tokens, and behavioral anomaly detection instead of interactive authentication challenges.
How Entra Agent ID Works Under the Hood
Entra Agent ID introduces a new identity type in Microsoft Entra that sits alongside users, groups, and workload identities. Each agent registered through Microsoft Foundry, Copilot Studio, or an Agent 365 ecosystem partner receives its own agent identity object with a unique identifier, associated metadata (capabilities, tasks, protocols), and a link to the human or team that owns it.
Agent Autodiscovery
One of the hardest problems in agent governance is finding the agents that already exist. Microsoft reported discovering over 500,000 agents running inside its own organization before launching Agent 365. Most enterprises have a similar problem: teams spin up agents faster than IT can track them.
Entra Agent ID includes an autodiscovery mechanism that scans across the tenant for agents built on supported platforms and registers them automatically. Discovered agents appear in a central registry where admins can review their capabilities, assign owners, and apply governance policies. This is not optional inventory management. It is the prerequisite for everything else: you cannot govern what you cannot see.
Just-in-Time Scoped Tokens
Agent identities use a least-privilege model where agents request just-in-time, scoped tokens for exactly the resources they need. This is different from service accounts that typically hold broad, persistent credentials. An agent processing a customer support ticket gets a token scoped to the CRM and the ticketing system, valid for the duration of that task, and nothing else.
When the task finishes, the token expires. When a new task requires different resources, the agent requests a new token with different scopes. If the agent spawns a sub-agent, that sub-agent gets its own identity and its own scoped token, creating a traceable delegation chain. This is the kind of granularity that NIST’s Zero Trust Architecture calls for but that most organizations have never achieved for non-human identities.
Conditional Access for Agents
The Conditional Access engine now evaluates agent access requests with agent-specific logic. It treats agents as first-class identities and applies the same policy framework, context-aware recommendations, phased rollout, and automated least-privilege enforcement, but adapted for how agents actually behave.
In practice, this means you can write policies like: “Agents accessing financial data must originate from approved infrastructure, during business hours, and only when triggered by an authorized human.” The policy engine evaluates agent context (who owns it, what platform it runs on, what it is trying to access) and risk signals (is this agent behaving differently than its baseline?) before granting or denying access.
Microsoft also introduced Microsoft-managed policies that automatically block high-risk agent access as a baseline. Organizations can layer custom policies on top of these defaults.
Entra ID Protection for Agent Anomalies
Entra ID Protection, which already flags anomalous human sign-ins (unfamiliar locations, impossible travel, leaked credentials), now extends to agent identities. The system establishes behavioral baselines for each agent: what resources it normally accesses, how frequently, at what times, and in what patterns.
When an agent deviates from its baseline, for example if a customer service agent suddenly starts querying HR databases at 3 AM, Entra ID Protection flags the anomaly and triggers risk-based policies. Depending on configuration, this can mean requiring additional authorization from the agent’s human owner, throttling the agent’s access, or quarantining the agent entirely.
This behavioral approach is necessary because agents cannot respond to interactive authentication challenges. You cannot prompt an API call for a second factor. Instead, the system watches what agents do and reacts when behavior stops matching expectations. It is a fundamentally different security model, closer to EDR (endpoint detection and response) than to traditional IAM.
How Risk Signals Flow
Agent risk signals feed into the same Conditional Access engine that handles user risk. Security teams can configure policies that combine agent risk with other conditions: “If agent risk is high AND the target resource is classified as sensitive, block access and notify the security operations center.” This integration means agent security does not require a separate monitoring stack. It plugs into Microsoft Defender and Purview the same way user security already does.
What This Means for Enterprises Already Running Agents
If your organization uses Microsoft Entra ID for identity governance, extending it to agents is configuration work, not a platform migration. The agent identity objects live in the same directory, use the same policy engine, and generate audit logs in the same format. Your security team already knows the tools.
The harder question is whether the Microsoft-only scope is a limitation. Entra Agent ID currently supports agents built with Microsoft Foundry, Copilot Studio, and Agent 365 ecosystem partners including Adobe, Databricks, SAP, ServiceNow, and Workday. If your agents run on LangChain, CrewAI, or a custom framework, you would need to integrate them through the Entra identity platform APIs or use a third-party agent identity provider like Oasis Security or Aembit.
Preview Limitations to Watch
Entra Agent ID is in preview, not GA. Microsoft’s documentation explicitly notes that the product “may be substantially modified before it’s released.” Key limitations to consider:
- Agent 365 GA is May 1, 2026. Entra Agent ID’s timeline is tied to this. Do not build production governance around preview APIs.
- Partner ecosystem coverage varies. Not all ecosystem partners support the full identity lifecycle yet. Check your specific vendor’s integration status.
- Behavioral baselines take time. Entra ID Protection needs observational data before it can flag anomalies. New agent deployments will have a blind period.
- Multi-cloud gaps persist. Agents that operate across Azure, AWS, and GCP will need additional identity federation work.
The Competitive Landscape
Microsoft is not the only company building agent identity infrastructure. Oasis Security offers a platform-agnostic agent governance layer. Aembit specializes in workload-to-workload identity. Geordie AI is building a control plane specifically for agent security governance. And Google’s Agent2Agent protocol includes identity concepts, though it is more focused on interoperability than governance.
What Microsoft brings that others do not is the installed base. With 400 million monthly active commercial users on Microsoft 365 and Entra ID already managing their human identities, extending the same system to agents eliminates the “yet another identity provider” problem. For organizations already in the Microsoft ecosystem, this is the path of least resistance. For everyone else, the question is whether a single vendor’s identity system should govern all your agents, or whether a multi-platform approach makes more sense.
Frequently Asked Questions
What is Microsoft Entra Agent ID?
Microsoft Entra Agent ID is a dedicated identity layer within Microsoft Entra that assigns unique identities to AI agents, bringing them into the same Conditional Access, identity governance, and risk detection workflows that apply to human users. It is currently in public preview and serves as the identity foundation of Microsoft Agent 365.
How does Conditional Access work for AI agents in Entra Agent ID?
Conditional Access evaluates agent access requests using agent-specific logic, considering context like who owns the agent, what platform it runs on, and what it is trying to access. Policies can enforce conditions such as approved infrastructure, business hours, and authorized human triggers. Microsoft-managed policies automatically block high-risk agent access as a baseline.
Does Entra Agent ID work with non-Microsoft AI agent frameworks?
Entra Agent ID natively supports agents built with Microsoft Foundry, Copilot Studio, and Agent 365 ecosystem partners including Adobe, Databricks, SAP, ServiceNow, and Workday. Agents built on LangChain, CrewAI, or custom frameworks would need to integrate through the Entra identity platform APIs or use a third-party agent identity provider.
When will Microsoft Entra Agent ID be generally available?
Entra Agent ID is currently in public preview as of March 2026. Its timeline is tied to Microsoft Agent 365, which reaches general availability on May 1, 2026. Microsoft has noted the preview product may be substantially modified before release.
How does Entra Agent ID detect anomalous agent behavior?
Entra ID Protection establishes behavioral baselines for each agent identity by tracking what resources it normally accesses, how frequently, and in what patterns. When an agent deviates from its baseline, the system flags the anomaly and triggers risk-based policies, which can range from requiring additional authorization to quarantining the agent entirely.