4.1.3. Microsoft Entra Agent ID: Conditional Access, Blast Radius, and Access Management
💡 First Principle: An AI agent needs its own identity to authenticate and act, but that identity behaves differently enough from a human user or a standard service principal — potentially chaining actions across many connected systems autonomously — that Microsoft gave it a distinct identity type with its own governance surface, rather than folding it into existing app registrations.
Microsoft Entra Agent ID is that distinct identity type. Conditional Access for Entra Agent ID applies the same policy engine from Phase 2 (2.1.2) to agent identities specifically — controlling what an agent can do based on context, not just whether it authenticated. Blast radius analysis in Defender XDR is unique to this identity type: because an agent can potentially touch many connected systems in a single chain of actions, blast radius analysis maps out what could be affected if a specific agent's credentials were compromised, which is a materially different question than "what permissions does this agent have" — it's about realistic reachability, not just granted scope.
Managing Entra Agent ID access means applying the same least-privilege discipline from Phase 2's PIM and RBAC sections to agents specifically — scoping what each agent identity can reach to only what its function requires, since a broadly-scoped agent identity has a correspondingly larger blast radius by definition.
⚠️ Exam Trap: Treating Entra Agent ID like a standard app registration and applying only generic app-permission review misses agent-specific governance — blast radius analysis and agent-specific Conditional Access policies exist because an agent's realistic impact if compromised isn't fully captured by its granted permissions alone.
Reflection Question: Why does blast radius analysis matter even for an agent whose granted permissions look individually reasonable and well-scoped?
