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
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-<AccessPattern>-<Control>-<Scope>-<Mode>
Examples:
CA-AgentID-Autonomous-Block-NonApproved-ReportOnly
CA-AgentID-Autonomous-Block-HighRisk-ReportOnly
CA-AgentID-Autonomous-Allow-Approved-Prod
CA-AgentUser-Require-CompliantDevice-Pilot
Good naming helps during operations, troubleshooting and policy review. It also prevents agent policies from being confused with human-user policies.
Keep these points visible in the design:
Conditional Access should come after inventory, accountability and custom security attributes.
The sequence should look like this:
Conditional Access is not the first step. It is the enforcement layer that becomes effective once the governance metadata is trusted.
Conditional Access turns agent classification into access control. For on-behalf-of flows, review the existing user Conditional Access baseline. For autonomous agents, use agent identity policies driven by approval status, risk and custom security attributes. For agent users, evaluate endpoint, network and device-based controls only where they apply.
Start in report-only mode, validate impact, and then enforce in controlled rings. This keeps agent governance scalable, defensible and safer to operate.