Shipping generative AI to users means shipping its failure modes: harmful outputs, prompt injection, hallucinated claims, regurgitated copyrighted text. Azure AI Content Safety is the guardrail service, and the engineering work is layering it so the product stays useful while the failure modes stay contained.

The Detection Surface

Four capabilities cover distinct risks. Harm classification scores text and images across hate, violence, sexual, and self harm categories with severity levels, applied to both user input and model output, and the design decision is thresholds per surface: a children’s education product and an internal engineering assistant do not share a config, so severity cutoffs, and which categories block versus log, are product decisions recorded like any policy. Prompt Shields target the adversarial layer: jailbreak attempts in user prompts and indirect injection hiding in documents your RAG pipeline retrieves, the attack the AI Search post’s architecture makes possible, retrieved content telling the model to ignore its instructions, which is why shields scan documents, not just user text. Groundedness detection compares model claims against the retrieval sources and flags the ungrounded ones, the automated hallucination check, with a correction mode that can rewrite flagged claims. And protected material detection catches verbatim regurgitation of copyrighted text and code with licensing context, the check that matters most for code assistants and content products.

Layering Without Ruining the Product

The reference request path: input passes harm classification and Prompt Shields before spending model tokens (cheap rejection first, the API gateway logic from the APIM post applied to AI); retrieval results pass injection scanning before entering context; output passes harm classification, groundedness against the sources, and protected material where relevant, before reaching the user. Blocking is not the only verb, and overusing it is how AI products become uselessly defensive: the graduated responses are block (severe harms), rewrite or correct (groundedness), soft flag with citation prompts (borderline claims), and log for review (everything marginal), with the thresholds tuned against a labeled set of your actual traffic, because guardrails have precision and recall like any classifier and false positives are a product tax users notice immediately. Custom categories cover the risks generic taxonomies miss, your industry’s specific prohibited content trained from examples, and blocklists handle the small hard rules that need no ML.

Operating Responsibly, Concretely

Guardrail telemetry is operational data: category hit rates, block rates per surface, and shield trigger counts flow into the monitoring stack, alerting on anomalies, a spike in jailbreak attempts is an attack, and reviewed monthly for threshold drift, because both attacks and usage evolve. Log enough to investigate (the flagged content, the decision, the config version) under the retention and access rules sensitive data deserves, and close the loop the way the Sentinel post closed it for security alerts: sampled human review of blocks and passes, feeding threshold tuning and custom category training. The governance wrapper makes it audit ready: which guardrails run on which AI features, at which thresholds, decided by whom, is a one page register that turns “are we being responsible” from a meeting into a document, and pairs with the evaluation gates from yesterday’s Foundry post so safety regressions fail CI exactly like quality regressions. Guardrails do not make an AI product trustworthy by themselves, but their absence reliably makes it untrustworthy, and the difference is a week of engineering this post just outlined.

Cheers
Osama