Guardrails and Controls: Where Microsoft Foundry Intercepts Risk

From principle to plumbing

Everything in the responsible AI topic up to this point is policy: decide what could go wrong, measure it, mitigate it. Guardrails are where some of that policy becomes running code. In Microsoft Foundry, a guardrail is the safety and security machinery you apply to models and agents, and understanding its three moving parts is the single most useful piece of vocabulary in this slice.

Guardrail, control, and the three questions

A guardrail is a named collection of controls. A control is the atomic unit, and it answers three questions at once: which risk to detect, where in the request path to scan for it, and what to do when it fires. Learners who hold that triple in their heads can reason about almost any guardrail scenario, because a misconfiguration is always a wrong answer to one of the three.

The risks themselves are flagged by classification models — Foundry's guardrails draw on classification models from Azure AI Content Safety to detect harmful content across the supported categories. You are not writing the detectors; you are deciding which ones run, where, and with what consequence.

Intervention points: where scanning happens

Four intervention points exist. User input is the prompt on its way to the model or agent. Output is the final completion on its way back to the user. Those two apply to models and agents alike. The other two are agent-only and in preview: tool call, covering the action and data an agent proposes to send to a tool, and tool response, covering what a tool returns to the agent.

The reason four points exist rather than two is that risk enters a system at more than one door. Filtering only the user prompt misses harmful generations. Filtering only the output misses an agent quietly sending sensitive data to an external tool. For a plain model deployment there are only two doors; for an agent there are four, and each must be configured deliberately.

Actions: annotate, or annotate and block

When a control fires it takes one of two actions. Annotate labels the content without stopping it, which is how you observe a risk in production before you enforce against it. Annotate and block stops the content. A detail worth remembering: annotate-only applies to models, while agents support annotate-and-block. Annotation-only is therefore a model-side observation tool, not a universal dry-run mode.

The annotate-first pattern matters practically. It lets you measure how often a control would have fired against real traffic before you accept the false positives that blocking brings.

Severity thresholds

For the four content risks — hate, sexual, self-harm, and violence — each control carries a severity threshold that decides what gets flagged. Low flags content at low severity and above and is the least restrictive setting; medium flags medium and above; high flags only the most severe content and is the most restrictive. There is also an off setting, but detection can only be disabled by customers approved through the modified guardrails limited access review. That gate is itself a responsible AI control: turning safety off is not a self-service toggle.

Scope: what guardrails cover

The guardrail system applies to Foundry Models sold by Azure, with an exception for prompts and completions processed by audio transcription models. On the agent side it currently applies to agents developed in the Foundry Agent Service rather than to every agent registered in the control plane. Beyond content safety, hosted agents can also carry network egress controls in preview, configured inside the same guardrail, governing which outbound destinations an agent may reach.

The risk catalogue is broader than the four content categories. It also includes user prompt attacks, indirect attacks, protected material for text and for code, personally identifiable information, task adherence, spotlighting, and groundedness — with the last two currently applicable to models but not agents.

Defaults and inheritance

Models are assigned a default Microsoft-provided guardrail unless you replace it, which means a deployment is never completely unprotected by accident. Agents follow a chain: an explicitly assigned custom guardrail wins; with none assigned, the agent inherits the guardrail of its underlying model deployment. So an agent running on a model deployment that uses a custom guardrail also uses that custom guardrail until you say otherwise.

Common mistakes

The biggest is assuming that adding a control to a guardrail means it is running everywhere. If a guardrail contains controls for preview risks that agents do not yet support, those controls simply do not take effect for the agent, while still applying to models using the same guardrail — the symptom is behaviour that does not match the configuration you can see in the portal. A second mistake is configuring only the user-input intervention point and assuming outputs are covered. A third is reading a blocked legitimate response as a bug rather than as a threshold set more restrictively than your content warrants.

How this connects to the principles

Guardrails are the safety-system layer of the layered mitigation model, and they carry reliability and safety, privacy and security, and part of fairness — but only within the risks they define. They are a floor, not a ceiling, and they never replace scoping the use case.