9.4 Defender for AI, Foundry Guardrails & AI Gateway

9.4 Defender for AI, Foundry Guardrails & AI Gateway

Quick Answer: Protect Azure AI platforms with three complementary layers: Foundry guardrails (inline safety / Prompt Shields), AI Gateway in Azure API Management (governed front door for Foundry traffic), and Defender for AI Service in Defender for Cloud (threat detection + Data and AI security dashboard visibility). Assume prompt injection is a first-class risk.

SC-500 skills measured close the AI domain with platform controls:

• Enable Defender for AI Service in Cloud Workload Protection in Defender for Cloud
• Configure guardrails for agent security in Foundry
• Configure and deploy AI Gateway in Azure API Management for Microsoft Foundry
• Monitor AI security by using the Data and AI security dashboard in Defender for Cloud

This section is the Azure / Microsoft Foundry stack—complementing Purview (data), Copilot Studio (M365 agents), and Entra Agent ID (identity).

Microsoft Foundry in one sentence

Microsoft Foundry (evolved from Azure AI Foundry branding in Microsoft materials) is Microsoft’s platform for building, deploying, and operating AI applications—models, agents, tools, and supporting data. SC-500 does not require you to be a prompt engineer; it requires you to secure the control and data planes around Foundry workloads.

Layered model: three different timings

Exam trap: Enabling Defender does not replace guardrails; deploying a gateway does not replace Content Safety filters. Defense in depth is the point.

Enable Defender for AI Service in Cloud Workload Protection

Microsoft Defender for Cloud protects AI with two related ideas often discussed together:

1. AI security posture management (AI SPM) — discover generative AI apps, misconfigurations, recommendations, attack paths (typically associated with Defender CSPM capabilities).
2. AI threat protection / Defender for AI services — runtime-oriented Cloud Workload Protection (CWP) style detections for AI workloads.

What you enable

In Defender for Cloud environment settings, enable the plan commonly referred to in training as Defender for AI Services / threat protection for AI workloads (wording in portal may appear as AI services workload protection). Microsoft Learn modules for SC-500-aligned training phrase it as enabling Defender for AI Services workload protection and then monitoring via the Data and AI security dashboard.

What threats matter (conceptual)

Microsoft threat content for AI commonly discusses classes such as:

• Jailbreak / unsafe model manipulation attempts
• Prompt injection (direct user prompts and indirect injections hidden in documents/tools)
• Credentials or sensitive data in outputs (model echoing secrets)
• Anomalous usage that may indicate abuse or automated attacks
• Misconfiguration-driven exposure (public endpoints, weak auth) discovered via posture recommendations

Defender alerts should be investigated like other workload alerts—correlate in Microsoft Defender XDR when incidents span identity, cloud, and AI resources.

Posture recommendations you should recognize

AI SPM-style checks documented for generative AI apps include patterns such as:

• Use private endpoints for Azure AI services
• Restrict public endpoints appropriately
• Prefer managed identity / identity-based authentication over key sprawl

If a scenario says an Azure OpenAI / Foundry endpoint is public with keys in a client app, the security engineer answer is almost never “hope users are nice”—it is identity + network isolation + gateway + monitoring.

Configure guardrails for agent security in Foundry

What guardrails are

Microsoft Foundry guardrails are named collections of controls. Each control defines:

• A risk to detect (harmful content categories, user prompt attacks, document attacks, etc.)
• Intervention points where scanning happens
• An action when detected (for example annotate vs block)

Guardrails leverage classification models from Azure AI Content Safety. Content Safety is the underlying detection service; Foundry guardrails are the policy/enforcement layer that applies those detections automatically to deployments and agents without every app calling Content Safety APIs manually.

Intervention points (memorize)

Agent-focused intervention points matter because indirect prompt injection often arrives via tool responses or grounded documents—not only the user’s first message.

Prompt Shields and content safety concepts

Prompt Shields in Microsoft Foundry address:

• User prompt attacks — malicious prompts trying to bypass system instructions / safety training (scanned at user input).
• Document attacks — hidden instructions in third-party content (documents, emails, web pages) trying to hijack the session (scanned at user input and tool response; Spotlighting options may exist for document attack controls).

When enabled, results typically include annotation fields such as detected and filtered so applications and operators can see whether content was flagged and whether it was blocked.

Content filters cover classic harmful categories (violence, self-harm, sexual, hate, etc.—exact category packs depend on configuration). Additional controls in the Foundry safety system may include protected material, groundedness-related controls, or abuse detection depending on feature set and region. If a specific sub-feature’s GA status is unclear in your tenant, do not invent it on the exam—reason from risk → intervention point → annotate/block.

Configuration mental model

1. Open Foundry project → Guardrails (or compliance/security workspaces where policy is managed).
2. Create guardrail with required controls (content filters, Prompt Shields, etc.).
3. Choose intervention points and actions (annotate for monitoring, block for enforcement).
4. Assign the guardrail to model deployments and/or agents.
5. Optionally use guardrail policies at subscription/resource scope to mandate that deployments use required controls and track noncompliance.
6. Validate with adversarial test prompts and document-based injection samples.

