A guardrail is a policy object that lives in your AWS account, separate from any model. It holds denied topics, content filters, PII rules, and contextual grounding thresholds. You attach it to a model call, or you call it on its own with the ApplyGuardrail API. We are going to do both.

The deliverable is a single Python module, guarded_chat.py, that exposes a guarded_answer() function. It takes a user message and a trusted knowledge snippet, screens the input with ApplyGuardrail, calls Claude through the Converse API with the guardrail attached, and screens the grounded answer for hallucinations before returning anything to the user. By the end you will have run four scripted attacks and seen the guardrail intervene on each one.

The non-obvious design choice: we do not rely only on the inline guardrail attached to the model call. We also run a standalone ApplyGuardrail check on the raw input before the model ever sees it. That is the difference between a chatbot that filters its own output and a system that refuses to spend tokens on a hostile prompt in the first place. The independent API is what makes guardrails composable across providers and stages, and it is the part most tutorials skip.

One important constraint up front, straight from the AWS docs: the contextual grounding check supports summarization, paraphrasing, and question answering. It does not support open conversational chatbot turns. So our endpoint is a grounded support assistant that answers from a supplied snippet, not a free-form chat companion. That is the use case where grounding actually works.

You need an AWS account with Amazon Bedrock enabled in a region that offers Guardrails and Anthropic models. This tutorial uses us-east-1. In the Bedrock console, open Model access and request access to at least one Claude model. The model string used below is anthropic.claude-3-5-sonnet-20241022-v2:0. If your account has a different Claude version enabled, swap the string and everything else stands.

You need Python 3.9+ and boto3. You need an IAM principal whose policy allows these actions, scoped to your account:

Assumed knowledge: you can read Python, you have run an AWS CLI command before, and you have credentials configured (aws configure or environment variables). No prior Bedrock experience is required.

Pin your dependency and confirm the SDK can see Bedrock:

Smoke test that your credentials and region resolve and that the model is reachable:

If that prints a model ID, you are ready. If it prints nothing, your region has no Claude 3.5 Sonnet or your model access request has not been approved yet. If it errors with AccessDeniedException, your IAM policy is missing bedrock:* list permissions. Fix that before continuing, because the rest of the tutorial assumes the model call works.

Create a project file guarded_chat.py. We will build it up across four steps.

The first move is to define the policy object. We configure denied topics (financial and medical advice), content filters including the prompt-attack filter, PII anonymization for names and emails, and contextual grounding thresholds. This is one create_guardrail call.

Two details that trip people up. The PROMPT_ATTACK filter only takes effect on input, so its outputStrength must be NONE. Setting it to anything else returns a validation error. And the PII action field has two flavors: ANONYMIZE replaces the match with a token like {NAME}, while BLOCK stops the whole request with your canned message. Use ANONYMIZE for things you want to scrub and keep flowing, BLOCK for things that should never appear at all, like a social security number.

The grounding thresholds run from 0 to 0.99. A value of 0.7 means any answer scoring below 0.7 on grounding or relevance is treated as a hallucination and blocked. A threshold of 1 is invalid because it would block everything. Start at 0.7 and tune from there.

create_guardrail gives you a DRAFT. Drafts are mutable and meant for iteration. For anything you call repeatedly, publish an immutable numbered version so a later edit cannot silently change behavior under a running endpoint.

The version is a frozen snapshot. If you later change the draft and want the change live, you publish a new version and point your endpoint at it. This is the same discipline you would apply to any deployed config: never let production read from a mutable draft.

Before we call the model, we screen the raw user message on its own. ApplyGuardrail is decoupled from any foundation model, so you can run it as a cheap gate at the front of your pipeline and refuse hostile input before spending a single inference token.

The source field is the whole point. Set it to INPUT for user content and OUTPUT for model content. The two are evaluated with the same policy but the action semantics differ: a denied topic or prompt attack on input gets blocked here, while PII set to ANONYMIZE comes back masked in output[0]["text"], ready to forward to the model with the sensitive bits already scrubbed.

If you want the full assessment for debugging, including the policies that did not fire, pass outputScope="FULL". By default the response only returns the policies that were triggered, which keeps the payload small in production.

