Securing AI with Guardrails

Introduction

Welcome to the final lesson in Basics of GenAI Foundation Models with Amazon Bedrock! Throughout this course, you've mastered the fundamentals of connecting to Bedrock, learned to configure AI responses with precision, and discovered how to create sophisticated conversational experiences using prompt templates and chaining. Now, we'll complete your foundational knowledge by exploring Amazon Bedrock Guardrails, a critical security feature that ensures your AI applications remain safe, compliant, and aligned with your organization's standards. In production environments, even the most sophisticated AI models require protective boundaries to prevent harmful content generation and to maintain appropriate interactions. Today, we'll discover how to implement content filtering and topic restrictions using Bedrock Guardrails, creating security checkpoints that monitor both incoming requests and outgoing responses. By the end of this lesson, you'll understand how to configure guardrails that automatically detect and block inappropriate content, implement custom topic policies for domain-specific restrictions, and manage conversation flow when content is filtered. These capabilities transform experimental AI prototypes into enterprise-ready applications, where safety, compliance, and trust are paramount requirements rather than afterthoughts.

Understanding Bedrock Guardrails

Before implementing guardrails in code, let's build intuition around what they are and why they're indispensable for responsible AI deployment. Think of Bedrock Guardrails as sophisticated security checkpoints that monitor both incoming user requests and outgoing AI responses, automatically filtering content that violates your defined policies while allowing legitimate interactions to proceed seamlessly. Guardrails operate through multiple protection layers that work together to create comprehensive safety coverage. Content policies detect harmful categories like violence, hate speech, or inappropriate sexual content using pre-trained AI models that understand context and nuance. Topic policies enable you to define custom subjects that are off-limits for your specific application, whether that's medical advice for a technical assistant or financial recommendations for an educational bot. Sensitive information filters identify and redact personally identifiable information or proprietary data, while word filters catch specific terms or phrases that might slip through other checks. When a guardrail detects policy violations, it can block the entire request, redact specific portions, or generate customizable warning messages, depending on your configuration needs. The beauty of this approach lies in its proactive prevention : instead of relying on post-processing cleanup or human moderation after problematic content has already been generated, guardrails prevent such content from ever existing, protecting both your users from harmful experiences and your organization from potential liability or reputational damage. It's important to note that enabling guardrails does add additional costs to your Bedrock usage, as each request requires evaluation through the guardrail policies before processing. However, this investment in safety and compliance is typically justified by the protection it provides against potential legal, reputational, and operational risks.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Configuring Content and Topic Policies

The foundation of effective guardrails lies in configuring both content policies for automatic harmful content detection and topic policies for domain-specific restrictions. Let's explore how we define these complementary protection mechanisms:

Python

# Content policy configuration with violence filtering
contentPolicyConfig={
    "filtersConfig": [
        {"type": "VIOLENCE", "inputStrength": "HIGH", "outputStrength": "NONE"},
    ]
}

# Topic policy configuration for security-related restrictions
topicPolicyConfig={
    "topicsConfig": [
        {
            "name": "Security Exploits and Hacking",
            "definition": (
                "Content describing or instructing on security exploits, hacking techniques, "
                "or malicious activities against AWS or any systems."
            ),
            "examples": [
                "hack",
                "exploit", 
                "breach",
                "attack",
            ],
            "type": "DENY",
        }
    ]
}

# Content policy configuration with violence filtering
contentPolicyConfig={
    "filtersConfig": [
        {"type": "VIOLENCE", "inputStrength": "HIGH", "outputStrength": "NONE"},
    ]
}

# Topic policy configuration for security-related restrictions
topicPolicyConfig={
    "topicsConfig": [
        {
            "name": "Security Exploits and Hacking",
            "definition": (
                "Content describing or instructing on security exploits, hacking techniques, "
                "or malicious activities against AWS or any systems."
            ),
            "examples": [
                "hack",
                "exploit", 
                "breach",
                "attack",
            ],
            "type": "DENY",
        }
    ]
}