Note: Microsoft documentation has stated agent guardrails capabilities can be in preview and that guardrail systems apply to supported Foundry model/agent paths (with exclusions such as certain audio models). Read scenario constraints carefully.

AI Gateway in Azure API Management for Microsoft Foundry

Why a gateway

Applications and agents calling Foundry model endpoints need a governed entry point. AI Gateway uses Azure API Management (APIM) as the reverse proxy / control plane in front of Foundry so you can:

• Avoid distributing raw Foundry API keys to every consumer
• Enforce token rate limits and quotas per product/subscription/consumer
• Centralize logging, metrics, and tracing of prompts/responses (within privacy policy)
• Apply authentication policies (JWT validation, managed identity patterns, certificates)
• Add caching, throttling, and IP filters as needed
• Present one manageable API even when many apps call many deployments

Microsoft has documented configuring AI Gateway from the Foundry experience (Operate → Admin console → AI Gateway), creating or selecting an APIM instance, and enabling gateway status for resources/projects. New projects may default to gateway enabled; existing projects may need manual enablement. Free-tier / Basic v2 promotional details exist for getting started—prefer Standard v2 / Premium v2 class APIM for production throughput (confirm current pricing on Microsoft docs).

SC-500 scenario fit

Prompt: Fourteen applications call Microsoft Foundry. Leadership wants one place for per-consumer token limits, logging every prompt/response, and no Foundry keys on each client.

Answer pattern: Deploy AI Gateway in Azure API Management for Microsoft Foundry, issue APIM subscriptions/credentials to consumers, keep Foundry secrets on the server side, apply policies for rate limiting and diagnostics.

Data and AI security dashboard in Defender for Cloud

The Data and AI security dashboard is a centralized Defender for Cloud view to monitor data and AI resources, risks, and protection status. Benefits include:

• Inventory of storage, managed databases, hosted databases, and AI services across connected clouds
• Visibility into whether resources are fully / partially / not protected by plans such as Defender CSPM, Defender for Storage, Defender for Databases, and AI threat protection
• Top issues, high/critical recommendations, alerts, and attack paths needing attention
• Insights related to sensitive data in data resources and AI workloads (when sensitive data discovery features are enabled)

Prerequisites mindset (exam-relevant)

Microsoft documents that fuller dashboard value depends on enabling relevant plans (for example Defender CSPM with sensitive data discovery, Defender for Storage, Defender for Databases, and threat protection for AI workloads) and registering the Microsoft.Security resource provider. Minimum RBAC is often described around Security Reader / Security explorer class permissions for viewing assessments and alerts. Exact role names can vary—know you need security read rights, not Owner on every resource, for monitoring scenarios.

Operational use: After enabling Defender for AI Service, the dashboard is where leadership demos “are our AI resources covered?” and where engineers prioritize the noisiest gaps.

Prompt injection & content safety — exam risk language

End-to-end scenario (ties the chapter together)

Fabrikam builds an internal research agent on Microsoft Foundry that grounds on SharePoint and calls a summarization model:

1. Purview DSPM for AI remediates overshared research libraries; labels block Copilot-style oversharing of Highly Confidential sets.
2. Agent runtime in enterprise channels uses Entra Agent ID with Conditional Access; permissions are site-scoped.
3. Foundry guardrails enable Prompt Shields at user input + tool response; block on high-severity hits.
4. All model calls go through AI Gateway (APIM) with per-team token quotas and full diagnostics.
5. Defender for AI Service is enabled; the Data and AI security dashboard shows the Foundry resources as protected; SOC receives jailbreak alerts in Defender XDR.
6. If a related Copilot Studio front-end exists, real-time protection blocks unsafe email tools.

That is “implement security for AI” as SC-500 intends—not a single product silo.

SC-500 traps

1. AI Gateway = Web Application Firewall only — Gateway is APIM governance for AI APIs; WAF may sit elsewhere (App Gateway/Front Door) for HTTP threats but is not a substitute for token quotas and Foundry key isolation.
2. Guardrails = network NSG — Guardrails are content/safety controls, not subnet rules.
3. Defender for AI replaces Purview — Different planes (threat/posture in Defender for Cloud vs data security in Purview).
4. Prompt injection is only a developer education issue — It is an exam-measured technical risk with platform mitigations.
5. Dashboard works fully with no plans enabled — Full value needs the relevant Defender plans and permissions.

Implementation checklist

1. Inventory Foundry/AI resources and endpoints (public vs private).
2. Enable Defender CSPM + Defender for AI Services threat protection on in-scope subscriptions.
3. Open Data and AI security dashboard; remediate critical AI recommendations first.
4. Create and assign Foundry guardrails (content filters + Prompt Shields) to production agents/models; prefer block for high-risk intervention points.
5. Deploy AI Gateway via Foundry admin console / APIM; migrate clients off raw keys.
6. Wire logs/alerts to Defender XDR / Sentinel as your org’s SOC standard (Sentinel details appear in later SC-500 posture chapters).
7. Red-team with sample direct and indirect injection payloads; verify block/annotate behavior.

Bottom line: SC-500’s Azure AI security story is guardrails for safety, AI Gateway for governance, Defender for AI for threat detection, and the Data and AI dashboard for continuous visibility—always assuming prompt injection and oversharing are real, not theoretical.