Enable ID Protection and Deploy Risk-Based Conditional Access for Agents
Implementation Effort: Low – ID Protection for agents is enabled at the tenant level with minimal configuration; the risk-based CA policy follows a standard template.
User Impact: Low – Blocks only agent identities exhibiting anomalous behavior; legitimate agents are unaffected.
Overview
ID Protection for agents and risk-based Conditional Access are operationally inseparable — ID Protection provides the risk signals and Conditional Access enforces policy based on those signals. Without both in place, the organization either detects risk without enforcement or deploys policies with no signals to evaluate.
Microsoft Entra ID Protection for agents detects anomalous behavior specific to agent identities: unfamiliar resource access where an agent targets resources outside its normal pattern, sign-in spikes indicating possible automation abuse or token replay, failed access attempts suggesting an attacker is probing unauthorized resources with an agent's token, sign-ins by risky users during delegated authentication, and admin-confirmed compromise. Each detection contributes to a risk level (high, medium, low) that Conditional Access for Agent ID can consume as its only available condition. The Microsoft-managed policy provides a secure baseline by automatically blocking high-risk agent identities; organizations should verify this policy is enabled and then decide whether to deploy a custom policy with additional risk thresholds (for example, blocking medium-risk agents as well) or rely on the managed policy alone.
Risk-based policies must cover both agent identities and agent users. A CA policy scoped to "All agent identities" does not protect agent users — these are a separate identity type with human-like access to mailboxes, Teams, calendars, and documents. Agent users present higher exposure because a compromised agent user can send communications, access shared documents, and participate in meetings as a trusted team member. Organizations must create a parallel risk-based CA policy scoped to "All agent users" to ensure both identity types are protected. Agent identity sign-in events appear in service principal sign-in logs under agentType "agent ID user," while agent user events appear in non-interactive user sign-ins under agentType "agent user" — both must be monitored.
This supports Assume breach by treating every agent as potentially compromised and continuously evaluating behavioral signals to detect and block agents before they can complete an attack. It supports Verify explicitly because risk is assessed on every token acquisition, not just at initial provisioning. If risk-based CA is not deployed, a compromised agent can continue to access resources indefinitely — even after ID Protection flags the agent as risky — because there is no policy to act on the signal. The risk detections appear in the Risky Agents report, and remediation actions (confirm compromise, confirm safe, dismiss risk, disable agent) are available directly from the report. Administrators should deploy the CA policy in report-only mode first, then validate using sign-in logs filtered by agentType before switching to enforcement.