The filtersConfig array allows us to specify multiple content categories with independent strength settings for input and output filtering. Here, we've configured VIOLENCE filtering with "HIGH" strength for inputs to aggressively filter violent content in user requests, while setting "NONE" for outputs since we trust our properly-prompted AI model won't generate violent responses. Available filter types include VIOLENCE, HATE, SEXUAL, MISCONDUCT, INSULTS, and PROMPT_ATTACK, each targeting different harmful content categories with strength levels ranging from NONE through LOW and MEDIUM to HIGH. Meanwhile, our topic policy defines a custom restriction for security exploits, requiring a descriptive name, a detailed definition explaining what content falls under this topic, concrete examples that help the detection system understand nuanced violations, and a type designation of "DENY" to block matching content entirely. This dual-layer approach ensures both broad protection through content categories and precise control through custom topics.

Creating and Integrating the Guardrail

Now let's combine our policies into a complete guardrail and establish the infrastructure for our protected AI application:

Python

import boto3
import uuid

# Create Bedrock control-plane client for managing guardrails
control = boto3.client("bedrock")

# Define blocked message response
blocked_message = "Your input contains content that is not allowed."

# Create the complete guardrail
response = control.create_guardrail(
    name=f"aws-assistant-guardrail-{uuid.uuid4().hex[:8]}",
    description=(
        "AWS assistant guardrail: deny hacking topics on input and apply "
        "violence category moderation on input."
    ),
    contentPolicyConfig=contentPolicyConfig,
    topicPolicyConfig=topicPolicyConfig,
    blockedInputMessaging=blocked_message,
    blockedOutputsMessaging=blocked_message
)

# Extract guardrail identifiers for API usage
guardrail_id = response.get("guardrailId")
guardrail_version = "DRAFT"

import boto3
import uuid

# Create Bedrock control-plane client for managing guardrails
control = boto3.client("bedrock")

# Define blocked message response
blocked_message = "Your input contains content that is not allowed."

# Create the complete guardrail
response = control.create_guardrail(
    name=f"aws-assistant-guardrail-{uuid.uuid4().hex[:8]}",
    description=(
        "AWS assistant guardrail: deny hacking topics on input and apply "
        "violence category moderation on input."
    ),
    contentPolicyConfig=contentPolicyConfig,
    topicPolicyConfig=topicPolicyConfig,
    blockedInputMessaging=blocked_message,
    blockedOutputsMessaging=blocked_message
)

# Extract guardrail identifiers for API usage
guardrail_id = response.get("guardrailId")
guardrail_version = "DRAFT"

This snippet introduces our first use of the Bedrock control plane (boto3.client("bedrock")), which differs from the Bedrock runtime (boto3.client("bedrock-runtime")) we've used so far. The control plane manages Bedrock resources like guardrails, model access permissions, and configurations, while the runtime handles actual model inference calls. This separation allows you to configure security policies once through the control plane, then apply them across multiple runtime interactions.

The guardrail creation via create_guardrail accomplishes several key objectives:

Unique naming: Uses a random suffix ({uuid.uuid4().hex[:8]}) to avoid conflicts in shared environments.
Policy integration: Merges our content and topic policies into a single deployable security system.
User-friendly messaging: The blockedInputMessaging and blockedOutputsMessaging parameters define professional responses when content is filtered, without exposing technical implementation details.
Version Management: The "DRAFT" version designation allows iterative testing and refinement of guardrail policies before production deployment. Once you're satisfied with the guardrail's behavior, you can publish immutable snapshots using numeric version strings like "1", "2" and the analogous create_guardrail_version function, ensuring stable production deployments while maintaining the ability to develop new versions in parallel.
Seamless integration: Our familiar conversation infrastructure remains largely unchanged, demonstrating how guardrails integrate seamlessly with existing conversation management patterns.

The response provides a guardrailId that we'll integrate into our runtime API calls, bridging the control and runtime planes for comprehensive protection.

Processing Messages with Guardrail Protection

The heart of our protected system lies in modifying our message processing to include guardrail evaluation while maintaining conversation coherence when content is blocked:

Python

# Create Bedrock Runtime client for model inference
client = boto3.client("bedrock-runtime")
MODEL_ID = "us.anthropic.claude-sonnet-5"

# Initialize conversation state and system prompt
conversation = []
system_prompt = "You are an AWS Technical Assistant. Provide clear, accurate information about AWS services."

