Microsoft Entra Agent ID
Conditional AccessConditional Access for Agents in Microsoft Entra
In brief
The documentation now distinguishes agents acting for signed-in users, using their own identity, or using an agent user account. It adds separate guidance links for autonomous agents and agent users and updates the listed licensing combinations.
What Entra admins need to know
Administrators should identify each agent’s access pattern and review the corresponding policy guidance and licensing requirements.
This editorial summary was generated by AI from the documentation changes. Verify important details in the full Microsoft Learn article.
Documentation change
View on Microsoft LearnThe comparison below shows only the changed extract. Use the full-page view for complete context.
Conditional Access for agents
Conditional Access for agents is an intelligentextension of the Conditional Access policy engine that helps organizations controlcontrols how users and agents access corporate resources.resources protected by Microsoft Entra ID. 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 P1Understanding 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 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.use its own agent user account.
Learn about Conditional Access for agents:
- High-level overview of Conditional Access: What is Conditional Access?
- Guide to managing agent identities across your organization: Manage agent identities in your organization.
- How to target agent identities in Conditional Access
- Secure autonomous agents with Conditional Access
- Secure agent users with Microsoft Entra Conditional Access
Requirements and licensing
Microsoft Entra ID Conditional Access for agents requires one of the following license plans:
- Microsoft 365 E7, which includes Agent 365 and Microsoft Entra Suite.
- Microsoft Agent 365 license paired with at least Microsoft Entra P1 or Microsoft 365 E3.
For more information, see Microsoft Agent 365 plans and pricing.
How Conditional Access evaluates agent access requests
To access a corporate resource such as a SharePoint file, MCP servers,server, or Open API services,service, 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 issuingit issues the token. If the requirements are satisfied, an access token is issued.Microsoft Entra ID issues the token. The token is then presented to the target resource, whichresource validates the token and uses its claims to make authorization decisions.
The following diagram illustrates this process.
:::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":::
How subjects and audiences are used
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.audience:
- Subject: The identity
receivingthat receives the token.- In delegated
access scenarios,access, the token represents the user while also identifying the calling application or agent. - In application-only
scenarios,access, theapplication or autonomousagent identity is the subject. - In
agent'sagent-useraccount scenarios,access, the agent's user account is the subject.
- In delegated
- Audience: The target resource that the token is
intended for.The resourcefor, which must be registered inMicrosoftEntra ID.- If a subject
needs to accessaccesses multipleresources (for example, multiple MCP servers or APIs),resources, it typicallyrequiresneeds a separateaccesstoken for eachresource, each with its own audience and permissions.resource.
Conditional Access
policies are evaluated based onevaluates both the subjectrequestingthat 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.How Conditional Access decisions are made
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.
Agent access patterns
Agents can access Microsoft Entra-protected resources using one of the following patterns:
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 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 Accesses resources through its own user account Agent-user access Agent's user account Secure agents that act as users with Conditional Access 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
actingthat act on behalf of a userThe most common access pattern is the on-behalf-of (OBO) flow. In
thisthe OBO flow, a user signs in to an agentapplication, and theapplication. The agent accesses downstream resourcesusingwith 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.Because the user is the subject in this flow, Conditional Access policies target users and groups, not agent identities.
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.
- 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.
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 Secure autonomous agents with Conditional Access.
Agents
actingthat act asa userusersSometimes 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 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.
Agents running on managed endpoints like Windows 365 Cloud PCs 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.
Conditional Access policies and agent identity blueprints
In addition to the specific agent access patterns, you can also select agent identity blueprints to apply Conditional Access policies to a class of agents.
EveryAn agent identityis derived from an agent identity blueprint, whichblueprint definesitsthe configuration and governancemodel. Applyingmodel for agent identities created from it. A policy that targets apolicy at theblueprintlevel automatically coversapplies to all agent identitiesderivedcreated fromit,that blueprint, includingany new ones added in the future. Targeting theagentidentity blueprint does not cover agents' user accounts.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.
:::image type="content" source="media/agent-id/conditional-access-agent-identity-blueprint-diagram.png" alt-text="Diagram showing
thea Conditional Accessflow forpolicy applied to agentidentity blueprints.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.
:::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":::
For a
full walkthrough on creating custom security attributes and using them in a Conditional Access policy,policy example, seeConditional Access for autonomous agentsAllow approved agents by using custom security attributes.Conditional Access boundariesBoundaries and limitationsConditional Access policies don't apply when:
- 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.
Next stepsRelated content
@@ -1,53 +1,56 @@ --- 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.+description: Learn how Conditional Access for agents in Microsoft Entra ID extends Zero Trust principles to AI agents, ensuring secure access and governance. 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 is an extension of the Conditional Access policy engine that controls how agents access resources protected by Microsoft Entra ID. It brings together real-time signals such as user's and agent's context, device, location, and 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).+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. Learn about Conditional Access for agents: - 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)+- [Secure autonomous agents with Conditional Access](policy-autonomous-agents.md)+- [Secure agent users with Microsoft Entra Conditional Access](policy-agent-user.md)+## Requirements and licensing -## How Conditional Access evaluates agent access requests+Microsoft Entra ID Conditional Access for agents requires one of the following license plans:+- **Microsoft 365 E7**, which includes Agent 365 and Microsoft Entra Suite.+- **Microsoft Agent 365** license paired with at least Microsoft Entra P1 or Microsoft 365 E3. -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.+For more information, see [Microsoft Agent 365 plans and pricing](https://www.microsoft.com/microsoft-agent-365#plans-and-pricing). -The following diagram illustrates this process.+<a name='how-conditional-access-evaluates-agent-access-requests'></a> -:::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":::--### How subjects and audiences are used+## How Conditional Access evaluates agent access -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.+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. -**Subject**: The identity receiving the token.+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. -- 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.+:::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"::: -**Audience**: The target resource the token is intended for.+Each access token has one subject and one audience: -- 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.+- **Subject**: The identity that receives the token. + - In delegated access, the token represents the user while also identifying the calling application or agent.+ - In application-only access, the agent identity is the subject. + - In agent-user access, the agent's user account is the subject.+- **Audience**: The target resource that the token is for, which must be registered in Entra ID. If a subject accesses multiple resources, it typically needs a separate token for each resource. -Conditional Access policies are evaluated based on both the subject requesting access and the audience being accessed.+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. ### How Conditional Access decisions are made @@ -63,13 +66,26 @@ For example, an organization may require multifactor authentication before a use 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. ++<a name='agent-access-patterns'></a>+ ## Agent access patterns Agents can access Microsoft Entra-protected resources using one of the following patterns: -### Agents acting on behalf of a user+| 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) |++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. -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).+<a name='agents-acting-on-behalf-of-a-user'></a>++### Agents that act on behalf of a user++The most common access pattern is the on-behalf-of (OBO) flow. 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. 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). > [!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.@@ -78,7 +94,9 @@ In this flow, the agent can't reuse the user's original token because it was iss Because the user is the subject in this flow, Conditional Access policies target **users and groups**, not agent identities. -### Agents acting as an application+<a name='agents-acting-as-an-application'></a>++### 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). @@ -91,9 +109,11 @@ This flow applies in the following common scenarios: - 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. -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).+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 [Secure autonomous agents with Conditional Access](policy-autonomous-agents.md). -### Agents acting as a user+<a name='agents-acting-as-a-user'></a>++### 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. @@ -103,13 +123,15 @@ Agents using this flow are also considered autonomous agents as they don't invol 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 -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.+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. 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. -:::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. @@ -119,9 +141,9 @@ As the number of agent identities grows, individually managing each one across e :::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"::: -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#use-custom-security-attributes). -## Conditional Access boundaries and limitations+## Boundaries and limitations Conditional Access policies don't apply when: @@ -141,7 +163,8 @@ The following configurations aren't currently supported: - 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. -## 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)