Building Safety Guardrails into AI Systems

Guardrails are essential for managing AI risk in production environments. They are the difference between a prototype that works in a demo and a system customers actually trust — and, increasingly, they are not something teams need to build from scratch. Azure, AWS, and Google Cloud all now ship managed guardrail services with defined harm categories, configurable thresholds, and jailbreak detection built in.

Key Takeaways

• Guardrails belong at two checkpoints, not one. An input check (is this prompt itself an attack or an out-of-scope request?) and an output check (is this response safe, on-topic, and grounded in fact?) catch different failure modes — a system that only checks one side will still ship harmful output.
• The three major clouds converge on the same four-ish harm categories. Azure AI Content Safety defines four categories — Hate and Fairness, Sexual, Violence, Self-Harm — each scored on an 0–7 severity scale (Microsoft Learn); Google's Gemini API safety settings use four similarly-scoped categories — Harassment, Hate speech, Sexually explicit, Dangerous content (Google AI for Developers); Amazon Bedrock Guardrails filters on six — Hate, Insults, Sexual, Violence, Misconduct, Prompt Attacks (AWS documentation).
• Jailbreak and prompt-injection detection is now a distinct, named capability, not a DIY regex list. Azure's Prompt Shields explicitly detects both direct "user prompt attacks" (role-play jailbreaks, instructions to ignore system rules) and indirect "document attacks" (hidden instructions smuggled inside a retrieved document) (Microsoft Learn); Bedrock Guardrails' Standard tier adds equivalent prompt-attack detection with broader language coverage (AWS).
• Defaults differ meaningfully across providers, and that's a real design decision, not a footnote. Google's own documentation states that for Gemini 2.5 and 3 models, the adjustable safety filter threshold defaults to Off (Google AI for Developers) — meaning a team building on Vertex AI/Gemini needs to deliberately enable and tune filtering, rather than starting from a conservative default and loosening it.
• A managed guardrail service does not replace domain-specific policy checks. None of these platforms know your company's specific refund policy, medical disclaimer requirements, or brand rules — that layer still has to be built and owned by the product team, on top of the platform's general-purpose filters.

What Are Safety Guardrails?

Safety guardrails are constraints and checks that prevent AI systems from producing harmful, inaccurate, or out-of-scope outputs. In a production system they typically operate as two checkpoints around the model itself, plus a decision layer for what happens when something is flagged:

1. Input guardrails — reject or flag problematic requests before they reach the model: jailbreak attempts, prompt injection, requests clearly out of the system's intended scope.
2. Output guardrails — check the model's response before it reaches the user: harmful content by category, factual groundedness against source material, policy compliance.
3. Escalation routing — send anything the guardrails flag as uncertain, borderline, or high-risk to a human reviewer or a safe fallback response, rather than silently blocking or silently allowing it.

How the Major Cloud Platforms Implement This

Halden Solutions builds primarily on Microsoft Azure for cloud and platform work; for AI-specific capability we also work across AWS and Google Cloud where their tooling is more mature, since both currently lead on AI infrastructure breadth. All three now offer managed guardrail services rather than requiring hand-built classifiers, and it's worth knowing what each actually covers before choosing where to build.

Azure AI Content Safety and Prompt Shields

Azure AI Content Safety scores text and image content across four harm categories — Hate and Fairness, Sexual, Violence, and Self-Harm — using a severity scale from 0–7 for text (a trimmed 0/2/4/6 scale for images), with content able to be multi-labeled across categories simultaneously (Microsoft Learn — Harm categories). Separately, Prompt Shields is a dedicated API that detects adversarial input before generation — both direct "user prompt attacks" (asking the model to ignore its rules, role-play as an unrestricted persona, or use encoding tricks to smuggle disallowed requests past a filter) and indirect "document attacks" (hidden instructions embedded in a document the model is asked to summarize or reference) (Microsoft Learn — Prompt Shields). Azure AI Foundry also offers groundedness detection specifically to catch hallucinated claims in retrieval-augmented responses.

Amazon Bedrock Guardrails

Bedrock Guardrails filters content across six categories — Hate, Insults, Sexual, Violence, Misconduct, and Prompt Attacks — with per-category filter strength configuration, plus separate mechanisms for denied topics (block specific subjects entirely, e.g. a banking assistant refusing to discuss unregulated investment schemes), word filters (exact-match blocking of specific terms, including a ready-to-use profanity list), sensitive information filters (probabilistic PII detection and masking), and contextual grounding checks for RAG hallucination detection (AWS documentation — Guardrail components). A June 2025 update introduced a "Standard" tier with materially better detection of prompt-variation attacks (including typos designed to evade filters) and expanded language support to roughly 60 languages, available to customers who opt into cross-region inference.

Google Gemini / Vertex AI safety filters

