4.1.5. Defender for AI Service and Foundry Guardrails
💡 First Principle: Detection for AI workloads has to watch for a fundamentally different attack pattern than traditional workload detection — the "attack" can arrive as ordinary-looking text that manipulates model behavior from inside its own input, rather than as a recognizable exploit signature.
Enabling Defender for AI Service within Cloud Workload Protection in Defender for Cloud extends threat detection specifically to AI workloads — flagging anomalous model usage, potential jailbreak or prompt-injection attempts, and suspicious agent behavior patterns. Foundry guardrails are configured at the application layer to actively filter or block risky content and behavior before it reaches (or leaves) the model — content filtering, prompt-injection mitigation, and output validation.
| Control | Layer | Question It Answers |
|---|---|---|
| AI Gateway (4.1.4) | Network/traffic | Is this call authenticated, rate-limited, logged? |
| Foundry guardrails | Application/content | Is this specific prompt or response safe to process? |
| Defender for AI Service | Detection | Does this usage pattern look like an attack in progress? |
⚠️ Exam Trap: Guardrails and Defender for AI Service serve different functions even though both relate to "AI safety" — guardrails actively filter content in real time as part of the request path, while Defender for AI Service is a detection and alerting capability. A scenario asking which control would have actively blocked a malicious prompt is pointing at guardrails, not Defender for AI Service, which surfaces the alert rather than intervening in the request itself.
Reflection Question: Why would an organization want both guardrails and Defender for AI Service rather than treating either one as sufficient on its own?
