Design Conditional Access policies for agent identities Microsoft Entra ID introduces Conditional Access policies for AI agent identities, enabling organizations to enforce governance based on agent classification and custom security attributes. The approach distinguishes between on-behalf-of, autonomous, and user-like agent patterns, using metadata like approval status and data sensitivity to scale policy enforcement without creating per-agent rules. This article is part of a multi-part series on Microsoft Entra Agent ID governance. For the full sequence and recommended reading order, start from the Governing AI agents with Microsoft Entra Agent ID and Agent 365 https://dev.to/stepbysteptocloud/governing-ai-agents-with-microsoft-entra-agent-id-and-agent-365-3a7g After agent inventory, ownership, sponsorship and custom security attributes are in place, the next step is to turn that governance metadata into policy enforcement. This is where Conditional Access becomes important. The goal is not to create one policy per agent. That model will not scale. The better approach is to use the information already captured during inventory and classification — such as approval status, access pattern, environment, data sensitivity and risk — to decide which agents should access which resources, and under what conditions. Conditional Access is the point where the governance model starts becoming enforceable. Agents can access resources in different ways. Some act on behalf of a signed-in user. Some operate independently using their own identity. Some behave more like user accounts with their own mailbox, collaboration context or persistent access. Because these patterns are different, one Conditional Access design will not fit every agent type. Before creating policies, classify each agent by access pattern: | Access pattern | What it means | Conditional Access approach | |---|---|---| On-behalf-of flow | Agent acts in the signed-in user’s context | Review existing user Conditional Access policies | Autonomous agent | Agent authenticates using its own identity | Use agent-specific Conditional Access policies | Agent user identity | Agent behaves like a user-like identity with its own access | Use agent-user targeting and supported endpoint/network controls | This distinction matters because the policy subject changes. In an on-behalf-of flow, the user is still central to the access decision. In an autonomous agent flow, the agent identity itself becomes the subject of the policy. For agents acting on behalf of users, do not immediately assume a new agent-specific policy is required. First review the existing user Conditional Access baseline. The organisation should confirm whether existing user policies already enforce the expected Zero Trust posture: If the user access path is already well governed, the on-behalf-of agent scenario benefits from those user-context controls. The agent does not bypass the user’s identity governance model simply because it is performing work for the user. Screenshot: Existing user Conditional Access policy baseline for Microsoft 365 resources Autonomous agents need a different approach. These agents authenticate using their own identity and may run without a signed-in user present. They cannot satisfy interactive controls in the same way a human user can. For these agents, Conditional Access should use agent-specific signals and metadata. A practical starting point is to use the custom security attributes populated in the previous phase. | Policy pattern | Suggested targeting | Recommended action | |---|---|---| Allow only approved agents | ApprovalStatus = Approved | Allow access to selected resources | Block rejected agents | ApprovalStatus = Rejected or Revoked | Block access | Restrict unknown agents | ApprovalStatus = New or ReviewRequired | Keep blocked or in report-only validation | Block high-risk agents | Agent risk is high | Block access | Protect sensitive data access | DataSensitivity = Confidential or Restricted | Apply stricter access decisions | Separate production from test | Environment = Prod , Test , Sandbox | Apply different enforcement rings | The key design idea is simple: approved agents can proceed, unknown or rejected agents should not be trusted by default. Screenshot: Conditional Access policy targeting agent identities by custom security attributes Autonomous agents are not humans. They do not complete MFA prompts. They do not respond to interactive remediation flows. They may not have a compliant device context unless they run through a managed endpoint model. For autonomous agents, focus on controls that make sense for non-human access: Avoid applying human-user policy patterns without reviewing the agent access model. A policy designed for a person may not behave correctly for an autonomous agent. Agent Conditional Access policies should not be enforced blindly. Start with report-only mode and validate the effect. A safe rollout model looks like this: | Ring | Purpose | |---|---| Ring 0 — report-only | Understand impact without blocking access | Ring 1 — pilot agents | Apply to selected approved agents | Ring 2 — production approved agents | Expand to known, classified, accountable agents | Ring 3 — broader enforcement | Apply across a wider approved population | This staged approach reduces risk. It also gives administrators an opportunity to validate sign-in logs, policy impact, exceptions and unsupported scenarios before enforcement. Screenshot: Conditional Access report-only impact for agent identity policy A clean Conditional Access design for agents can start with a small number of baseline policies. Use this policy to prevent agents without the right approval metadata from accessing corporate resources. Target agents based on custom security attributes such as: ApprovalStatus = New ApprovalStatus = ReviewRequired ApprovalStatus = Rejected ApprovalStatus = Revoked This helps ensure only classified and approved agent identities can proceed to resource access. Use this policy to ensure approved autonomous agents can access only the resources they are supposed to use. Target agents where: ApprovalStatus = Approved Environment = Prod AccessPattern = Autonomous Scope the policy to the relevant resources instead of treating all resources the same. Use this policy to respond to risky agent behaviour. If an agent identity is detected as high risk, block access until the issue is reviewed. The operational response could include reviewing permissions, disabling the agent identity, moving the agent back to ReviewRequired , or retiring the agent if it is no longer valid. Agents tagged with higher sensitivity or business criticality may need stricter governance. Example targeting: DataSensitivity = Confidential DataSensitivity = Restricted BusinessCriticality = High BusinessCriticality = MissionCritical These agents may need stricter resource scoping, closer monitoring, shorter access durations and stronger approval before access packages are granted. Some agents may operate with their own user-like identity. These scenarios need separate design consideration because controls such as device compliance, network compliance and endpoint execution context may become relevant. For agent users, consider policies that evaluate: Be careful not to apply endpoint-based requirements to cloud-native agents that have no device context. If the agent has no route to satisfy a device or network condition, the result may be unintended blocking. Screenshot: Conditional Access policy for agent user identity with endpoint-based conditions Use consistent naming so policies remain readable over time. Suggested naming pattern: CA-AgentID-