How to Use Amazon Bedrock Guardrails: Complete Setup Guide (2026)

Your LLM application is live, but what stops it from generating harmful content, leaking customer PII in a response, or producing a hallucination like a refund policy that does not exist? Amazon Bedrock Guardrails is AWS's answer: a configurable enforcement pipeline that sits between any foundation model and your end users, evaluating every input and output against policies you define.

This guide walks through every step of setting up Guardrails from scratch. You will create content filters, configure denied topics, set up PII detection, add word and regex filters, enable contextual grounding, and use the ApplyGuardrail API to protect models outside the Bedrock ecosystem. Each step includes verification instructions so you can confirm the guardrail works before moving to production. For a deeper understanding of what Guardrails is and how it fits the broader AI safety landscape, see What Is Amazon Bedrock Guardrails?

What You Need Before Starting

Bedrock Guardrails is a managed service within Amazon Bedrock. If you are new to the platform, our What Is Amazon Bedrock? breakdown covers the full model catalog and architecture. You do not need special hardware, but you do need a properly configured AWS account. Walk through this checklist before proceeding.

Step 1: Navigating the Guardrails Console

Guardrails are configured through the Amazon Bedrock console, AWS CLI, CloudFormation, or Terraform (via the aws_bedrock_guardrail resource). This guide uses the console for visual clarity, but every action has a CLI equivalent.

1. Sign in to the AWS Management Console and navigate to Amazon Bedrock.
2. In the left navigation pane, select Guardrails under the Safeguards section.
3. You will see a list of existing guardrails (empty if this is your first setup). The Create guardrail button is in the top-right corner.
4. Confirm you are in a supported region. Automated Reasoning requires US East (Ohio or N. Virginia), US West (Oregon), or select European regions (Frankfurt, Ireland, Paris).

Step 2: Creating Your First Guardrail (Content Filters)

Content filters are the foundation of every guardrail. They detect and block harmful content across six categories: Hate, Insults, Sexual, Violence, Misconduct, and Prompt Attack (jailbreak and injection attempts). You set the sensitivity threshold for each category independently.

1. Click Create guardrail.
2. Enter a descriptive name (for example, customer-service-guardrail) and an optional description.
3. Under Content filters, you will see the six categories. For each category, set the filter strength:
   • None: Disabled for this category
   • Low: Blocks only the most explicit content
   • Medium: Balanced detection (recommended starting point)
   • High: Aggressive filtering, may catch borderline content
4. Set Prompt Attack to High. This protects against jailbreak and prompt injection attempts. The other categories depend on your use case, but Medium is a reasonable default for customer-facing applications.
5. Choose your safeguard tier:
   • Standard: 15%+ recall improvement, 60-language support, code-level protection. Recommended for most production deployments. Requires cross-region inference opt-in.
   • Classic: Lower latency, simpler evaluations. Suitable for straightforward moderation without multilingual or code requirements.
6. Set a blocked messaging response. This is the message users see when their input or the model's output is blocked. Write something clear: "I'm unable to respond to that request. Please rephrase your question."
7. Click Next (do not save yet; you will add more policies in the following steps).

Step 3: Configuring Denied Topics

Denied topics prevent your application from discussing subjects that are off-limits. Unlike word filters, denied topics use semantic understanding: the guardrail recognizes the intent behind a question, not just specific keywords.

1. In the guardrail configuration wizard, navigate to the Denied topics section.
2. Click Add denied topic.
3. Give the topic a name (for example, "Investment Advice").
4. Write a natural language description of the topic: "Any recommendations, suggestions, or guidance about buying, selling, or holding financial securities, stocks, bonds, cryptocurrency, or other investment instruments."
5. Add example prompts that should be blocked:
   • "Should I buy Tesla stock?"
   • "What is the best cryptocurrency to invest in right now?"
   • "How should I allocate my 401(k)?"
6. Repeat for each topic you want to deny. Common examples for enterprise applications:
   • Competitor product recommendations
   • Medical diagnosis or treatment advice
   • Legal counsel or interpretation
   • Internal company financials

Step 4: Adding Sensitive Information Filters (PII Detection)

Sensitive information filters detect and handle personally identifiable information. You control the action per PII type: block the entire request or anonymize the PII by replacing it with a placeholder.

1. Navigate to the Sensitive information filters section in the wizard.
2. Enable the PII types relevant to your application. Available types include:
   • Names, email addresses, phone numbers
   • Social Security numbers, credit card numbers
   • IP addresses, AWS account IDs
   • Driver's license numbers, passport numbers
3. For each PII type, choose the action:
   • Block: Reject the entire request or response
   • Anonymize: Replace the detected PII with a placeholder (for example, {EMAIL}, {PHONE}, {SSN})
4. For most applications, use Anonymize for common identifiers (email, phone, name) and Block for high-sensitivity data (SSN, credit card numbers).
5. Add custom regex patterns for organization-specific identifiers. For example, if your employee IDs follow the pattern EMP- followed by six digits:

   EMP-\d{6}

   Regex-based filters are free; no per-unit charge applies.

Step 5: Setting Up Word Filters and Regex

Word filters are the simplest policy type: exact-match keyword blocking. Use them for profanity, competitor names, internal project codenames, or any term that should never appear in inputs or outputs. Word filters are free.

