Amazon Bedrock in Practice

Amazon Bedrock Guardrails: Capabilities and When to Use Them

Claude ships with strong built-in safety behavior. Guardrails let you add your own layer on top — organization-specific rules, enforced by AWS, outside the model.

Claude 3P 101 · Updated July 2026 · Unofficial guide

Amazon Bedrock Guardrails is an AWS feature that sits between your application and the model, evaluating both the prompts going in and the completions coming out against policies you configure. It works across Bedrock's foundation models, Claude included, and it exists to answer a question the model itself cannot: "what does this organization consider out of bounds for this application?" A bank's customer chatbot, an internal HR assistant, and a developer tool all have different lines — Guardrails is where you draw them.

The six policy types

Per AWS's documentation, a guardrail can combine six kinds of safeguard:

PolicyWhat it does
Content filtersDetect harmful content in categories including Hate, Insults, Sexual, Violence, Misconduct, and Prompt Attack — in text and images
Denied topicsBlock whole subject areas you define, however the request is phrased
Word filtersExact-match blocking of specific words and phrases, including a managed profanity list
Sensitive information filtersDetect PII — personally identifiable information — and either block or mask it; custom regex patterns supported
Contextual grounding checksFor RAG applications, flag responses that are not grounded in the retrieved source material or not relevant to the query
Automated Reasoning checksValidate responses against logical rules you encode

The first four are covered in depth in their own articles: content filters, topic denial, and PII detection and redaction.

How a guardrail is applied

Two modes. The usual one: attach the guardrail to inference by specifying its ID and version on the model invocation, and Bedrock evaluates the input prompt and the model's completion as part of the call. The second: the standalone ApplyGuardrail API evaluates arbitrary text against your policies without invoking a model at all — useful for checking content from other sources, or for testing policy changes cheaply. There is also input tagging (SDK only, not the console), which lets you mark selected sections of a prompt for evaluation — handy when a prompt mixes trusted system instructions with untrusted user text and you only want the guardrail scrutinizing the latter.

Guardrails come in two tiers, Classic and Standard. The documented difference worth knowing: Standard extends detection to harmful content hidden inside code elements — comments, variable and function names, string literals — which matters if your application handles code. One documented limitation: guardrails do not evaluate reasoning content blocks, so extended-thinking output is not policed the way final text is.

When to use Guardrails — and when not to

Use them when the rule is organizational, not universal. Claude will already decline plainly harmful requests. What it cannot know is that your insurance chatbot must never discuss pending litigation, or that account numbers must be masked in every transcript. Encode those in a guardrail.

Use them when you need enforcement outside the prompt. System-prompt instructions ("never discuss X") are genuinely useful but live inside the same channel an attacker manipulates. A guardrail is configuration in AWS, versioned, and changes to it are visible in your audit trail — Amazon GuardDuty even analyzes Bedrock CloudTrail activity for suspicious behavior such as guardrail removal.

Use them for uniformity across models. Because guardrails operate at the platform layer, the same policy set applies whichever Bedrock model sits behind the application — useful if you tier between Claude models or run a mixed-model estate.

Do not treat them as the whole safety story. A guardrail is one screen in a layered defense: model behavior, prompt design, guardrail policies, IAM, and human review each catch things the others miss. No filter catches everything, and misfires in both directions (over-blocking and under-blocking) should be expected and tested for — see testing your guardrails. For regulated workloads, treat guardrail output as a control that supports your compliance case, not one that settles it; confirm requirements with your provider.

Portability note: Guardrails is a Bedrock-platform feature, not a Claude feature. If you also run Claude on Vertex AI, Foundry, or the first-party API, these policies do not follow the model — you would recreate equivalent controls per platform.

Where to go next

Ready to build one? Creating and attaching a guardrail step by step walks the console flow, and prompt injection basics explains the attack class the Prompt Attack filter targets.

Sources