Now we wire it together. We screen the input, then call Converse with the guardrail attached inline and the grounding source and query tagged, so the model answer is checked for hallucinations against the trusted snippet in the same call.

The guardContent block with the grounding_source qualifier marks your trusted snippet, and the query qualifier marks the question. The grounding check scores the model answer against both. If the answer introduces facts that are not in the snippet, the grounding score drops below 0.7 and Converse returns stopReason of guardrail_intervened instead of the answer. That is hallucination filtering enforced by the platform, not by a prompt asking the model to behave.

Notice the model is never called when input screening blocks the request. That ordering is deliberate. A prompt injection or a medical-advice request is rejected at Step 3, so you pay for one cheap ApplyGuardrail call instead of a full inference plus an output check.

Put the four attacks in a main() block and run them against a tiny knowledge base:

Run it with python guarded_chat.py. Here is what each line should produce. The prompt injection returns I cannot help with that request. because the PROMPT_ATTACK filter fires on input and the model is never called. The second message has its name and email masked to {NAME} and {EMAIL} before the model sees them, and the answer about support hours comes back grounded and clean. The stock question returns the canned block message because it hits the Financial Advice denied topic. The last question is legitimate: it asks about refund timing, which is in the snippet, and about 24/7 phone support, which is not. A well-behaved answer states the refund window and declines the support-hours claim; if the model invents "yes, 24/7 support," the grounding check blocks it.

If you see four sensible interventions and one clean grounded answer, the endpoint works.

AccessDeniedException on the Converse call almost always means model access. Creating a guardrail needs no model access, so the guardrail succeeds and then the inference fails, which is confusing. Go to Bedrock console, Model access, and confirm Claude is approved in us-east-1.

ValidationException on create_guardrail is usually the PROMPT_ATTACK filter with a non-NONE outputStrength. Prompt attack is input-only. Set its outputStrength to NONE.

The grounding check does nothing. Two causes. First, you forgot one of the three required components: a grounding_source, a query, and the content to guard, which for Converse is the model response itself. Miss any one and the check silently skips. Second, you are using it for open conversational turns, which the docs explicitly do not support. Keep it to question answering over a supplied source.

PII comes through unmasked. Check that you used ANONYMIZE and not NONE, and remember that masking on the user message only shows up if you read output[0]["text"] from the ApplyGuardrail response and forward that, rather than forwarding the original text. The guardrail tells you what to send; it does not mutate your variables.

ThrottlingException under a loop of test calls is normal on a fresh account. Add a short sleep between calls or request a quota increase.

Guardrails bills per text unit, where one text unit is up to 1,000 characters. As of mid-2026, content filters and denied topics cost about $0.15 per 1,000 text units each, while PII detection and contextual grounding cost about $0.10 per 1,000 text units each. Word filters are free. Our four test prompts are a few hundred characters apiece, so the entire run costs a fraction of a cent in guardrail fees plus the normal Claude token charges for the one or two prompts that actually reach the model. Following this whole tutorial costs well under five cents. Verify current numbers on the Bedrock pricing page before you size a production workload, because these rates have already been cut twice.

Delete the guardrail so it does not linger in your account. Deleting the guardrail removes all its versions.

Or in Python: bedrock.delete_guardrail(guardrailIdentifier=gid). There is no standing charge for an idle guardrail, but cleaning up keeps list-guardrails readable and avoids name collisions on your next run.

First, swap the inline Converse guarding for two independent ApplyGuardrail calls, one on input and one on output, and compare latency. The independent path lets you guard a self-hosted or third-party model that never touches Bedrock inference, which is the real reason the API exists.

Second, add a regex policy under sensitiveInformationPolicyConfig to catch an internal identifier format that the built-in PII types miss, like an order number ORD-\d{8}. The regexesConfig block takes a name, a pattern, and an action.

Third, wire this endpoint into the Knowledge Base you built in episode 2 of this series. Feed the retrieved chunks in as the grounding_source and you have a RAG assistant whose answers are both cited and grounding-checked. That is the combination that turns a demo into something you would actually put in front of users. The question worth sitting with: once the platform can block a hallucination, where does the responsibility for a wrong answer actually sit?