Place guardrail controls where risks enter

Learning objective

Configure Microsoft Foundry native content guardrails, categories, severity thresholds, and intervention points.

Core idea

A Microsoft Foundry guardrail is a named collection of controls. Each control selects a risk, an applicable intervention point, and an action. For the four harmful-content categories, it also selects a severity threshold. The architecture decision is where to inspect content and what to stop when a detector flags it.

A guardrail on the final answer cannot prevent every unsafe intermediate operation. Tool arguments can carry harmful content outward, and tool results can introduce malicious instructions before an answer exists. Agent guardrails are preview; Tool call and Tool response are also explicitly preview intervention points. Plan their use with those statuses and their integration limits visible.

How it works

Select categories and thresholds independently

The four harmful-content categories are Hate, Sexual, Violence, and Self-harm. They classify different risks, so a benign result in one category does not clear the others. Foundry reports severity as Safe, Low, Medium, or High. Safe content is annotated but never filtered, and Safe is not a configurable blocking threshold.

Configure thresholds by the severities they include:

With a blocking action, lowering the threshold broadens the content that can be blocked. Do not interpret High as “block more.” Microsoft’s tables label Low “least restrictive” and High “most restrictive” while specifying the inclusion behavior shown here; use the explicit flagged-severity rule when making the decision.

Off disables detection for that category. For models sold by Azure, turning guardrails off requires approval for modified guardrails. Treat this as a governed configuration change, not an ordinary tuning shortcut. Threshold tuning should use representative allowed and disallowed content so you can distinguish reduced false positives from missing protection.

Other controls cover different questions. User prompt attacks and Indirect attacks detect attempts to redirect the model; they do not use the four-category harm threshold as their decision contract. Protected material for text and Protected material for code are separate risks. The applicability table marks Personally identifiable information and Task Adherence preview. It also marks Spotlighting and Groundedness preview and unsupported for agents. A risk appearing in a shared guardrail does not establish that every assigned target runs it.

Place controls at applicable intervention points

Foundry defines four points in the interaction:

Select only combinations supported for the chosen risk. For example, user prompt attacks apply to User input. For indirect injection in a tool result, the documented combination is Indirect attacks, Tool response, and Annotate and block; see 4.2.2 for attack classification and 4.2.4 for the result-screening design.

Tool moderation requires support from the integration itself. The documented supported set is Azure AI Search, Azure Functions, OpenAPI, Sharepoint Grounding, Fabric Data Agent, Bing Grounding, Bing Custom Search, and Browser Automation. Controls at Tool call or Tool response do not take effect for tools outside this set. A configured control therefore needs an integration check, not merely a successful save in the portal.

The native guardrail system applies to agents developed in Foundry Agent Service, not every agent registered in the Foundry Control Plane. The overview also excludes prompts and completions processed by audio transcription models. Keep target type and processing path in your configuration review.

Choose enforcement and assign the policy

Annotate reports detected risk without blocking and is supported for models. Annotate and block reports and blocks and is supported for both models and agents. Agent guardrails do not support an annotate-only action. A model annotation-only experiment is therefore not evidence that an agent has an equivalent monitoring configuration.

In the portal, Build → Guardrails → Create Guardrail opens the configuration wizard. Add control records the selected risk, intervention points, and action. The assignment stage uses Add agents and Add models to select targets. Review the controls and assignments before creating the named guardrail. Try in Playground tests an assigned guardrail; use a non-production target because assignment immediately changes its behavior.

For resource configuration through REST, a guardrail is an Azure Resource Manager RAI policy. RAI Policies - Create Or Update creates or updates it. For a model deployment, the deployment property raiPolicyName selects the policy through Deployments - Create Or Update. This deployment mechanism does not mean a tool-specific control runs on a model.

Check agent override behavior

An agent without a custom guardrail inherits its underlying model deployment’s guardrail. Models receive Microsoft.DefaultV2 by default, but an agent does not independently receive that policy regardless of its model: it inherits the model’s assignment unless you explicitly assign another.

An explicitly assigned agent guardrail fully overrides the model guardrail. It is not a union of two protection sets. If the agent policy includes Violence at User input and Output but omits tool intervention points, the model policy does not fill those omissions. Review the complete agent policy whenever replacing an inherited assignment.

Key distinctions and trade-offs

Category versus severity: The category identifies the harm; the threshold determines which severities trigger the control. Attack detection is a separate risk selection.

Detection versus enforcement: Annotating a model request does not block it. Agent policies require the supported blocking action rather than an assumed annotation-only mode.

Assignment versus coverage: A guardrail can be assigned successfully while controls are inapplicable to the target or tool. Check target type, risk support, and moderation support together.

More extensive intervention coverage adds inspection work but catches risks before later stages consume them. Less extensive coverage may reduce overhead while leaving intermediate content unchecked. Make that trade-off per processing path, rather than applying one policy name and assuming universal coverage.

Architecture / decision scenario

A support agent uses Azure AI Search for case evidence and a remote MCP tool for account changes. Its model deployment has a model-level guardrail. The team explicitly assigns an agent guardrail with Medium thresholds for the four harm categories at User input and Output, plus Indirect attacks at Tool response with Annotate and block.

A low-severity Violence example is not flagged by the Medium threshold, while a medium-severity example is. A poisoned Search result is checked before agent memory because Search supports moderation. The remote MCP result needs a separate application screen because MCP is absent from the documented native moderation set; see 4.2.4. A schema-valid account-change call still requires identity authorization and approval under 4.2.3.

The team tests every configured path on a non-production agent. It verifies the agent policy as a complete replacement for the model policy and does not expect omitted tool checks to be inherited. If the task also requires Groundedness, it does not assume the agent assignment activates that unsupported control.

Common exam traps

• Treating High as a threshold that includes more severities than Low.
• Assuming an agent guardrail merges with its underlying model’s policy.
• Assuming Annotate is an available agent action.
• Equating portal assignment with moderation support for every tool.
• Presenting agent guardrails or tool intervention points as generally available.
• Using output filtering as proof that no unsafe intermediate action occurred.

What to remember

Specify risk, threshold where applicable, intervention point, and action. Confirm target and tool support, then inspect the effective agent assignment. A custom agent guardrail replaces the inherited model policy; it does not inherit missing controls from it.

Knowledge check

References

• Microsoft, Guardrails and controls overview in Microsoft Foundry
• Microsoft, Harm categories and severity levels in Microsoft Foundry
• Microsoft, Intervention points concepts
• Microsoft, How to configure guardrails and controls in Microsoft Foundry
• Microsoft, Agentic Workflows Task Adherence (preview)