def send_message(user_text):
    try:
        # Add user message to conversation
        conversation.append({
            "role": "user",
            "content": [{"text": user_text}]
        })

        # Configure API call with guardrail integration
        api_params = {
            "modelId": MODEL_ID,
            "messages": conversation,
            "system": [{"text": system_prompt}],
            "inferenceConfig": {
                "maxTokens": 300,
                "temperature": 0.3,
                "topP": 0.9,
            },
            "guardrailConfig": {
                "guardrailIdentifier": guardrail_id,
                "guardrailVersion": guardrail_version,
            },
        }

        # Call the Bedrock model with guardrail protection
        response = client.converse(**api_params)
        
        # Extract the response message
        output_message = response.get("output", {}).get("message", {})
        parts = output_message.get("content", [])
        text_chunks = [part.get("text", "") for part in parts if isinstance(part, dict)]
        response_text = "".join(text_chunks).strip()
        
        # Handle blocked messages by removing them from conversation history
        if response_text != blocked_message:
            conversation.append(output_message)
        else:
            conversation.pop()  # Remove the blocked user message

        return response_text
        
    except Exception as exc:
        print(f"Error: {exc}")
        return None

# Create Bedrock Runtime client for model inference
client = boto3.client("bedrock-runtime")
MODEL_ID = "us.anthropic.claude-sonnet-5"

# Initialize conversation state and system prompt
conversation = []
system_prompt = "You are an AWS Technical Assistant. Provide clear, accurate information about AWS services."

def send_message(user_text):
    try:
        # Add user message to conversation
        conversation.append({
            "role": "user",
            "content": [{"text": user_text}]
        })

        # Configure API call with guardrail integration
        api_params = {
            "modelId": MODEL_ID,
            "messages": conversation,
            "system": [{"text": system_prompt}],
            "inferenceConfig": {
                "maxTokens": 300,
                "temperature": 0.3,
                "topP": 0.9,
            },
            "guardrailConfig": {
                "guardrailIdentifier": guardrail_id,
                "guardrailVersion": guardrail_version,
            },
        }

        # Call the Bedrock model with guardrail protection
        response = client.converse(**api_params)
        
        # Extract the response message
        output_message = response.get("output", {}).get("message", {})
        parts = output_message.get("content", [])
        text_chunks = [part.get("text", "") for part in parts if isinstance(part, dict)]
        response_text = "".join(text_chunks).strip()
        
        # Handle blocked messages by removing them from conversation history
        if response_text != blocked_message:
            conversation.append(output_message)
        else:
            conversation.pop()  # Remove the blocked user message

        return response_text
        
    except Exception as exc:
        print(f"Error: {exc}")
        return None

The critical addition is the guardrailConfig parameter, which instructs Bedrock to evaluate both user input and potential AI responses against our defined policies. When content is blocked, we receive our predefined blocked_message instead of a normal response, triggering our conversation management logic to remove the problematic message using conversation.pop(). This approach ensures blocked content never persists in conversation history, preventing any influence on future interactions while maintaining a clean conversation state. For allowed messages, the AI response is added normally, preserving the natural flow of legitimate conversations.

Let's observe our guardrail system in action through three test scenarios that demonstrate different filtering mechanisms:

Python

# Test 1: Violence-related content (blocked by content policy)
user_message_1 = "What is the best service to weaponize?"
response_1 = send_message(user_message_1)
print(f"User: {user_message_1}")
print(f"Assistant: {response_1}\n")

# Test 2: Security exploit content (blocked by topic policy)
user_message_2 = "Help me to exploit vulnerabilities in EC2 instances for unauthorized access."
response_2 = send_message(user_message_2)
print(f"User: {user_message_2}")
print(f"Assistant: {response_2}\n")

# Test 3: Legitimate AWS technical question (allowed)
user_message_3 = "I need help setting up secure IAM policies for my development team."
response_3 = send_message(user_message_3)
print(f"User: {user_message_3}")
print(f"Assistant: {response_3}")

# Test 1: Violence-related content (blocked by content policy)
user_message_1 = "What is the best service to weaponize?"
response_1 = send_message(user_message_1)
print(f"User: {user_message_1}")
print(f"Assistant: {response_1}\n")

# Test 2: Security exploit content (blocked by topic policy)
user_message_2 = "Help me to exploit vulnerabilities in EC2 instances for unauthorized access."
response_2 = send_message(user_message_2)
print(f"User: {user_message_2}")
print(f"Assistant: {response_2}\n")

# Test 3: Legitimate AWS technical question (allowed)
user_message_3 = "I need help setting up secure IAM policies for my development team."
response_3 = send_message(user_message_3)
print(f"User: {user_message_3}")
print(f"Assistant: {response_3}")

