Microsoft Entra Agent ID
Conditional AccessConditional Access for Agents in Microsoft Entra
In brief
The overview now explains policy decisions, evaluation timing, token subjects and audiences, and supported agent access patterns. It also adds links to related identity-management and policy guidance.
What Entra admins need to know
Administrators have clearer guidance for selecting policy targets and securing different agent access patterns.
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.
Microsoft Entra Conditional Access for agents overview
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 tokenbrings together real-time signals such as user's and the resource that the token is for.agent's context, device, location, and session risk information to determine when to allow, block, or limit access, or require more verification steps.
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?
- 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
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.
Each access token has one subject and one audience:
- Subject: The identity that receives the token.
- In delegated access, the token represents the user
and identifieswhile also identifying 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.
- In delegated access, the token represents the user
- Audience: The target resource that the token is
for.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 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
Conditional Access policies operate as if-then statements:
- 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.
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.
When Conditional Access is evaluated
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.
Choose an agentAgent access patternpatterns
Choose theAgents can access pattern based on the subjectMicrosoft Entra-protected resources using one of the token, not the platform where the agent was built.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 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.
The For example, when an agent can't reusereads your emails, it accesses your mailbox on your behalf. For more information about how 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.
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.works for agents, see Agent OAuth flows: On-behalf-of.
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 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 application-only access, anthis case the agent accesses resourcesthe resource with its own agent identity and no signed-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.
This flow applies in user. This access pattern applies to agents that:the following common scenarios:
RunAutonomous 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.
UseIn this scenario, there's no user present, and the agent operates on its own.
- Interactive agents that use their own identity
fordon'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
candon'taccess.have access to, the OBO flow doesn't apply, and the agent authenticates directly as itself.
- For example, if an agent calls a backend SMS service that users
AreAgents published on the web for public usewithout delegateddon't authenticate the usercontext.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.identity (not the user). Therefore, Conditional Access policies therefore targetare scoped to the agent identity or its agent identity blueprint.rather than the user. For step-by-step policy examples,configuration, see Secure autonomous agents with Conditional Access.
Agents that act as users
An agent user account letsSometimes it's not enough for an agent haveto 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, orand the ability to participate in collaborative workflows as a team member. An administrator
In this model, an admin creates thea 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.
TheAgents 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. Conditional Access policies therefore targetaccount (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. For more information about the agent user OAuth flow, see Agent user OAuth flow.
Agents that runrunning on managed endpoints such as Windows 365 Cloud PCs for Agentslike Windows 365 Cloud PCs for Agents can usealso be subject to device compliance and compliant network controls. TheUse the Agent execution environments (Preview) condition limitsto scope these policies to endpoint-based sessions.sessions only. For policy examples,more information, see Secure agents that act as users with Conditional AccessRequire a compliant device for agents' user accounts.
AgentConditional 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. 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.
Targeting anThe following diagram shows that only agent identityidentities associated with blueprint doesn't cover agent user accounts."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 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 in one project might operate independently or work together.(A2A) to complete tasks. If they come from're all created under the same blueprint, onea single policy on theapplied to that blueprint can applyenforces consistent access controls across the entire collection.
Attribute-driven Conditional Access
Custom security attributesAs the number of agent identities grows, individually managing each one across every policy becomes unsustainable. Custom security attributes let you categorize agent identities and resources with business-specific labels. Conditional Access policies canlabels, then target those attributes instead of individual objects.
in Conditional Access policies. Policies based on custom security attributesautomatically apply to every agent with matching agent identities,attributes, including matching identities created later.ones added in the future.
:::image type="content" source="media/agent-id/conditional-access-agent-diagram.png" alt-text="Diagram showing the Conditional Access applied toflow for agent identities by using custom security attributes.identities." lightbox="media/agent-id/conditional-access-agent-diagram.png":::
For a policy example, see Allow approved agents by using custom security attributes.
Boundaries and limitations
Conditional Access policies don't apply in these cases:when:
- An agent identity blueprint
getsacquires 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.resources and are only involved in creating agent identities and agents' user accounts. - Agent
identities performtasks are always performed by the agenttasks.identity.
- Agent blueprints have limited functionality. They can't act independently to access
- An agent identity blueprint or agent identity performs an intermediate token exchange at the
AAD Token Exchange Endpoint: Publicendpointwith resource ID(Resource ID:fb60f99c-7a34-4190-8149-302f77469936).- Tokens
for this endpointscoped to theAAD Token Exchange Endpoint: Publiccan't call Microsoft Graph. Security defaultsAgent flows are protected because Conditional Access protects token acquisition from the agent identity or agent's user account.
- Tokens
- Security defaults are enabled.
AnConditional Access only protects resources secured by Microsoft Entra ID. For example, if an agent accessesa resource withoutresources using an API key, it bypasses the Microsoft Entra IDauthentication, such as by using an API key.authentication and token issuance pipeline entirely and Conditional Access policies won't apply to them.
The following configurations aren't currently supported:
- Policies
that targettargeting all users don't include agent's user accounts. Policies can'tScoping a Conditional Access policy to include or exclude agent's useraccountsaccount based on their groupmembership.membership- A Conditional Access policy
that targetstargeting agent identitiesdoesnwon't apply to the agent's useraccounts.account. - A Conditional Access policy
that targetstargeting agent identitiesthrough ausing agent identity blueprint covers only the agentidentities,identity, not the agent's useraccounts.account.
Related content
@@ -1,6 +1,6 @@ ----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.+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. Choose the right policy guidance for each agent access pattern. author: gracenagy ms.author: gracenagy ms.service: entra-id@@ -9,16 +9,21 @@ ms.date: 07/31/2026 ms.reviewer: yoelhor, kvenkit ms.custom: msecd-doc-authoring-1017 ai-usage: ai-assisted--#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. --- -# Microsoft Entra Conditional Access for agents overview+# Conditional Access for agents -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.+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 session risk information to determine when to allow, block, or limit access, or require more verification steps. 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)+- [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 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.@@ -37,94 +42,124 @@ When a Conditional Access policy applies, Microsoft Entra ID evaluates the polic Each access token has one subject and one audience: -- **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.+- **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 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, which must be registered in Entra ID. If a subject accesses multiple resources, it typically needs a separate token for each resource. 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++Conditional Access policies operate as if-then statements:++- 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.++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.++### When Conditional Access is evaluated++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> -## Choose an agent access pattern+## Agent access patterns -Choose the access pattern based on the subject of the token, not the platform where the agent was built.+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](../../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) |+| 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. <a name='agents-acting-on-behalf-of-a-user'></a> -## Agents that act 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 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). -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 that act as applications+### Agents that act as applications -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:+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). -- 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.+This flow applies in the following common scenarios: -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).+- **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.++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). <a name='agents-acting-as-a-user'></a> -## Agents that act as users+### 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> -## Agent identity blueprints+## Conditional Access policies and agent identity blueprints -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.+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. -Targeting an agent identity blueprint doesn't cover agent user accounts.+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 a Conditional Access policy applied to agent identities from one blueprint." lightbox="media/agent-id/conditional-access-agent-identity-blueprint-diagram.png"::: -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.+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. ## Attribute-driven Conditional Access -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.+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. -:::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":::+:::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 policy example, see [Allow approved agents by using custom security attributes](policy-autonomous-agents.md#allow-approved-agents-by-using-custom-security-attributes). ## Boundaries and limitations -Conditional Access policies don't apply in these cases:+Conditional Access policies don't apply when: -- 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.+- 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. The following configurations aren't currently supported: -- 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.+- 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. ## Related content