Gemini's API safety settings cover four categories — Harassment, Hate speech, Sexually explicit, and Dangerous content — each independently configurable across five threshold levels from "Block most" to "Off," alongside non-adjustable built-in protections against core harms like child-safety violations (Google AI for Developers — Safety settings). The detail worth designing around explicitly: Google's own documentation states the default threshold for these adjustable filters on Gemini 2.5 and 3 models is Off. This is a materially different starting posture than Azure or AWS, where guardrails are configured on and simply tuned — a team building on Gemini needs to make enabling and calibrating these filters an explicit implementation step, not assume a safe-by-default posture.

Comparison: Guardrail Capabilities Across Platforms

Sources: Microsoft Learn, AWS documentation, Google AI for Developers. Capabilities change frequently — verify current specifics against each provider's documentation before architecture decisions.

Why This Goes Beyond Any Single Platform's Filters

Platform-level harm categories map closely to the risks NIST's Generative AI Profile (NIST AI 600-1) identifies as needing mitigation industry-wide: content that enables non-consensual intimate imagery or CSAM via deepfake techniques, large-scale mis/disinformation, and "confabulation" — a model generating false information a user may believe and act on (NIST AI 600-1). NIST's recommended mitigations — enhanced human oversight of outputs, content provenance/watermarking, pre-deployment red-teaming, and structured incident reporting — apply regardless of which cloud platform's guardrail service you use, since they're organizational practices, not vendor features.

Common Guardrail Failures

Trade-offs and Decision Guidance

Guardrail Implementation Checklist

1. Map your risks — what could this system plausibly do wrong, and what's the worst realistic outcome?
2. Enable and check platform defaults — don't assume; confirm what your provider's guardrails actually block out of the box.
3. Add input and output checks — both directions, not just one.
4. Layer in domain-specific policy checks — no platform guardrail knows your company's specific rules.
5. Define escalation thresholds — what confidence level routes to a human, and to whom?
6. Log every trigger — you cannot improve a guardrail system you can't see the behavior of.
7. Test with adversarial input — jailbreak attempts, edge cases, and requests that sound in-scope but aren't.

How Halden Solutions Approaches This

We default to Azure AI Content Safety and Prompt Shields for clients standardizing on Azure, since it covers both harm-category filtering and jailbreak detection in one integrated service. Where a client's AI workload sits on AWS or Google Cloud — often because a specific model or AI-infrastructure capability there is the better fit for the use case — we build guardrails against Bedrock Guardrails or Gemini's safety settings respectively, and explicitly verify default configuration rather than assuming it matches Azure's posture. In every case, we treat platform guardrails as the first layer, not the whole system: domain-specific policy checks, escalation design, and trigger logging are scoped as part of the same engagement, not left as a follow-up.

Frequently Asked Questions

Do Azure, AWS, and Google Cloud all provide AI guardrails out of the box? Yes, all three now offer managed guardrail services — Azure AI Content Safety with Prompt Shields, Amazon Bedrock Guardrails, and Gemini's configurable safety filters — though their default configurations and specific capabilities differ, as detailed above.

Are platform guardrails enabled by default? It depends on the platform. Azure and AWS guardrails are generally active by default with configurable strength; Google's documentation states Gemini 2.5 and 3 models default their adjustable safety filters to off, requiring explicit configuration.

Do managed guardrails remove the need for custom safety logic? No — they cover general-purpose harm categories and, on some platforms, jailbreak detection and groundedness checks. They have no knowledge of your product's specific policies, so domain-specific rules still need to be built separately.

Which cloud should we build AI guardrails on? This should follow your broader cloud and AI infrastructure strategy rather than being decided in isolation — if you're building primarily on Azure, its integrated Content Safety and Prompt Shields stack is a natural default; if a specific AI capability is stronger on AWS or Google Cloud for your use case, their respective guardrail services cover comparable ground.

Conclusion

Guardrails aren't optional in production, and increasingly they aren't something you build from scratch either — Azure, AWS, and Google Cloud all ship managed services covering the core harm categories and, in Azure's and AWS's case, jailbreak detection as a named capability. The design work that remains is knowing each platform's actual defaults, layering in the domain-specific policy checks no platform can provide, and building the escalation and logging that turn a set of filters into an accountable system.

Have questions about implementing guardrails for your specific AI use case and cloud environment? Halden Solutions' Data & AI team can help design the right layers for your risk profile.

Sources

• Microsoft Learn — "Harm categories in Azure AI Content Safety"
• Microsoft Learn — "Prompt Shields in Azure AI Content Safety"
• AWS Documentation — "Create your guardrail" (Amazon Bedrock Guardrails components)
• Google AI for Developers — "Safety settings" (Gemini API)
• NIST — AI 600-1, Artificial Intelligence Risk Management Framework: Generative AI Profile