Design Conditional Access Posture for Agents

Implementation Effort: Medium – Requires mapping all agent access patterns across the Microsoft Entra Agent ID architecture and defining a policy structure before any enforcement begins.
User Impact: Low – This is a design exercise; no policies are enforced at this stage.

Overview

Conditional Access for Agent ID extends Zero Trust policy enforcement to AI agents as first-class identities. Before deploying any CA policies, organizations must design a posture that accounts for the distinct identity constructs and access patterns the agent platform introduces. Without a deliberate design, teams deploy policies reactively and leave coverage gaps that threat actors can exploit to move laterally through unprotected agent flows.

The agent identity architecture introduces several constructs that CA treats differently. Agent identities are instantiated agents that acquire tokens to access resources — CA governs these flows. Agent users are non-human user identities with mailbox and Teams access — CA governs these separately. Agent blueprints, which only create agent identities and agent users, and intermediate token exchange flows are excluded from CA evaluation. Agent resources — blueprints or agent identities acting as resource apps in agent-to-agent flows — are targetable as CA resource targets. A complete posture must define policy intent for each of these constructs.

The posture design must cover six access patterns: agent identity to any resource (baseline block-unless-approved), agent identity to specific high-value resources by appId or custom security attributes, agent identity to agent resource in A2A flows, agent user to any resource, high-risk agent identity to any resource using ID Protection risk signals, and external or third-party agent identity to any resource using attribute-based classification. For assignments, policies can target all agent identities, filter by custom security attributes, group by blueprint, select specific agent identities by object ID, or target all agent users. For resources, policies can target all resources, all agent resources, resources filtered by custom security attributes, specific resources by appId, or agent blueprints which cover all child agent identities. The only condition available is agent risk (high, medium, low) from ID Protection, and the only grant control is block — agents do not support MFA or device compliance because they have no interactive sessions. This supports Verify explicitly by evaluating agent risk and classification attributes on every token acquisition, and Assume breach by enforcing segmented access controls that limit what a compromised agent can reach.

Microsoft also provides managed CA policies that automatically block high-risk agents as a secure baseline. The posture design should account for these and ensure all custom policies follow a report-only, validate, then enforce lifecycle — using sign-in logs filtered by agentType in service principal sign-ins (for agent identities) and non-interactive user sign-ins (for agent users) to validate impact before enforcement. The complete policy set that implements this posture consists of four deployment tasks: enable ID Protection and deploy risk-based CA for agents, create custom security attributes for agent and resource classification, deploy attribute-based CA policies for agents, and configure sign-in log monitoring for agent CA evaluation. Each deployment task must cover both agent identities and agent users — these are separate identity types in Conditional Access, and a policy scoped to one does not protect the other. If this posture design is not completed, subsequent CA deployments will be fragmented, agents will operate with inconsistent controls, and the organization will lack a coherent policy framework to govern autonomous AI access.

Overview​

Reference​

Overview

Reference