Amazon Bedrock Guardrails are configured as standalone resources: you create a guardrail, configure its policies, publish a version, and then reference that guardrail from your inference calls. Nothing is enforced until the reference is in place — which is both the flexibility and the operational trap. This article walks the lifecycle end to end. (New to what guardrails can do? Start with the capabilities overview.)
Step 1: Create the guardrail in the console
In the Bedrock console, the Guardrails section walks you through creating a named guardrail. At creation time you make the structural choices: a name and description your auditors will thank you for, the tier (Classic or Standard — Standard extends detection to harmful content inside code elements such as comments, variable names, and string literals), and the messaging returned to users when the guardrail intervenes on an input or an output.
Step 2: Configure the policies
A guardrail is a bundle of up to six policy types, each optional, per AWS's documentation: content filters (Hate, Insults, Sexual, Violence, Misconduct, Prompt Attack — for text and images), denied topics, word filters (exact match, including a managed profanity list), sensitive information filters (PII blocking or masking, plus custom regex), contextual grounding checks for RAG applications, and Automated Reasoning checks. Configure only what the application needs — every policy you enable is a policy you must test and tune. The detailed decisions for the three most-used policies live in their own articles: content filters, topic denial, and PII detection and redaction.
Step 3: Test before you attach
You do not need to wire the guardrail into an application — or even invoke a model — to exercise it. The standalone ApplyGuardrail API evaluates text you supply against the guardrail's policies and reports what would be blocked or masked. Build a small test suite of prompts that should pass and prompts that should trip each policy, and run it against every draft. The console also provides a test panel for interactive spot checks. A guardrail that has never seen adversarial test input is a guess, not a control; testing your guardrails covers this in depth.
Step 4: Version it
Guardrails are referenced at inference time by ID and version. Treat versions like any other production configuration artifact: publish a version once a policy set has passed testing, point production at that immutable version, and keep iterating on the working draft separately. This gives you clean rollback and a defensible answer to "exactly which policies were enforced on March 3rd?"
Step 5: Reference it in your inference calls
Enforcement happens when the invocation names the guardrail. Per AWS's documentation, guardrails are applied at inference by specifying the guardrail ID and version on the request — this is documented for the InvokeModel and Converse APIs (and their streaming variants) on the bedrock-runtime surface. Check the current API reference for the exact request field names for your SDK, and check the Bedrock documentation for guardrail support status if you call Claude through the newer bedrock-mantle "Claude in Amazon Bedrock" surface instead. Once attached, the guardrail evaluates both the input prompt and the model's completion on every call. One documented nuance for Claude specifically: guardrails do not evaluate reasoning content blocks, so thinking output is outside their scope.
Ongoing operations
Plan for the guardrail to evolve: new denied topics after incidents, filter-strength tuning as false-positive reports arrive, new PII patterns as the application grows. Each change should flow through the same test-then-version-then-promote loop. Keep the change history alongside your other audit evidence — guardrail configuration changes are ordinary Bedrock API calls and appear in CloudTrail like everything else.
Where to go next
Deep-dive the individual policies via content filtering policies, or step back to the platform view with the feature matrix.