@@ -1,147 +1,133 @@ ----title: Conditional Access for Agents in Microsoft Entra-description: Learn how Conditional Access for agents in Microsoft Entra ID extends Zero Trust principles to AI agents, ensuring secure access and governance.+title: Microsoft Entra Conditional Access for agents overview+description: Learn how Microsoft Entra Conditional Access evaluates agent access and choose the right policy guidance for each agent access pattern.+author: gracenagy+ms.author: gracenagy+ms.service: entra-id ms.topic: concept-article-ms.date: 06/19/2026+ms.date: 07/31/2026 ms.reviewer: yoelhor, kvenkit-ms.custom: msecd-doc-authoring-1012+ms.custom: msecd-doc-authoring-1017 ai-usage: ai-assisted-#customer-intent: As an identity administrator, I want to understand how Conditional Access policies apply to agents in Microsoft Entra ID, so that I can effectively manage and secure access for AI agents in my organization.------# Conditional Access for agents--Conditional Access is an intelligent policy engine that helps organizations control how users and agents access corporate resources. It brings together real-time signals such as user's and agent's context, device, location, and session risk information to determine when to allow, block, or limit access, or require more verification steps.--Conditional Access for agents requires Microsoft Entra ID P1 or P2 and a Microsoft Agent 365 license for each user. Enforcement of Agent 365 licensing is coming soon. Network controls for agents require Microsoft Entra Internet Access. For more information, see [What is Microsoft Entra Agent ID](../../agent-id/what-is-microsoft-entra-agent-id.md#how-to-get-started). -Learn about Conditional Access for agents:+#customer intent: As an identity administrator, I want to understand how Conditional Access evaluates agent access so that I can choose the right policy target and guidance.+--- -- High-level overview of Conditional Access: [What is Conditional Access?](overview.md)-- Guide to managing agent identities across your organization: [Manage agent identities in your organization](../../agent-id/manage-agent-identities-admin.md).-- [How to target agent identities in Conditional Access](howto-target-agent-identities.md)-- [Configure policies for autonomous agent access](policy-autonomous-agents.md)+# Microsoft Entra Conditional Access for agents overview -## How Conditional Access evaluates agent access requests+Conditional Access for agents is an extension of the Conditional Access policy engine that controls how agents access resources protected by Microsoft Entra ID. It evaluates the subject that requests an access token and the resource that the token is for. -To access a corporate resource such as SharePoint file, MCP servers, or Open API services, a user or agent first requests an access token from Microsoft Entra ID.- -When a Conditional Access policy applies, Microsoft Entra ID evaluates the configured policy requirements before issuing the token. If the requirements are satisfied, an access token is issued. The token is then presented to the target resource, which validates the token and uses its claims to make authorization decisions.+Understanding the agent's access pattern helps you target the correct identity. An agent can act on behalf of a signed-in user, use its own agent identity, or use its own agent user account. -The following diagram illustrates this process.+## Requirements and licensing -:::image type="content" source="media/agent-id/data-access-patterns-diagram.png" alt-text="Diagram showing the data access patterns for agent identities." lightbox="media/agent-id/data-access-patterns-diagram.png":::+Conditional Access for agents requires Microsoft Entra ID P1 or P2 and a Microsoft Agent 365 license for each user. Enforcement of Agent 365 licensing is coming soon. Network controls for agents require Microsoft Entra Internet Access. -### How subjects and audiences are used+For more information, see [What is Microsoft Entra Agent ID](../../agent-id/what-is-microsoft-entra-agent-id.md#how-to-get-started). -Microsoft Entra ID issues an access token to a subject for a specific audience (resource). Each access token has exactly one subject and one audience.+<a name='how-conditional-access-evaluates-agent-access-requests'></a> -**Subject**: The identity receiving the token.+## How Conditional Access evaluates agent access -- In delegated access scenarios, the token represents the user while also identifying the calling application or agent.-- In application-only scenarios, the application or autonomous agent is the subject.-- In agent's user account scenarios, the agent's user account is the subject.+To access a resource such as a SharePoint file, MCP server, or Open API service, a user or agent requests an access token from Microsoft Entra ID. -**Audience**: The target resource the token is intended for.+When a Conditional Access policy applies, Microsoft Entra ID evaluates the policy requirements before it issues the token. If the requirements are satisfied, Microsoft Entra ID issues the token. The target resource validates the token and uses its claims to make authorization decisions. -- The resource must be registered in Microsoft Entra ID.-- If a subject needs to access multiple resources (for example, multiple MCP servers or APIs), it typically requires a separate access token for each resource, each with its own audience and permissions.+:::image type="content" source="media/agent-id/data-access-patterns-diagram.png" alt-text="Diagram showing the data access patterns for agent identities." lightbox="media/agent-id/data-access-patterns-diagram.png"::: -Conditional Access policies are evaluated based on both the subject requesting access and the audience being accessed.+Each access token has one subject and one audience: -### How Conditional Access decisions are made+- **Subject**: The identity that receives the token. In delegated access, the token represents the user and identifies the calling application or agent. In application-only access, the application or autonomous agent is the subject. In agent-user access, the agent's user account is the subject.+- **Audience**: The target resource that the token is for. If a subject accesses multiple resources, it typically needs a separate token for each resource. -Conditional Access policies operate as if-then statements:+Conditional Access evaluates both the subject that requests access and the audience being accessed. It evaluates policies when Microsoft Entra ID issues or refreshes an access token. Some resources also support Continuous Access Evaluation, which can trigger near-real-time enforcement for specific events. -- If the conditions defined in a policy are met, the configured access controls are enforced.-- If the required controls are satisfied, access is granted.-- If the required controls are not satisfied, access is denied.+<a name='agent-access-patterns'></a> -For example, an organization may require multifactor authentication before a user can authorize an agent to access their email. Similarly, an organization may configure a policy to block access from agents identified as high risk.+## Choose an agent access pattern -### When Conditional Access is evaluated+Choose the access pattern based on the subject of the token, not the platform where the agent was built. -Conditional Access is evaluated whenever Microsoft Entra ID issues or refreshes an access token. Some resources also support Continuous Access Evaluation, which can trigger near-real-time enforcement for specific events.+| If the agent | Access pattern | Policy target | Guidance |+|---|---|---|---|+| Accesses downstream resources for a signed-in user | On-behalf-of (OBO), also known as delegated access | Users and groups | [Agent OAuth flows: On-behalf-of](../../agent-id/agent-on-behalf-of-oauth-flow.md) |+| Accesses resources with its own agent identity and no signed-in user | Application-only, also known as client credentials or app-only access | Agent identity or agent identity blueprint | [Secure autonomous agents with Conditional Access](policy-autonomous-agents.md) |+| Accesses resources through its own user account | Agent-user access | Agent's user account | [Secure agents that act as users with Conditional Access](policy-agent-user.md) | -## Agent access patterns+An agent can use more than one access pattern. Create separate policies for each token subject that the agent uses. A policy that targets an agent identity doesn't apply to the agent's user account, and a policy that targets the agent's user account doesn't apply to the agent identity. -Agents can access Microsoft Entra-protected resources using one of the following patterns:+<a name='agents-acting-on-behalf-of-a-user'></a> -### Agents acting on behalf of a user+## Agents that act on behalf of a user -The most common access pattern is the on-behalf-of (OBO) flow. In this flow, a user signs in to an agent application, and the agent accesses downstream resources using the user's identity and delegated permissions. For example, when an agent reads your emails, it accesses your mailbox *on your behalf*. For more information about how the OBO flow works for agents, see [Agent OAuth flows: On-behalf-of](../../agent-id/agent-on-behalf-of-oauth-flow.md).+In the OBO flow, a user signs in to an agent application. The agent accesses downstream resources with the user's identity and delegated permissions. -> [!NOTE]-> The on-behalf-of flow is also known as delegated access. "On-behalf-of" describes the authentication flow, not the type of agent. These interactive agents involve a user interface for human interaction. Any agent can use this flow when a signed-in user is present and the agent needs to access resources with that user's identity and permissions.+The agent can't reuse the user's original token because that token is for a different audience. The agent exchanges the token for a new token for the target resource. Conditional Access evaluates this token exchange. -In this flow, the agent can't reuse the user's original token because it was issued for a different audience. Instead, the agent uses the OBO flow to exchange tokens with Microsoft Entra ID, obtaining a new token scoped to the target resource. This token exchange is also evaluated by Conditional Access, letting admins enforce granular controls over which resources agents can access on behalf of the user.+Because the user is the subject, Conditional Access policies target users and groups, not agent identities. The OBO flow describes the authentication flow, not a type of agent. Any agent can use this flow when a signed-in user is present and the agent needs the user's identity and permissions. -Because the user is the subject in this flow, Conditional Access policies target **users and groups**, not agent identities. +<a name='agents-acting-as-an-application'></a> -### Agents acting as an application+## Agents that act as applications -Agents might access resources without a signed-in user. In this case the agent accesses the resource with its own identity. This flow is also known as client credentials flow, or app only access. All types of agents might use this flow. For more information about how agents authenticate with their own identity, see [Agent OAuth flows: Autonomous apps](../../agent-id/agent-autonomous-app-oauth-flow.md).+In application-only access, an agent accesses resources with its own agent identity and no signed-in user. This access pattern applies to agents that: -This flow applies in the following common scenarios:+- Run in the background, respond to events, or run on a schedule.+- Use their own identity for a backend service that users can't access.+- Are published for public use without delegated user context. -- **Autonomous agents that operate independently** run in the background, respond to events, or run on a schedule.-  - For example, an agent that generates a daily report and sends the result to a group of employees.-  - In this scenario, there's no user present, and the agent operates on its own.-- **Interactive agents that use their own identity** don't always access resources on a user's behalf; sometimes they use their own identity.-  - For example, if an agent calls a backend SMS service that users don't have access to, the OBO flow doesn't apply, and the agent authenticates directly as itself.-- **Agents published on the web for public use** don't authenticate the user or don't support delegating the user's context to corporate resources.+The token is issued to the agent identity. Conditional Access policies therefore target the agent identity or its agent identity blueprint. For policy examples, see [Secure autonomous agents with Conditional Access](policy-autonomous-agents.md). -In these scenarios, the agent requests an access token using its own agent identity and credentials managed through the agent identity blueprint. The token is issued to the agent identity (not the user). Therefore, Conditional Access policies are scoped to the agent identity rather than the user. For step-by-step policy configuration, see [Conditional Access for autonomous agents](policy-autonomous-agents.md).+<a name='agents-acting-as-a-user'></a> -### Agents acting as a user+## Agents that act as users -Sometimes it's not enough for an agent to perform tasks on behalf of a user or operate with its own identity. In certain scenarios, an agent has its own [agent's user account](../../agent-id/agent-users.md) that functions as a digital worker with its own mailbox, access to chat, and the ability to participate in collaborative workflows as a team member.+An agent user account lets an agent have a mailbox, access chat, or participate in collaborative workflows as a team member. An administrator creates the user account in the directory and links it to the agent identity. -In this model, an admin creates a user account in the directory and links it to the agent's identity. From there, it's like any other user account. Licenses can be assigned to access Microsoft 365 resources such as a mailbox and calendar. The account can be added to administrative units and security groups just like a human user account.+The token is issued to the agent's user account. Conditional Access policies therefore target the agent's user account, not the agent identity. -Agents using this flow are also considered autonomous agents as they don't involve a user interface for human interaction. In this model, the access token is issued to the agent's user account (the token subject), and policy is evaluated against the agent's user account, not the agent identity. For step-by-step policy configuration, see [Conditional Access for autonomous agents](policy-autonomous-agents.md). For more information about the agent user OAuth flow, see [Agent user OAuth flow](../../agent-id/agent-user-oauth-flow.md).+Agents that run on managed endpoints such as Windows 365 Cloud PCs for Agents can use device compliance and compliant network controls. The **Agent execution environments (Preview)** condition limits these policies to endpoint-based sessions. For policy examples, see [Secure agents that act as users with Conditional Access](policy-agent-user.md). -Agents running on managed endpoints like [Windows 365 Cloud PCs for Agents](/windows-365/agents/introduction-windows-365-for-agents) can also be subject to device compliance and compliant network controls. Use the **Agent execution environments (Preview)** condition to scope these policies to endpoint-based sessions only. For more information, see [Require a compliant device for agents' user accounts](policy-autonomous-agents.md#require-a-compliant-device-for-agents-user-accounts).+<a name='conditional-access-policies-and-agent-identity-blueprints'></a> -## Conditional Access policies and agent identity blueprints+## Agent identity blueprints -In addition to the specific agent access patterns, you can also select [agent identity blueprints](../../agent-id/agent-blueprint.md) to apply Conditional Access policies to a class of agents. Every agent identity is derived from an agent identity blueprint, which defines its configuration and governance model. Applying a policy at the blueprint level automatically covers all agent identities derived from it, including any new ones added in the future. Targeting the agent identity blueprint does not cover agents' user accounts.+An agent identity blueprint defines the configuration and governance model for agent identities created from it. A policy that targets a blueprint applies to all agent identities created from that blueprint, including agent identities created later. -The following diagram shows that only agent identities associated with blueprint "A" are granted access; all other agents are excluded and blocked.+Targeting an agent identity blueprint doesn't cover agent user accounts. -:::image type="content" source="media/agent-id/conditional-access-agent-identity-blueprint-diagram.png" alt-text="Diagram showing the Conditional Access flow for agent identity blueprints." lightbox="media/agent-id/conditional-access-agent-identity-blueprint-diagram.png":::+:::image type="content" source="media/agent-id/conditional-access-agent-identity-blueprint-diagram.png" alt-text="Diagram showing a Conditional Access policy applied to agent identities from one blueprint." lightbox="media/agent-id/conditional-access-agent-identity-blueprint-diagram.png"::: -For example, imagine a project where you have several agents, each with its own purpose. Some operate independently, while others collaborate with other agents (A2A) to complete tasks. If they're all created under the same blueprint, a single policy applied to that blueprint enforces consistent access controls across the entire collection.+For example, several agents in one project might operate independently or work together. If they come from the same blueprint, one policy on the blueprint can apply consistent controls across the collection.  ## Attribute-driven Conditional Access -As the number of agent identities grows, individually managing each one across every policy becomes unsustainable. [Custom security attributes](../../fundamentals/custom-security-attributes-overview.md) let you categorize agent identities and resources with business-specific labels, then target those attributes in Conditional Access policies. Policies automatically apply to every agent with matching attributes, including ones added in the future.+Custom security attributes let you categorize agent identities and resources with business-specific labels. Conditional Access policies can target those attributes instead of individual objects.++Policies based on custom security attributes apply to matching agent identities, including matching identities created later. -:::image type="content" source="media/agent-id/conditional-access-agent-diagram.png" alt-text="Diagram showing the Conditional Access flow for agent identities." lightbox="media/agent-id/conditional-access-agent-diagram.png":::+:::image type="content" source="media/agent-id/conditional-access-agent-diagram.png" alt-text="Diagram showing Conditional Access applied to agent identities by using custom security attributes." lightbox="media/agent-id/conditional-access-agent-diagram.png"::: -For a full walkthrough on creating custom security attributes and using them in a Conditional Access policy, see [Conditional Access for autonomous agents](policy-autonomous-agents.md#allow-only-specific-agents-to-access-resources).+For a policy example, see [Allow approved agents by using custom security attributes](policy-autonomous-agents.md#allow-approved-agents-by-using-custom-security-attributes). -## Conditional Access boundaries and limitations+## Boundaries and limitations -Conditional Access policies don't apply when:+Conditional Access policies don't apply in these cases: -- An agent identity blueprint acquires a token for Microsoft Graph to create an agent identity or agent's user account.-  - Agent blueprints have limited functionality. They can't act independently to access resources and are only involved in creating agent identities and agents' user accounts.-  - Agent tasks are always performed by the agent identity.-- An agent identity blueprint or agent identity performs an intermediate token exchange at the `AAD Token Exchange Endpoint: Public` endpoint (Resource ID: `fb60f99c-7a34-4190-8149-302f77469936`).-  - Tokens scoped to the `AAD Token Exchange Endpoint: Public` can't call Microsoft Graph.-  - Agent flows are protected because Conditional Access protects token acquisition from the agent identity or agent's user account.-- [Security defaults](../../fundamentals/security-defaults.md) are enabled.-- Conditional Access only protects resources secured by Microsoft Entra ID. For example, if an agent accesses resources using an API key, it bypasses the Microsoft Entra ID authentication and token issuance pipeline entirely and Conditional Access policies won't apply to them.+- An agent identity blueprint gets a token for Microsoft Graph to create an agent identity or agent user account. Agent blueprints can't act independently to access resources. Agent identities perform agent tasks.+- An agent identity blueprint or agent identity performs an intermediate token exchange at the `AAD Token Exchange Endpoint: Public` endpoint with resource ID `fb60f99c-7a34-4190-8149-302f77469936`. Tokens for this endpoint can't call Microsoft Graph.+- Security defaults are enabled.+- An agent accesses a resource without Microsoft Entra ID authentication, such as by using an API key.  The following configurations aren't currently supported: -- Policies targeting all users don't include agent's user accounts.-- Scoping a Conditional Access policy to include or exclude agent's user account based on their group membership-- A Conditional Access policy targeting agent identities won't apply to the agent's user account.-- A Conditional Access policy targeting agent identities using agent identity blueprint covers only the agent identity, not the agent's user account.+- Policies that target all users don't include agent user accounts.+- Policies can't include or exclude agent user accounts based on group membership.+- A policy that targets agent identities doesn't apply to agent user accounts.+- A policy that targets agent identities through a blueprint covers only the agent identities, not agent user accounts. -## Next steps+## Related content -- [How to target agent identities in Conditional Access](howto-target-agent-identities.md)-- [Configure policy for autonomous agent access](policy-autonomous-agents.md)+- [Target agent identities in Conditional Access policies](howto-target-agent-identities.md)+- [Secure autonomous agents with Conditional Access](policy-autonomous-agents.md)+- [Secure agents that act as users with Conditional Access](policy-agent-user.md)