Configure safety filters, guardrails, risk detection, and content moderation

Content filtering is one of the few areas of Foundry with meaningful defaults, and most exam questions here turn on knowing exactly what those defaults are. Some protections are on out of the box; one important one is off; and the direction in which you are allowed to weaken them is asymmetric.

Why This Matters

Three properties make the defaults worth memorising rather than reasoning about.

A safe default is not a complete default. Harm-category filtering applies without configuration, but the shield covering instructions hidden in retrieved documents is off unless you enable it. A team running on defaults is protected against the attack that arrives in the user's prompt and exposed to the one that arrives in a supplier's PDF.

Weakening is gated in one direction only. Making filters stricter is self-service; turning them off on completions requires approval. That asymmetry tells you which direction the platform considers risky.

Two severity scales coexist. The content filtering system classifies into four levels — safe, low, medium, high — and you set a threshold there. The Content Safety API returns numeric severities that differ by modality. Questions frequently hinge on which surface is being described.

Prerequisites

• That a content filter is a configuration object applied to a model deployment.
• The difference between a prompt (input) and a completion (output).
• What prompt injection is, and that content can arrive from retrieved documents as well as from a user.
• That filters are created at the resource level and associated with deployments.

Learning Objectives

By the end of this lesson you will be able to:

1. State the default filtering configuration and what it covers.
2. Distinguish direct and indirect Prompt Shields, including their differing defaults.
3. Configure thresholds, annotate-only, and blocklists, and know which changes need approval.
4. Distinguish the content filtering severity levels from the Content Safety API scales.
5. Apply a filter to a deployment, and override it per request.

Building Blocks

The four harm categories. Content Safety "recognizes four distinct categories of objectionable content": Hate and Fairness (Hate), Sexual, Violence, Self-Harm (SelfHarm). "Classification can be multi-labeled" — one sample can be both Sexual and Violence. The harm-categories table also lists Task Adherence, which "helps ensure AI Agents consistently behave in alignment with user instructions and task objectives", identifying "misaligned tool invocations, improper tool input or output relative to user intent".

The default configuration. "The content filtering system… uses an ensemble of multi-class classification models to detect four categories of harmful content (violence, hate, sexual, and self-harm) at four severity levels respectively (safe, low, medium, and high)… The default content filtering configuration is set to filter at the medium severity threshold for all four content harms categories for both prompts and completions."

Configurability. All customers can set thresholds to Low, medium, high (strictest), Medium, high, or High only, separately for prompts and completions. No filters and Annotate only are available for prompts, and for completions "If approved" — "Approval is required for turning the content filters partially or fully off on completions."

The other filters, with their defaults.

Blocklists. "You can apply a blocklist as either an input or output filter, or both… Select one or more blocklists from the dropdown, or use the built-in profanity blocklist. You can combine multiple blocklists into the same filter."

Scope and application. "Content filters can be configured at the resource level. Once a new configuration is created, it can be associated with one or more deployments." A per-request override exists: the x-policy-id header, where "the request-level content filtering configuration will override the deployment-level configuration, for the specific API call" — though it "is not available for image input (chat with images) scenarios."

The API severity scales. Text — "supports the full 0-7 severity scale… If the user specifies, it can return severities in the trimmed scale of 0, 2, 4, and 6." Image — "supports the trimmed version… The classifier only returns severities 0, 2, 4, and 6." Image with text (multimodal) — "supports the full 0-7 severity scale."

Deep Dive

The exposure hiding in the defaults

The single most examinable fact in this objective is that indirect-attack Prompt Shields is off by default.

The two shields address different threats. The direct-attack shield "filters / annotates user prompts that might present a Jailbreak Risk" — the user themselves trying to break the system. The indirect-attack shield covers "Indirect Attacks, also referred to as Indirect Prompt Attacks or Cross-Domain Prompt Injection Attacks, a potential vulnerability where third parties place malicious instructions inside of documents that the generative AI system can access and process."

Any RAG or agent system ingests third-party content — supplier PDFs, web pages, email, tool responses. On a default configuration, that entire surface is unprotected while something called "Prompt Shields" is switched on, which is exactly why the misconception survives.

Enabling it has a prerequisite worth knowing: the indirect shield "Requires: Document embedding and formatting", so the documents must be presented in the documented structure for the service to distinguish content from instructions.

Thresholds, and the asymmetry of weakening

Threshold configuration is straightforward: pick which severities are filtered, separately for prompts and completions. "Content detected at the 'safe' severity level is labeled in annotation output but isn't subject to filtering and isn't configurable."

What matters is the governance asymmetry. Tightening — moving from medium, high to low, medium, high — is self-service. Loosening on completions to No filters or Annotate only "requires approval", available through the Limited Access Review for modified content filters.

Annotate only is worth understanding as a distinct mode rather than a synonym for off: it "runs the respective model and returns annotations via API response, but it will not filter content." That makes it the right choice when you need to measure prevalence before enforcing, or when an application wants to make its own decision from the annotation.

