L12. Securing AI Agents: Microsoft Entra Agent ID, Foundry Guardrails & Defender for AI

Microsoft Entra Agent ID

Microsoft Entra Agent ID extends Microsoft Entra's identity model to AI agents themselves, so an agent isn't just "using" a service principal on an application's behalf, it gets its own governable identity: discoverable, subject to access policies, and reviewable the same way a human or workload identity is.

The distinctive risk concept here is blast radius. Entra Agent ID introduces blueprints and blueprint principals: a blueprint can be linked to *multiple* agent instances and their associated privileges, potentially across tenants. If an attacker compromises a credential tied to a blueprint, they may gain access to every identity built from that blueprint, not just one agent instance, which is a materially larger blast radius than compromising a single traditional application's service principal.

Conditional Access for Agent ID

Because agent identities live in Microsoft Entra, they can be targeted directly by Conditional Access, the same engine covered in Lesson 1: if you already know how to scope a CA policy to a user or workload identity, you already know the mechanics for scoping one to an agent. This lets organizations require specific conditions (location, risk level) before an agent identity is allowed to authenticate and act.

Analyzing Blast Radius with Defender XDR

Microsoft Defender XDR extends its posture and investigation capabilities to agent identities, assessing an agent's risk level based on its configuration, access grants, runtime activity, and any active alerts, then modeling the blast radius of a hypothetical compromise: which other identities, data, and resources would be reachable if this specific agent (or the blueprint it was built from) were compromised. This lets security teams prioritize which agents to review first, rather than treating every deployed agent as equal risk.

Managing Agent ID Access

Ongoing governance of agent identities mirrors human identity governance: reviewing which permissions an agent actually holds versus what it needs, ensuring blueprint principals aren't scoped more broadly than necessary, and tracking agent inventory so no agent identity exists outside of a known, reviewed set.

AI Gateway in Azure API Management for Microsoft Foundry

Microsoft Foundry (the platform for building AI applications and agents) can create or associate an AI Gateway, built on Azure API Management, sitting in front of model and agent calls the same way APIM has always sat in front of traditional APIs. This brings API Management's existing governance model to AI traffic specifically: token-based rate limiting, usage quotas per consumer, centralized logging/observability of every model call, and policy enforcement (like blocking a request that doesn't match an approved model deployment) at the gateway layer rather than scattered across every application calling the model directly.

Defender for AI Service

Defender for AI Service, enabled as a Cloud Workload Protection plan in Defender for Cloud, consumes annotations produced by an application's configured guardrails (content safety filters) and correlates them into security incidents: a detected jailbreak attempt or prompt injection isn't just logged by the guardrail in isolation, it's scored into the application's overall AI security posture and can be walked as an attack path, the same way Defender CSPM walks attack paths for traditional cloud resources.

Configuring Guardrails in Foundry

Guardrails in Microsoft Foundry are the content-safety and behavioral controls configured directly on a model deployment or agent: blocking categories of harmful content, detecting prompt injection attempts, and constraining what tools/actions an agent is permitted to invoke. These guardrail annotations are precisely what Defender for AI Service ingests to build its correlated view.

The Data and AI Security Dashboard

Defender for Cloud's Data and AI security dashboard unifies visibility across data security posture (from Purview DSPM) and AI-specific posture (from Defender for AI Service and Entra Agent ID risk data) into a single view, so a security team isn't switching between separate Purview and Defender consoles to understand overall AI risk.

Managing Agents in the Microsoft 365 Admin Center

Beyond Entra and Defender, the Microsoft 365 admin center provides an inventory and management surface specifically for agents deployed across Microsoft 365 (including Copilot Studio agents), letting admins see what agents exist, who published them, and manage their availability, complementing the identity-focused view in Entra Agent ID with an application-lifecycle view. Exam tip: Expect the exam to test the *chain*: guardrails generate annotations → Defender for AI Service correlates those annotations into incidents and posture scores → the Data and AI security dashboard surfaces that alongside data posture → Entra Agent ID and Defender XDR separately handle the *identity and blast-radius* dimension of the same overall AI risk picture.