Edit

Conditional Access 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:

  • 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.

In those scenarios, 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.

Important

Before configuring a Conditional Access policy, read the Conditional Access for agent identities 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.

Allow only specific agents to access resources

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 targeted in your policy, or by manually selecting them using the enhanced object picker.

Create Conditional Access policy 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. You can assign attributes across multiple attribute sets to an agent or cloud application.

Create and assign custom attributes

  1. Create the custom security attributes:
    1. Create an Attribute set named AgentAttributes.
    2. 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.
  2. Create another attribute set to group resources that your agents are allowed to access.
    1. Create an Attribute set named ResourceAttributes.
    2. 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.
  3. 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 Conditional Access policy

After you complete the previous steps, create a Conditional Access policy using custom security attributes to block all agent identities except those reviewed and approved by your organization.

  1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator and Attribute Assignment Reader.
  2. Browse to Entra ID > Conditional Access > Policies.
  3. Select New policy.
  4. Give your policy a name. Create a meaningful standard for the names of your policies.
  5. Under Assignments, select Users, agents (Preview) or workload identities.
    1. Under What does this policy apply to?, select Agents (Preview).
      1. Under Include, select All agent identities (Preview).
      2. Under Exclude:
        1. Select Select agent identities based on attributes.
        2. Set Configure to Yes.
        3. Select the Attribute we created earlier called AgentApprovalStatus.
        4. Set Operator to Contains.
        5. Set Value to HR_Approved.
        6. Select Done.
  6. Under Target resources, select the following options:
    1. Select what this policy applies to Resources (formerly cloud apps).
      1. Include All resources (formerly 'All cloud apps')
  7. Under Access controls > Grant:
    1. Select Block.
    2. Select Select.
  8. Confirm your settings and set Enable policy to Report-only.
  9. Select Create to create your policy.

After confirming your settings using policy impact or report-only mode, move the Enable policy toggle from Report-only to On.

Block high-risk agent identities from accessing organizational resources

In the second scenario, organizations can create a Conditional Access policy to block high-risk agent identities 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 agent identities from accessing your organization's resources.

  1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
  2. Browse to Entra ID > Conditional Access > Policies.
  3. Select New policy.
  4. Give your policy a name. Create a meaningful standard for the names of your policies.
  5. Under Assignments, select Users, agents (Preview) or workload identities.
    1. Under What does this policy apply to?, select Agents (Preview).
      1. Under Include, select All agent identities (Preview).
  6. Under Target resources, select the following options:
    1. Select what this policy applies to Resources (formerly cloud apps).
    2. Include, All resources (formerly 'All cloud apps').
  7. 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.
  8. Under Access controls > Grant.
    1. Select Block.
    2. Select Select.
  9. Confirm your settings and set Enable policy to Report-only.
  10. Select Create to enable your policy.

After confirming your settings using policy impact or report-only mode, move the Enable policy toggle from Report-only to On.

Investigating policy evaluation using sign-in logs

Admins can use the Sign-in logs to investigate why a Conditional Access policy did or didn't apply as explained in Microsoft Entra sign-in events. These events appear in the Service principal sign-ins. You can also filter by Agent type is agent identity.