Design Conditional Access policies for agent identities

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.

Why Conditional Access matters for agents

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.

Start by reviewing existing user policies

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:

• Strong authentication or MFA where required
• Compliant device or trusted device requirements
• Network or location-based controls
• Legacy authentication blocking
• Resource-specific controls for Microsoft 365, SharePoint, Exchange, Teams, Graph or other sensitive resources
• Risk-based user protections where applicable

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 Conditional Access policy templates from portal

Design separate policies for autonomous agents

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

Avoid copying human-user controls to autonomous agents

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:

• Block or allow based on approval state
• Block based on agent risk
• Scope access to specific resources
• Use custom security attributes for targeting
• Use report-only mode before enforcement
• Validate sign-in impact before enabling policy

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.

Use report-only mode first

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

Recommended baseline policies

A clean Conditional Access design for agents can start with a small number of baseline policies.

Block non-approved autonomous agents

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.

Allow approved agents to access selected resources

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.

Block high-risk agent identities

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.

Apply stricter controls for sensitive agents

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.

Agent user identity considerations

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:

• Agent risk
• Execution environment
• Device compliance where supported
• Network or Global Secure Access signals where applicable
• Resource-specific access

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

Naming and governance standards

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.

Common design caveats

Keep these points visible in the design:

• Do not assume every discovered agent has a Microsoft Entra Agent ID.
• Do not assume every agent can be governed through the same Conditional Access model.
• Do not apply user MFA controls to autonomous agents without validating behaviour.
• Do not enforce policies before validating in report-only mode.
• Do not create individual policies for hundreds or thousands of agents.
• Use custom security attributes for scalable targeting.
• Keep OBO, autonomous and agent user scenarios separate.
• Validate policy impact using sign-in logs before enforcement.
• Keep exception handling documented and time-bound.

Where Conditional Access fits in the sequence

Conditional Access should come after inventory, accountability and custom security attributes.

The sequence should look like this:

1. Inventory agents.
2. Classify source, identity model and access pattern.
3. Assign owners and sponsors.
4. Populate custom security attributes.
5. Create Conditional Access policies in report-only mode.
6. Validate impact.
7. Enforce in rings.
8. Use access packages for durable resource access.
9. Monitor risky agents and policy outcomes.

Conditional Access is not the first step. It is the enforcement layer that becomes effective once the governance metadata is trusted.

Wrap-up

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.