1. Navigate to the Word filters section.
2. Enable the managed word list to block common profanity. AWS maintains this list.
3. Add custom words and phrases. Enter each term on a new line or upload a CSV file. Examples:
   • Competitor product names: "CompetitorX", "RivalProduct"
   • Internal codenames: "Project Phoenix", "Alpha Build"
   • Sensitive terms specific to your industry
4. Note that word filters are case-insensitive and match exact strings. The phrase "CompetitorX" will also catch "competitorx" but will not catch "Competitor X" (with a space). Add variations as needed.

Step 6: Enabling Contextual Grounding

Contextual grounding checks evaluate whether the model's response is grounded in the provided reference source and relevant to the user's query. This is the hallucination detection layer for RAG (Retrieval-Augmented Generation) applications. If your application retrieves documents and uses them to ground model responses, this filter catches cases where the model drifts from the source material.

1. Navigate to the Contextual grounding section.
2. Set the Grounding threshold (0.0 to 1.0). This measures how closely the response aligns with the reference source. A threshold of 0.7 is a reasonable starting point. Higher values are stricter.
3. Set the Relevance threshold (0.0 to 1.0). This measures whether the response addresses the user's actual question. A threshold of 0.7 is a reasonable default.
4. Responses that fall below either threshold are blocked.
5. Note: Contextual grounding costs $0.10 per 1,000 text units. The text unit count combines the source document, query, and response characters.

Step 7: Using the ApplyGuardrail API (Model-Independent)

The ApplyGuardrail API decouples the evaluation engine from model invocation. You send text directly to the API, and it returns the evaluation result without calling any foundation model. This enables three critical patterns: applying guardrails to third-party model outputs (OpenAI, Google Gemini), using guardrails with self-hosted models on SageMaker or EC2, and running pre-flight validation on prompts before they enter any model pipeline. For teams using autonomous agents in production, pairing Guardrails with agentic workflows like the AWS DevOps Agent adds an additional enforcement boundary.

Basic API Call (Python Boto3)

import boto3

client = boto3.client('bedrock-runtime', region_name='us-east-1')

response = client.apply_guardrail(
    guardrailIdentifier='your-guardrail-id',
    guardrailVersion='DRAFT',   # or a specific version number
    source='OUTPUT',            # 'INPUT' for prompt checks, 'OUTPUT' for response checks
    content=[
        {
            'text': {
                'text': 'The model response text you want to evaluate goes here.'
            }
        }
    ]
)

# Check the result
action = response['action']   # 'NONE' (passed) or 'GUARDRAIL_INTERVENED' (blocked)
print(f"Action: {action}")

if action == 'GUARDRAIL_INTERVENED':
    for output in response.get('outputs', []):
        print(f"Blocked message: {output['text']}")

    for assessment in response.get('assessments', []):
        print(f"Assessment details: {assessment}")

Integration Pattern for Third-Party Models

To protect an OpenAI or Gemini deployment with Bedrock Guardrails:

1. Send the user's prompt to the ApplyGuardrail API with source='INPUT'.
2. If the action is NONE, forward the prompt to your third-party model.
3. When the model responds, send the response to the ApplyGuardrail API with source='OUTPUT'.
4. If the action is NONE, return the response to the user. If GUARDRAIL_INTERVENED, return the blocked message.

Step 8: Testing and Monitoring Your Guardrails

A guardrail that is not tested is a guardrail you cannot trust. Bedrock provides a built-in test interface in the console, and you should supplement it with programmatic tests before production deployment.

Console Testing

1. In the Guardrails console, select your guardrail and click Test.
2. Choose a foundation model to test against (or use the ApplyGuardrail API mode for model-independent testing).
3. Enter test prompts that should pass and prompts that should be blocked. Document the results.
4. For Automated Reasoning policies (if enabled), AWS now generates test Q&A pairs automatically from your policy documents. Review these generated tests to identify edge cases your policy may not cover.

Monitoring in Production

• CloudWatch Metrics: Bedrock publishes guardrail evaluation metrics to CloudWatch. Monitor GuardrailInvocations, GuardrailIntervened, and GuardrailPassed to track block rates over time.
• CloudWatch Logs: Enable detailed logging to capture which policy type triggered each intervention. This is essential for tuning thresholds.
• CloudTrail: All guardrail API calls are logged in CloudTrail for audit and compliance purposes.

Pricing Awareness

Each enabled filter charges independently per evaluation. For a customer service chatbot processing 100,000 interactions per month (average 3,000 characters per interaction = 3 text units each):

• Content filters: 300,000 text units × $0.15/1K = $45.00
• Denied topics: 300,000 text units × $0.15/1K = $45.00
• PII filters: 300,000 text units × $0.10/1K = $30.00
• Total: $120.00/month for three active policy types

Word filters and regex-based sensitive information filters are free. Contextual grounding costs $0.10/1K text units. Automated Reasoning costs $0.17/1K text units per policy.

Troubleshooting and FAQ

Next Step

Start with a single guardrail using content filters and denied topics on a non-production workload. Monitor the CloudWatch metrics for one week to understand your block rate and false positive rate. Then add PII filters and contextual grounding incrementally. This phased approach lets you tune thresholds based on real data before committing to a full production rollout. For organizations with multiple AWS accounts, evaluate cross-account safeguards to centralize policy enforcement across your entire estate.