Two severity vocabularies

Confusing these produces confidently wrong answers.

The content filtering system — the thing you configure on a deployment — classifies into four levels: safe, low, medium, high. You set the threshold in those terms.

The Content Safety API — called directly — returns numeric severities, and the range depends on modality. Text supports the full 0–7 scale, optionally returning a trimmed 0/2/4/6 where "each two adjacent levels are mapped to a single level". Image supports only the trimmed scale, returning nothing but 0, 2, 4 and 6. Multimodal — image with text — supports the full 0–7.

The image restriction is the detail most often tested, and the reasoning trap is assuming the ceiling was lowered. It was not: multimodal returns 7, so nothing is being reserved. The image model simply reports at coarser resolution.

Blocklists: the enumerable case

A blocklist matches terms you can name in advance, and can be applied as an input filter, an output filter, or both, with multiple blocklists combined into one filter and a built-in profanity list available.

That makes it exactly right for a defined, enumerable set — a partner's prohibited symbol list, a set of internal identifiers that must never appear in output — and exactly wrong for an open-ended behaviour where an adversary chooses the wording. The general rule: if you can write the list down, a blocklist fits; if the attacker picks the phrasing, you need a detector.

Where filters live, and the request override

Filters are created at the resource level and associated with one or more deployments. The association is the step that changes behaviour, and skipping it is the classic mistake — a carefully built configuration that is not attached affects nothing, and testing in the playground then measures the default policy.

For cases needing per-call variation, the x-policy-id request header names a custom configuration and overrides the deployment-level one for that call. Two caveats: a configuration that does not exist returns InvalidContentFilterPolicy, and the override "is not available for image input (chat with images) scenarios", where the default filter is used.

Worked Examples

Example 1 — a poisoned supplier document. A RAG assistant summarizes supplier PDFs. One contains hidden text instructing the model to reveal its system prompt. The deployment uses the default filter configuration.

Prompt Shields for indirect attacks is off by default and must be enabled; the direct-attack shield is on but inspects the user's prompt, which never contained the payload. Harm categories do not apply — an instruction to disclose a prompt is not hate, sexual, violence, or self-harm content. A blocklist cannot anticipate the attacker's wording.

Example 2 — a surprised safety team. A platform screens uploaded images and finds the API returns only 0, 2, 4 and 6, while its text pipeline returns a finer scale.

The image model supports only the trimmed scale; text supports the full 0–7 and can optionally return trimmed. Multimodal supports the full range, so nothing is reserved for it — the image classifier simply reports at coarser resolution.

Example 3 — brand symbols and provenance. Partners require that a defined set of prohibited symbols never appears, and that generated images can later be shown to be machine-generated.

A custom blocklist for the enumerable symbol list, applied to the output filter. Content Credentials for provenance. Harm categories cannot be extended with a partner list, and protected material detects known copyrighted content, which is a different question from provenance.

Visual Explanations

What the defaults cover, and what they leave open:

Two severity vocabularies:

Common Mistakes

Assuming Prompt Shields covers retrieved content by default. The indirect shield is off.

Expecting harm categories to catch injection. They classify harmful content, not instructions.

Treating annotate-only as off. It runs the model and returns annotations without filtering.

Believing loosening is symmetric with tightening. Turning filters off on completions requires approval.

Confusing the four filtering levels with the API's numeric scale. And within the API, assuming image supports 0–7.

Creating a filter and not associating it with a deployment. The association changes behaviour.

Using a blocklist against an adversary who chooses the wording. Blocklists fit enumerable sets.

Reaching for Prompt Shields to stop a leak. Shields are inbound; leakage is an output concern.

Practice Exercises

1. State the default filtering configuration precisely — categories, threshold, and which directions.
2. A supplier PDF carries hidden instructions. Which control, what is its default, and why does the other shield not help?
3. Which filter changes require approval, and in which direction?
4. The image API returns only 0, 2, 4, 6. Explain, and say what multimodal returns.
5. A partner supplies a list of prohibited symbols and separately wants provenance on generated images. Name both controls.

Summary & Concept Map

Content moderation in Foundry is a defaults question first. Four harm categories are filtered at medium on both prompts and completions without configuration; direct-attack Prompt Shields and protected material for text and code are on; indirect-attack Prompt Shields, groundedness, and PII are off — and the indirect shield is the gap that matters for any system ingesting third-party content. Tightening is self-service and loosening completions needs approval. Filters are resource-level objects that only take effect once associated with a deployment, with x-policy-id for per-request overrides. And keep the two severity vocabularies apart: four named levels where you set thresholds, numeric scales at the API where image returns only the trimmed 0/2/4/6.

Sources and freshness

Written against current Microsoft Learn documentation for the AI-103 skills measured (16 April 2026), reviewed 2026-08-20. Microsoft Learn controls every changing product contract — availability, preview status, quotas, limits, regional support, naming, and retirement dates all move independently of this lesson. Where a scenario turns on a specific number or a GA/preview boundary, confirm it against the product's own page before relying on it.