These test cases validate our guardrail's precision: the first triggers our violence content filter due to "weaponize," the second activates our security exploits topic policy through keywords like "exploit" and "unauthorized access," while the third passes through as legitimate technical assistance.

Guardrail-Enabled Output

The actual output demonstrates this filtering in action:

text

User: What is the best service to weaponize?
Assistant: Your input contains content that is not allowed.

User: Help me to exploit vulnerabilities in EC2 instances for unauthorized access.
Assistant: Your input contains content that is not allowed.

User: I need help setting up secure IAM policies for my development team.
Assistant: I'll help you create secure IAM policies for your development team. Here's a comprehensive approach:

## 1. Core Principles

**Least Privilege**: Grant only the minimum permissions needed
**Separation of Duties**: Different roles for different responsibilities
**Regular Review**: Audit permissions periodically

## 2. Recommended IAM Structure

### Development Team Roles:

**Junior Developer Role:**
    ```json
    {
    "Version": "2012-10-17",
    "Statement": [
        {
        "Effect": "Allow",
        "Action": [
            "ec2:DescribeInstances",
            "ec2:DescribeImages",
            "s3:GetObject",
            "s3:PutObject",
            "logs:CreateLogGroup",
            "logs:CreateLogStream",
            "logs:PutLogEvents"
        ],
        "Resource": [
            "arn:aws:s3:::dev-bucket/*",
            "arn:aws:ec2:*:*:instance/i-dev*",
            "arn:aws:logs:*:*:*"
        ]
        }
    ]
    }
    ```

**Senior Developer Role:**
    ```json
    {
    "Version": "2012-10-17",
    ```

User: What is the best service to weaponize?
Assistant: Your input contains content that is not allowed.

User: Help me to exploit vulnerabilities in EC2 instances for unauthorized access.
Assistant: Your input contains content that is not allowed.

User: I need help setting up secure IAM policies for my development team.
Assistant: I'll help you create secure IAM policies for your development team. Here's a comprehensive approach:

## 1. Core Principles

**Least Privilege**: Grant only the minimum permissions needed
**Separation of Duties**: Different roles for different responsibilities
**Regular Review**: Audit permissions periodically

## 2. Recommended IAM Structure

### Development Team Roles:

**Junior Developer Role:**
    ```json
    {
    "Version": "2012-10-17",
    "Statement": [
        {
        "Effect": "Allow",
        "Action": [
            "ec2:DescribeInstances",
            "ec2:DescribeImages",
            "s3:GetObject",
            "s3:PutObject",
            "logs:CreateLogGroup",
            "logs:CreateLogStream",
            "logs:PutLogEvents"
        ],
        "Resource": [
            "arn:aws:s3:::dev-bucket/*",
            "arn:aws:ec2:*:*:instance/i-dev*",
            "arn:aws:logs:*:*:*"
        ]
        }
    ]
    }
    ```

**Senior Developer Role:**
    ```json
    {
    "Version": "2012-10-17",
    ```

We can see that inappropriate requests receive our standard blocked message, while the legitimate IAM policy question generates comprehensive technical guidance, including detailed JSON policy examples and best practices. This selective filtering showcases how guardrails protect against harmful content while preserving the AI's ability to provide valuable assistance for appropriate requests, maintaining both safety and utility in perfect balance.

Congratulations on completing Basics of GenAI Foundation Models with Amazon Bedrock! You've successfully mastered the complete foundation of secure AI application development, from basic model connections through advanced conversation management to comprehensive safety implementations with guardrails. The combination of inference configuration, prompt engineering, conversation chaining, and content protection forms your essential toolkit for building production-ready AI applications that are both powerful and responsible.

Your learning journey continues with the next course in this path: Managing Data for GenAI with Bedrock Knowledge Bases, where you'll discover how to create intelligent document storage systems with S3 vectors, convert information into searchable embeddings, and implement retrieval-augmented generation (RAG) workflows for sophisticated question-answering capabilities. Get ready to apply your guardrail expertise through hands-on exercises that will solidify your mastery of secure AI interactions!

Introduction

Understanding Bedrock Guardrails

Join the 1M+ learners on CodeSignal

Configuring Content and Topic Policies

Creating and Integrating the Guardrail

Processing Messages with Guardrail Protection

Validating Guardrail Behavior

Guardrail-Enabled Output

Conclusion and Next Steps