Secure autonomous agents with Microsoft Entra Conditional Access
In brief
The article now focuses on Conditional Access for agents using their own identities, adds prerequisites, clarifies that policies target agent identities rather than users, and recommends report-only block policies for unapproved agents.
What Entra admins need to know
Administrators should use the updated licensing, role, registration, and OAuth prerequisites when configuring agent policies.
This editorial summary was generated by AI from the documentation changes. Verify important details in the full Microsoft Learn article.
Documentation change
The comparison below shows only the changed extract. Use the full-page view for complete context.
Recommended policies forSecure autonomous agents with Microsoft Entra Conditional Access
Use this guide to configure Conditional Access to control access for autonomous agents that authenticate with their own identity, withagent identity and no signed-in user. The access pattern is known client credentials flow. Instead of acting on behalf of a user, the agent authenticates with its own credentials - a client ID paired with a certificate or managed identity managed by the agent identity blueprint. This access pattern applies in the following scenarios:
Autonomousincludes agents thatoperate independently:These agentsrun in the background,respondingrespond to events,orrun on aschedule. A typical example is an agent that generates a daily report and sends the result to a group of employees. In this scenario, there is no user present, and the agent operates on its own.
Agents that don't always act on a user's behalf:Sometimes agents operate entirely on their own. For example, a backend SMS service that is not accessible to users. In this scenario, the OBO flow is not applicable and agent accesses the target resource by authenticating directly with its own identity.
Agentsschedule, or are publishedon the webfor public use:These agents either don’t authenticate thewithout delegated useror don’t support delegating the user’s context to downstream resources.
In those scenarios,this access pattern, the agent is the one who requests access, and the issued access token's subject is the agent identity rather than the user. As a result, the Conditional Access policy scope applies to the agent identity, not a user.
Allow only specific agents to access resources
There are two key business scenarios whereidentity. Conditional Access policies can helptherefore target the agent identity, not a user or an agent's user account.
Before you manage agents effectively. Instart, review the first scenariolicensing, role, and agent setup requirements.
Prerequisites
- A Microsoft Entra ID P1 or P2 license.
- At least the Conditional Access Administrator role.
- At least one agent identity registered in your tenant.
- The agent uses the autonomous app OAuth flow.
Allow only approved agentsagent identities
Create a block policy that excludes approved agent identities or agent identity blueprints. Start in report-only mode so you can access resources. You can do this by tagging agents and resources with custom security attributes targeted in your policy, or by manually selecting them usingreview the enhanced object picker.
Use the enhanced object picker
Create Conditional Access policy using the enhanced object picker
Alternatively, organizations can create a Conditional Access policy using the enhanced object picker to block all agents except those reviewed and approved by your organization.
The enhanced object picker replaces the previous flat list experience in both the assignment and target resources sections of policy configuration. The new experience is meant to simplify the selection of items's effect before you want to scope in the policy.enforce it.
- Sign in to the Microsoft Entra admin center as at least a
Conditional Access Administrator.Conditional Access Administrator. - Browse to Entra ID > Conditional Access > Policies.
- Select New policy.
Give your policyEnter aname. Create a meaningful standardname for thenames of your policies.policy.- Under Assignments, select Users, agents or workload identities.
- Under What does this policy apply to?, select Agents.
- Under Include, select All agent identities.
- Under Exclude
:Select, select Select individual agent identities.UsingIn theenhancedobject picker,switch betweenuse thetabsAll, Agent blueprint principals, and Agent identities tabs to select theindividual agent blueprints and/orapproved agent identitiesapproved for use in your environment.or blueprints.- Select Select.
Under> Include, select All resources (formerly 'All cloud apps').
Select, select Block.Select, and then select Select.
[!INCLUDE conditional-access-report-only-mode]
Use custom security attributes
Create Conditional Access policy
For more information about assignment options and the object picker, see Target agent identities in Conditional Access policies.
Allow approved agents by using custom security attributes
Use custom security attributes when you need to manage approved agents and resources at scale. The recommended approach forfollowing example blocks agents from resources unless the first scenario is to createagent has the HR_Approved value.
Create and assign custom security attributes to each
Create attributes for agent or agent blueprint,approval status and resource departments, and then target those attributes with a Conditional Access policy. This approach uses steps similar to those documented in Filter for applications in Conditional Access policy. You can assign attributes across multiple attribute sets to an agent or cloud application.the appropriate values.
Create and assign custom attributes
Create the custom security attributes:- Create an
Attributeattribute set named AgentAttributes. - Create
New attributesan attribute named AgentApprovalStatusthatAllow. - Configure the attribute to allow multiple values
to be assignedandOnly allowonly predefinedvalues to be assigned.- values.
- Add the
followingpredefinedvalues:values New, In_Review, HR_Approved, Finance_Approved, and IT_Approved.
- Create an
- Create an
Attributeattribute set named ResourceAttributes. - Create
New attributesan attribute named DepartmentthatAllow. - Configure the attribute to allow multiple values
to be assignedandOnly allowonly predefinedvalues to be assigned.- values.
- Add the
followingpredefinedvalues:values Finance, HR, IT, Marketing, and Sales.
For more information about custom security attributes, see Custom security attributes in Microsoft Entra ID.
Create the Conditional Access policy
After you completeCreate a block policy that excludes agents with the previous steps, create a Conditional Access policy usingapproved custom security attributes to block all agents except those reviewed and approved by your organization. attribute value.
- Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator and Attribute Assignment Reader.
- Browse to Entra ID > Conditional Access > Policies.
- Select New policy.
Give your policyEnter aname. Create a meaningful standardname for thenames of your policies.policy.- Under Assignments, select Users, agents or workload identities.
- Under What does this policy apply to?, select Agents.
- Under Include, select All agent identities.
- Under Exclude
:Select, select Select agent identities based on attributes.- Set Configure to Yes.
- Select the
Attribute we created earlier calledAgentApprovalStatus.attribute. - Set Operator to Contains.
- Set Value to HR_Approved
. Select, and then select Done.
Under> Include, select All resources (formerly 'All cloud apps').
Select, select Block.Select, and then select Select.
[!INCLUDE conditional-access-report-only-mode]
Block high-risk agentsagent identities
Create a policy that blocks high-risk agent identities from accessing organizational resources
In the second scenario, organizations can create a Conditional Access policy to block high-resources. Agent risk agents based on signals from Microsoft Entra ID Protection. For details on risk detection types and response actions for agents, see Identity Protection for agents.
The following steps create a Conditional Access policy to block all high-risk agents from accessing your organization's resources.is in Preview.
- Sign in to the Microsoft Entra admin center as at least a
Conditional Access Administrator.Conditional Access Administrator. - Browse to Entra ID > Conditional Access > Policies.
- Select New policy.
Give your policyEnter aname. Create a meaningful standardname for thenames of your policies.policy.- Under Assignments, select Users, agents or workload identities.
- Under What does this policy apply to?, select Agents.
- Under Include, select All agent identities.
Under> Include, select All resources (formerly 'All cloud apps').
Select, select Block.Select, and then select Select.
[!INCLUDE conditional-access-report-only-mode]
For details about agent risk detections, see Microsoft Entra ID Protection and agents.
Policies for autonomous agents'agent user accounts
Some autonomous agents can operate like users with their own mailboxes, group memberships, and enterprise identities. These agents use an agent's user account instead of (or in addition to) an agent identity.
Conditional Access extendsAgent-user policy enforcementguidance moved to these user-like autonomous agents. Administrators can:Secure agents that act as users with Microsoft Entra Conditional Access. The article includes the following policies:
Target all agent users or select specific agent usersBlock risky agent user accountsApply policies using custom security attributesRequire a compliant deviceApply agent risk conditions to block risky agentsUse the agent execution environments condition to scope policies to agents running on endpointsEnforce device compliance for agents running on managed endpoints (Windows 365 Cloud PCs)Enforce compliant network locations for agents with a Global Secure Access clientRequire a compliant network
To create a Conditional Access policy for agents operating with their own identity, use the following settings:
Assignments: In an agent access flow, the access token is issued to the agent identity (the token subject), so you assign the policy to agents or their agent identity blueprint.Target resources: Select the resources the agent needs to access.Conditions: Configure whether the agent is at risk. For more information, see ID Protection for agents.Access control: Because this agent accesses resources with its own identity, there's no remediation and the only available option is blocking access.
Block risky agents' user accounts
This policy blocks autonomous agents operating as users when Microsoft Entra ID Protection detects medium or high risk.
Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.Browse toEntra ID>Conditional Access>Policies.SelectNew policy.Give your policy a name. Create a meaningful standard for the names of your policies.UnderAssignments, selectUsers, agents or workload identities.UnderWhat does this policy apply to?, selectAgents.UnderInclude, selectAll agent users (Preview).
UnderTarget resources:UnderInclude, selectAll resources (formerly 'All cloud apps').
UnderConditions>Agent risk (Preview), setConfiguretoYes.UnderConfigure agent risk levels needed for policy to be enforced, selectMediumandHigh.
UnderAccess controls>Grant.SelectBlock.SelectSelect.
Confirm your settings and setEnable policytoReport-only.SelectCreateto enable your policy.
Require a compliant device for agents' user accounts
Some autonomous agents are computer-using agents. These agents operate a desktop environment to complete tasks, similar to how a human user interacts with applications. They typically run on dedicated Windows 365 Cloud PCs for Agents, which are Intune-managed Windows devices. Because the Cloud PC is a managed endpoint, its compliance status can be evaluated by Conditional Access just like an employee's laptop.
However, not all agents run on endpoints. Agents running directly in Microsoft infrastructure don't have an associated device. Policies scoped with this condition don't apply to those cloud-native agents, which prevents unintended blocking.
The Agent execution environments (Preview) condition solves this by restricting the policy to only apply when the agent user session is initiated from an endpoint. Cloud-native agents without a device are excluded from evaluation entirely.
UnderWhat does this policy apply to?, selectAgents.UnderInclude, selectAll agent users (Preview).
UnderInclude, selectAll resources (formerly 'All cloud apps').
UnderInclude, selectAgent user sessions initiated from endpoints.
SelectGrant access.SelectRequire device to be marked as compliant.SelectSelect.
[!INCLUDE conditional-access-report-only-mode]
Require a compliant network for agents' user accounts
Similar to device compliance, you can require agents running on endpoints to connect through a compliant network using Global Secure Access. The Global Secure Access client installed on the endpoint provides the network location signal that Conditional Access evaluates.
Use the Agent execution environments (Preview) condition to scope this policy to endpoint-based sessions only. Without this condition, cloud-native agents without a Global Secure Access client are blocked with no path to compliance.
Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.Browse toEntra ID>Conditional Access>Policies.SelectNew policy.Give your policy a name. Create a meaningful standard for the names of your policies.UnderAssignments, selectUsers, agents or workload identities.UnderWhat does this policy apply to?, selectAgents.UnderInclude, selectAll agent users (Preview).
UnderTarget resources:UnderInclude, selectAll resources (formerly 'All cloud apps').
UnderConditions>Agent execution environments (Preview), setConfiguretoYes.UnderInclude, selectAgent user sessions initiated from endpoints.
UnderAccess controls>Grant.SelectGrant access.SelectRequire compliant network.SelectSelect.
Confirm your settings and setEnable policytoReport-only.SelectCreateto enable your policy.
[!INCLUDE conditional-access-report-only-mode]
Related content
Manage agent identities in your organization - Overview of agent management across the full lifecycle.- Conditional Access for agents
Conditional Access template policiesConditional Access: Users, groups, agents, and workload identitiesConditional Access: Target resourcesConditional Access: ConditionsConditional Access: GrantSecurity for AI with Microsoft Entra agent identityMicrosoft Entra ID Protection and agents\ No newline at end of file- Target agent identities in Conditional Access policies
- Secure agents that act as users with Microsoft Entra Conditional Access
@@ -1,240 +1,140 @@ ----title: Recommended policies for autonomous agents in Microsoft Entra-description: Learn how to configure Conditional Access for autonomous agents in Microsoft Entra ID, extending Zero Trust principles to AI agents.+title: Secure autonomous agents with Microsoft Entra Conditional Access+description: Learn how to configure Microsoft Entra Conditional Access policies for autonomous agents that access resources with their own agent identities.+author: gracenagy+ms.author: gracenagy+ms.service: entra-id ms.topic: how-to-ms.date: 06/02/2026+ms.date: 07/31/2026 ms.reviewer: 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 control which autonomous agents can access resources so that only approved agents can reach organizational data and services. ----# Recommended policies for autonomous agents -Use this guide to configure Conditional Access for agents that authenticate with their own identity, with no signed-in user. The access pattern is known **client credentials flow**. Instead of acting on behalf of a user, the agent authenticates with its own credentials - a client ID paired with a certificate or managed identity managed by the agent identity blueprint. This access pattern applies in the following scenarios:+# Secure autonomous agents with Microsoft Entra Conditional Access -- **Autonomous agents that operate independently**:- - These agents run in the background, responding to events, or run on a schedule. A typical example is an agent that generates a daily report and sends the result to a group of employees. In this scenario, there is no user present, and the agent operates on its own. -- **Agents that don't always act on a user's behalf**:- - Sometimes agents operate entirely on their own. For example, a backend SMS service that is not accessible to users. In this scenario, the OBO flow is not applicable and agent accesses the target resource by authenticating directly with its own identity. -- **Agents published on the web for public use**:- - These agents either don’t authenticate the user or don’t support delegating the user’s context to downstream resources.+Use Conditional Access to control access for autonomous agents that authenticate with their own agent identity and no signed-in user. This access pattern includes agents that run in the background, respond to events, run on a schedule, or are published for public use without delegated user context. -In those scenarios, the agent is the one who requests access, and the issued access token's subject is the [agent identity](/entra/agent-id/what-are-agent-identities) rather than the user. As a result, the Conditional Access policy scope applies to the **agent identity**, not a user. +In this access pattern, the access token's subject is the agent identity. Conditional Access policies therefore target the agent identity, not a user or an agent's user account. -> [!IMPORTANT]-> Before configuring a Conditional Access policy, read the [Conditional Access for agents](agent-id.md) article. It covers the authentication flow, service boundaries, and limitations to ensure you cover all scenarios and your corporate data and services are well protected.+Before you start, review the licensing, role, and agent setup requirements. -## Allow only specific agents to access resources+## Prerequisites -There are two key business scenarios where Conditional Access policies can help you manage agents effectively. In the first scenario you might want to ensure that only approved agents can access resources. You can do this by tagging agents and resources with [custom security attributes](/entra/fundamentals/custom-security-attributes-overview) targeted in your policy, or by manually selecting them using the enhanced object picker.+- A Microsoft Entra ID P1 or P2 license.+- At least the [Conditional Access Administrator](../role-based-access-control/permissions-reference.md#conditional-access-administrator) role.+- At least one agent identity registered in your tenant.+- The agent uses the [autonomous app OAuth flow](../../agent-id/agent-autonomous-app-oauth-flow.md). -### [Use the enhanced object picker](#tab/use-the-enhanced-object-picker)+> [!IMPORTANT]+> Review [Conditional Access for agents](agent-id.md) before you create a policy. A policy that targets an agent identity doesn't apply to an agent's user account. -### Create Conditional Access policy using the enhanced object picker+<a name='allow-only-specific-agents-to-access-resources'></a> -Alternatively, organizations can create a Conditional Access policy using the enhanced object picker to block all agents except those reviewed and approved by your organization. +## Allow only approved agent identities -The enhanced object picker replaces the previous flat list experience in both the assignment and target resources sections of policy configuration. The new experience is meant to simplify the selection of items you want to scope in the policy.+Create a block policy that excludes approved agent identities or agent identity blueprints. Start in report-only mode so you can review the policy's effect before you enforce it. -1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Conditional Access Administrator](../role-based-access-control/permissions-reference.md#conditional-access-administrator).+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a Conditional Access Administrator. 1. Browse to **Entra ID** > **Conditional Access** > **Policies**. 1. Select **New policy**.-1. Give your policy a name. Create a meaningful standard for the names of your policies.-1. Under **Assignments**, select **Users, agents or workload identities**. - 1. Under **What does this policy apply to?**, select **Agents**.- 1. Under **Include**, select **All agent identities**.- 1. Under **Exclude**: - 1. Select **Select individual agent identities**.- 1. Using the enhanced object picker, switch between the tabs **All**, **Agent blueprint principals**, and **Agent identities** to select the individual agent blueprints and/or agent identities approved for use in your environment.- 1. Select **Select**.-1. Under **Target resources**:- 1. Under **Include**, select **All resources (formerly 'All cloud apps')**.-1. Under **Access controls** > **Grant**: - 1. Select **Block**.- 1. Select **Select**.-1. Confirm your settings and set **Enable policy** to **Report-only**.-1. Select **Create** to create your policy.+1. Enter a name for the policy.+1. Under **Assignments**, select **Users, agents or workload identities**.+1. Under **What does this policy apply to?**, select **Agents**.+1. Under **Include**, select **All agent identities**.+1. Under **Exclude**, select **Select individual agent identities**.+1. In the object picker, use the **All**, **Agent blueprint principals**, and **Agent identities** tabs to select the approved agent identities or blueprints.+1. Select **Select**.+1. Under **Target resources** > **Include**, select **All resources (formerly 'All cloud apps')**.+1. Under **Access controls** > **Grant**, select **Block**, and then select **Select**.+1. Set **Enable policy** to **Report-only**.+1. Select **Create**. [!INCLUDE [conditional-access-report-only-mode](../../includes/conditional-access-report-only-mode.md)] -### [Use custom security attributes](#tab/use-custom-security-attributes)+For more information about assignment options and the object picker, see [Target agent identities in Conditional Access policies](howto-target-agent-identities.md). -### Create Conditional Access policy using custom security attributes+## Allow approved agents by using custom security attributes -The recommended approach for the first scenario is to create and assign custom security attributes to each agent or agent blueprint, then target those attributes with a Conditional Access policy. This approach uses steps similar to those documented in [Filter for applications in Conditional Access policy](concept-filter-for-applications.md). You can assign attributes across multiple attribute sets to an agent or cloud application.+Use custom security attributes when you need to manage approved agents and resources at scale. The following example blocks agents from resources unless the agent has the `HR_Approved` value. -#### Create and assign custom attributes+### Create and assign custom security attributes -1. Create the custom security attributes:- 1. Create an **Attribute set** named *AgentAttributes*.- 1. Create **New attributes** named *AgentApprovalStatus* that **Allow multiple values to be assigned** and **Only allow predefined values to be assigned**. - 1. Add the following predefined values: **New**, **In_Review**, **HR_Approved**, **Finance_Approved**, **IT_Approved**.-1. Create another attribute set to group resources that your agents are allowed to access.- 1. Create an **Attribute set** named *ResourceAttributes*.- 1. Create **New attributes** named *Department* that **Allow multiple values to be assigned** and **Only allow predefined values to be assigned**.- 1. Add the following predefined values: **Finance**, **HR**, **IT**, **Marketing**, **Sales**.-1. Assign the appropriate value to resources that your agent is allowed to access. For example, you might want only agents that are **HR_Approved** to be able to access resources that are tagged **HR**.+Create attributes for agent approval status and resource departments, and then assign the appropriate values. -#### Create Conditional Access policy+1. Create an attribute set named *AgentAttributes*.+1. Create an attribute named *AgentApprovalStatus*.+1. Configure the attribute to allow multiple values and only predefined values.+1. Add the predefined values **New**, **In_Review**, **HR_Approved**, **Finance_Approved**, and **IT_Approved**.+1. Create an attribute set named *ResourceAttributes*.+1. Create an attribute named *Department*.+1. Configure the attribute to allow multiple values and only predefined values.+1. Add the predefined values **Finance**, **HR**, **IT**, **Marketing**, and **Sales**.+1. Assign the appropriate value to each agent or agent blueprint and resource. -After you complete the previous steps, create a Conditional Access policy using custom security attributes to block all agents except those reviewed and approved by your organization. +For more information about custom security attributes, see [Custom security attributes in Microsoft Entra ID](../../fundamentals/custom-security-attributes-overview.md). -1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Conditional Access Administrator](../role-based-access-control/permissions-reference.md#conditional-access-administrator) and [Attribute Assignment Reader](../role-based-access-control/permissions-reference.md#attribute-assignment-reader).-1. Browse to **Entra ID** > **Conditional Access** > **Policies**.-1. Select **New policy**.-1. Give your policy a name. Create a meaningful standard for the names of your policies.-1. Under **Assignments**, select **Users, agents or workload identities**. - 1. Under **What does this policy apply to?**, select **Agents**.- 1. Under **Include**, select **All agent identities**.- 1. Under **Exclude**: - 1. Select **Select agent identities based on attributes**.- 1. Set **Configure** to **Yes**. - 1. Select the Attribute we created earlier called **AgentApprovalStatus**.- 1. Set **Operator** to **Contains**.- 1. Set **Value** to **HR_Approved**.- 1. Select **Done**.-1. Under **Target resources**:- 1. Under **Include**, select **All resources (formerly 'All cloud apps')**.-1. Under **Access controls** > **Grant**: - 1. Select **Block**.- 1. Select **Select**.-1. Confirm your settings and set **Enable policy** to **Report-only**.-1. Select **Create** to create your policy.+### Create the Conditional Access policy -[!INCLUDE [conditional-access-report-only-mode](../../includes/conditional-access-report-only-mode.md)]+Create a block policy that excludes agents with the approved custom security attribute value. ------## Block high-risk agents from accessing organizational resources--In the second scenario, organizations can create a Conditional Access policy to block high-risk agents based on [signals from Microsoft Entra ID Protection](/entra/id-protection/concept-risky-agents). For details on risk detection types and response actions for agents, see [Identity Protection for agents](/entra/id-protection/concept-risky-agents).--The following steps create a Conditional Access policy to block all high-risk agents from accessing your organization's resources.--1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Conditional Access Administrator](../role-based-access-control/permissions-reference.md#conditional-access-administrator).+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Conditional Access Administrator](../role-based-access-control/permissions-reference.md#conditional-access-administrator) and [Attribute Assignment Reader](../role-based-access-control/permissions-reference.md#attribute-assignment-reader). 1. Browse to **Entra ID** > **Conditional Access** > **Policies**. 1. Select **New policy**.-1. Give your policy a name. Create a meaningful standard for the names of your policies.-1. Under **Assignments**, select **Users, agents or workload identities**. - 1. Under **What does this policy apply to?**, select **Agents**.- 1. Under **Include**, select **All agent identities**.-1. Under **Target resources**:- 1. Under **Include**, select **All resources (formerly 'All cloud apps')**.-1. Under **Conditions** > **Agent risk (Preview)**, set **Configure** to **Yes**.- 1. Under **Configure agent risk levels needed for policy to be enforced**, select **High**. This guidance is based on Microsoft recommendations and might be different for each organization.-1. Under **Access controls** > **Grant**. - 1. Select **Block**.- 1. Select **Select**.-1. Confirm your settings and set **Enable policy** to **Report-only**.-1. Select **Create** to enable your policy.+1. Enter a name for the policy.+1. Under **Assignments**, select **Users, agents or workload identities**.+1. Under **What does this policy apply to?**, select **Agents**.+1. Under **Include**, select **All agent identities**.+1. Under **Exclude**, select **Select agent identities based on attributes**.+1. Set **Configure** to **Yes**.+1. Select the **AgentApprovalStatus** attribute.+1. Set **Operator** to **Contains**.+1. Set **Value** to **HR_Approved**, and then select **Done**.+1. Under **Target resources** > **Include**, select **All resources (formerly 'All cloud apps')**.+1. Under **Access controls** > **Grant**, select **Block**, and then select **Select**.+1. Set **Enable policy** to **Report-only**.+1. Select **Create**. [!INCLUDE [conditional-access-report-only-mode](../../includes/conditional-access-report-only-mode.md)] -## Policies for autonomous agents' user accounts--Some autonomous agents can operate like users with their own mailboxes, group memberships, and enterprise identities. These agents use an [agent's user account](../../agent-id/agent-users.md) instead of (or in addition to) an agent identity.+<a name='block-high-risk-agents-from-accessing-organizational-resources'></a> -Conditional Access extends policy enforcement to these user-like autonomous agents. Administrators can:+## Block high-risk agent identities -- Target all agent users or select specific agent users-- Apply policies using custom security attributes-- Apply agent risk conditions to block risky agents-- Use the agent execution environments condition to scope policies to agents running on endpoints-- Enforce device compliance for agents running on managed endpoints (Windows 365 Cloud PCs)-- Enforce compliant network locations for agents with a Global Secure Access client+Create a policy that blocks high-risk agent identities from organizational resources. Agent risk is in Preview. -To create a Conditional Access policy for agents operating with their own identity, use the following settings:--- **Assignments**: In an agent access flow, the access token is issued to the agent identity (the token subject), so you assign the policy to agents or their agent identity blueprint.-- **Target resources**: Select the resources the agent needs to access.-- **Conditions**: Configure whether the agent is at risk. For more information, see [ID Protection for agents](../../id-protection/concept-risky-agents.md).-- **Access control**: Because this agent accesses resources with its own identity, there's no remediation and the only available option is blocking access.--### Block risky agents' user accounts--This policy blocks autonomous agents operating as users when [Microsoft Entra ID Protection](../../id-protection/concept-risky-agents.md) detects medium or high risk.--1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Conditional Access Administrator](../role-based-access-control/permissions-reference.md#conditional-access-administrator).+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a Conditional Access Administrator. 1. Browse to **Entra ID** > **Conditional Access** > **Policies**. 1. Select **New policy**.-1. Give your policy a name. Create a meaningful standard for the names of your policies.+1. Enter a name for the policy. 1. Under **Assignments**, select **Users, agents or workload identities**.- 1. Under **What does this policy apply to?**, select **Agents**.- 1. Under **Include**, select **All agent users (Preview)**.-1. Under **Target resources**:- 1. Under **Include**, select **All resources (formerly 'All cloud apps')**.+1. Under **What does this policy apply to?**, select **Agents**.+1. Under **Include**, select **All agent identities**.+1. Under **Target resources** > **Include**, select **All resources (formerly 'All cloud apps')**. 1. Under **Conditions** > **Agent risk (Preview)**, set **Configure** to **Yes**.- 1. Under **Configure agent risk levels needed for policy to be enforced**, select **Medium** and **High**.-1. Under **Access controls** > **Grant**.- 1. Select **Block**.- 1. Select **Select**.-1. Confirm your settings and set **Enable policy** to **Report-only**.-1. Select **Create** to enable your policy.--### Require a compliant device for agents' user accounts--Some autonomous agents are computer-using agents. These agents operate a desktop environment to complete tasks, similar to how a human user interacts with applications. They typically run on dedicated [Windows 365 Cloud PCs for Agents](/windows-365/agents/introduction-windows-365-for-agents), which are Intune-managed Windows devices. Because the Cloud PC is a managed endpoint, its compliance status can be evaluated by Conditional Access just like an employee's laptop.--However, not all agents run on endpoints. Agents running directly in Microsoft infrastructure don't have an associated device. Policies scoped with this condition don't apply to those cloud-native agents, which prevents unintended blocking.--The **Agent execution environments (Preview)** condition solves this by restricting the policy to only apply when the agent user session is initiated from an endpoint. Cloud-native agents without a device are excluded from evaluation entirely.--> [!NOTE]-> An agent can technically run on any machine. But device compliance checks require Intune enrollment, which today is only supported on Windows 365 Cloud PCs for Agents. Without the **Agent execution environments** condition scoping this policy, agents running in cloud infrastructure are blocked with no path to compliance.--1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Conditional Access Administrator](../role-based-access-control/permissions-reference.md#conditional-access-administrator).-1. Browse to **Entra ID** > **Conditional Access** > **Policies**.-1. Select **New policy**.-1. Give your policy a name. Create a meaningful standard for the names of your policies.-1. Under **Assignments**, select **Users, agents or workload identities**.- 1. Under **What does this policy apply to?**, select **Agents**.- 1. Under **Include**, select **All agent users (Preview)**.-1. Under **Target resources**:- 1. Under **Include**, select **All resources (formerly 'All cloud apps')**.-1. Under **Conditions** > **Agent execution environments (Preview)**, set **Configure** to **Yes**.- 1. Under **Include**, select **Agent user sessions initiated from endpoints**.-1. Under **Access controls** > **Grant**.- 1. Select **Grant access**.- 1. Select **Require device to be marked as compliant**.- 1. Select **Select**.-1. Confirm your settings and set **Enable policy** to **Report-only**.-1. Select **Create** to enable your policy.+1. Select **High**.+1. Under **Access controls** > **Grant**, select **Block**, and then select **Select**.+1. Set **Enable policy** to **Report-only**.+1. Select **Create**. [!INCLUDE [conditional-access-report-only-mode](../../includes/conditional-access-report-only-mode.md)] -### Require a compliant network for agents' user accounts+For details about agent risk detections, see [Microsoft Entra ID Protection and agents](../../id-protection/concept-risky-agents.md). -Similar to device compliance, you can require agents running on endpoints to connect through a compliant network using [Global Secure Access](/entra/global-secure-access/overview-what-is-global-secure-access). The Global Secure Access client installed on the endpoint provides the network location signal that Conditional Access evaluates.+<a name='policies-for-autonomous-agents-user-accounts'></a> -Use the **Agent execution environments (Preview)** condition to scope this policy to endpoint-based sessions only. Without this condition, cloud-native agents without a Global Secure Access client are blocked with no path to compliance.+## Policies for agent user accounts -1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Conditional Access Administrator](../role-based-access-control/permissions-reference.md#conditional-access-administrator).-1. Browse to **Entra ID** > **Conditional Access** > **Policies**.-1. Select **New policy**.-1. Give your policy a name. Create a meaningful standard for the names of your policies.-1. Under **Assignments**, select **Users, agents or workload identities**.- 1. Under **What does this policy apply to?**, select **Agents**.- 1. Under **Include**, select **All agent users (Preview)**.-1. Under **Target resources**:- 1. Under **Include**, select **All resources (formerly 'All cloud apps')**.-1. Under **Conditions** > **Agent execution environments (Preview)**, set **Configure** to **Yes**.- 1. Under **Include**, select **Agent user sessions initiated from endpoints**.-1. Under **Access controls** > **Grant**.- 1. Select **Grant access**.- 1. Select **Require compliant network**.- 1. Select **Select**.-1. Confirm your settings and set **Enable policy** to **Report-only**.-1. Select **Create** to enable your policy.+Agent-user policy guidance moved to [Secure agents that act as users with Microsoft Entra Conditional Access](policy-agent-user.md). The article includes the following policies: -[!INCLUDE [conditional-access-report-only-mode](../../includes/conditional-access-report-only-mode.md)]+- <a name='block-risky-agents-user-accounts'></a>[Block risky agent user accounts](policy-agent-user.md#block-risky-agent-user-accounts)+- <a name='require-a-compliant-device-for-agents-user-accounts'></a>[Require a compliant device](policy-agent-user.md#require-a-compliant-device)+- <a name='require-a-compliant-network-for-agents-user-accounts'></a>[Require a compliant network](policy-agent-user.md#require-a-compliant-network) ## Related content -- [Manage agent identities in your organization](/entra/agent-id/manage-agent-identities-organization) - Overview of agent management across the full lifecycle. - [Conditional Access for agents](agent-id.md)-- [Conditional Access template policies](concept-conditional-access-policy-common.md)-- [Conditional Access: Users, groups, agents, and workload identities](concept-conditional-access-users-groups.md)-- [Conditional Access: Target resources](concept-conditional-access-cloud-apps.md)-- [Conditional Access: Conditions](concept-conditional-access-conditions.md)-- [Conditional Access: Grant](concept-conditional-access-grant.md)-- [Security for AI with Microsoft Entra agent identity](../../agent-id/security-for-ai-overview.md)-- [Microsoft Entra ID Protection and agents](/entra/id-protection/concept-risky-agents)\ No newline at end of file+- [Target agent identities in Conditional Access policies](howto-target-agent-identities.md)+- [Secure agents that act as users with Microsoft Entra Conditional Access](policy-agent-user.md) 