Edit

Share via

Conditional Access for Agent ID (Preview)

Conditional Access for Agent ID is a new capability in Microsoft Entra ID that brings Conditional Access evaluation and enforcement to AI agents. This capability extends the same Zero Trust controls that already protect human users and apps to your agents. Conditional Access treats agents as first-class identities and evaluates their access requests the same way it evaluates requests for human users or workload identities, but with agent-specific logic.

For more information about the types of agents and the identity and access management challenges they present, see Security for AI with Microsoft Entra agent identity.

Agent identity architecture in Microsoft Entra

To understand how Conditional Access works with agent identities, it's important to understand the fundamentals of Microsoft Entra Agent ID. Agent ID introduces first-class identity constructs for agents. These are modeled as applications (agent identities) and users (agent users).

Term Description
Agent blueprint A logical definition of an agent type. Necessary for agent identity blueprint principal creation in the tenant.
Agent identity blueprint principal A service principal that represents the agent blueprint in the tenant and executes only creation of agent identities and agent users.
Agent identity Instantiated agent identity. Performs token acquisitions to access resources.
Agent user Nonhuman user identity used for agent experiences that require a user account. Performs token acquisitions to access resources.
Agent resource Agent blueprint or agent identity acting as the resource app (for example, in agent to agent (A2A) flows).

For more information, see Microsoft Entra agent ID security capabilities for AI Agents.

Conditional Access capabilities for agent identities and agent users

Conditional Access enforces Zero Trust principles across all token acquisition flows initiated by agent identities and agent users.

Conditional Access applies when:

  • An agent identity requests a token for any resource (agent identity → resource flow).
  • An agent user requests a token for any resource (agent user → resource flow).

Conditional Access doesn't apply when:

  • An agent identity blueprint acquires a token for Microsoft Graph to create an agent identity or agent user.

    Note

    Agent blueprints have limited functionality. They can't act independently to access resources and are only involved in creating agent identities and agent users. Agentic 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).

    Note

    Tokens scoped to the AAD Token Exchange Endpoint: Public can't call Microsoft Graph. Agentic flows are protected because Conditional Access protects token acquisition from agent identity or agent user.

  • The Conditional Access policy is scoped to users or workload identities, not to agents.

  • Security defaults are enabled.

Authentication flow Does Conditional Access apply Details
Agent identity → Resource ✅
Yes		 Governed by agent identity policies.
Agent user → Resource ✅
Yes		 Governed by agent user policies.
Agent identity blueprint → Graph (create agent identity (Agent ID)/agent user) ❌
No		 Not governed by Conditional Access because this flow involves creation of agent identities and agent users by the blueprint.
Agent identity blueprint or Agent identity (Agent ID) → Token Exchange ❌
No		 Not governed by Conditional Access because this flow involves the blueprint or agent identity making an intermediate token exchange call that enables it to perform agentic tasks. This flow does not involve any resource access.

Policy configuration

Creating a Conditional Access policy for agents involves these four key components:

Screenshot of Conditional Access interface showing a policy configured to block all high-risk agent identities, with assignments scoped to all agent identities.

  1. Assignments
    1. Scope policies to:
      1. All agent identities in the tenant.
      2. Specific agent identities based on their object ID.
      3. Agent identities based on custom security attributes preassigned to them.
      4. Agent identities grouped by their blueprint.
      5. All agent users in the tenant.
  2. Target resources
    1. Resource targeting options include:
      1. All resources.
      2. All agent resources (agent blueprints and agent identities).
      3. Specific resources grouped by custom security attributes preassigned to them.
      4. Specific resources based on their appId.
      5. Agent blueprints (targeting the blueprint covers the agent identities parented by the blueprint).
  3. Conditions
    1. Agent risk (high, medium, low).
  4. Access controls
    1. Block.
  5. Policies can be toggled On, Off, or set to Report-only for simulation.

Common business scenarios

There are two key business scenarios where Conditional Access policies can help you manage agents effectively.

In the first scenario, you may want to ensure that only approved agents can access specific 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.

In the second scenario, Conditional Access uses signals from Microsoft Entra ID Protection to detect and block agents exhibiting risky behavior from accessing resources.

Scenario 1: Allow only specific agents to access resources

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 may 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. We recommend that organizations create a meaningful standard for the names of their 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')
      2. Exclude Select resources.
        1. Select Select resources based on attributes.
        2. Set Configure to Yes.
        3. Select the Attribute we created earlier called Department.
        4. Set Operator to Contains.
        5. Set Value to HR.
  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.

Scenario 2: Block high-risk agent identities from accessing my organization’s resources

Organizations can create a Conditional Access policy to block high-risk agent identities based on signals from Microsoft Entra ID Protection.

  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. We recommend that organizations create a meaningful standard for the names of their 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. For agent-specific entries, filter for agentType of agent user or agent identity. Some of these events appear in the User sign-ins (non-interactive) while others appear under Service principal sign-ins.

  • Agent identities (actor) accessing any resources → Service principal sign-in logs → agent type: agent ID user
  • Agent users accessing any resources → Non-interactive user sign-ins → agentType: agent user
  • Users accessing agents → User sign-ins

Related content

  • Last updated on