Day 6 : Make AI Chatbot Safer with Amazon Bedrock Guardrails
how to add Amazon Bedrock Guardrails to your AI chatbot to filter content, block unwanted topics, and protect sensitive information.
For example, someone might ask about unrelated content , try to get the model to ignore its instructions, or enter an email address into the chat.
For a class-notes assistant, we need more control over what goes in and what comes out.
Today, I'll add Amazon Bedrock Guardrails to help filter harmful content, block a topic we don't want, and detect or mask selected types of personal information.
What is a guardrail?
Think of a security guard standing at two doors.
- Before the AI answers: the guardrail can evaluate the user's question.
- After the AI generates an answer: the guardrail can evaluate the response.
If a configured policy is triggered, the guardrail can block the content or mask selected sensitive information, depending on the policy.
Guardrails don't make an AI system perfectly safe. They add another layer of protection that we can configure and test.
Which guardrail policies will we configure?
Amazon Bedrock Guardrails provides several policies. For this tutorial, we'll use three:
- Content filters: help filter harmful content and prompt attacks.
- Denied topics: help block topics we define as unwanted for our application.
- Sensitive information filters: detect selected personal information, such as email addresses, and mask or block it.
A denied-topic policy isn't a complete allowlist. Blocking sports doesn't automatically guarantee that the chatbot will only answer questions about class notes. We'll need to test that limitation.
Before you start
You'll need:
- The classic Knowledge Base and chat app from Day 5 .
- An AWS identity with permission to create and use Guardrails.
- Your Knowledge Base ID and model configuration from Day 5.
- Around 20–30 minutes for configuration and testing.
We'll use the classic Knowledge Base from our earlier tutorials.
Step 1: Create a guardrail
- Open the Amazon Bedrock console .
- Find Guardrails in the navigation menu.
- Choose Create guardrail.
- Give it a name, such as
class-notes-guardrail. - Configure the blocked messages if those options appear in your console.
For example, you could use:
- Blocked input message: "Sorry, I can't help with that request."
- Blocked output message: "Sorry, I couldn't provide that response."
The first message is for a request that gets blocked. The second is for a generated response that gets blocked.
Console labels may change as AWS updates the service, so follow the options shown in your account.
Step 2: Configure content filters
Content filters can evaluate categories such as hate, insults, sexual content, violence, misconduct, and prompt attacks.
A prompt attack is an attempt to get the model to ignore its instructions or bypass its intended safeguards.
- Open the content-filter configuration.
- Enable the categories relevant to your use case.
- Choose a filter strength for each category.
- For this experiment, start with Medium and adjust after testing.
The strength affects how sensitive the filter is. A stricter setting can block more content, but it can also block some legitimate requests.
Language note: Language support depends on the guardrail tier and policy. The Classic tier supports English, French, and Spanish for its content filters and denied topics; the Standard tier supports a broader range. Check the current AWS documentation if your users will write in other languages.
Step 3: Add a denied topic
Let's try to stop the chatbot from discussing sports and entertainment when those topics are unrelated to our class-notes use case.
- Open Denied topics.
- Add a topic named
Sports and entertainment. - Use a clear definition, such as:
"Questions about sports competitions, sports results, movies, and celebrity entertainment." - Add sample phrases if the console provides that option.
For example:
- "Who won the last Cricket World Cup?"
- "Tell me about a famous actor."
Denied topics evaluate the meaning of a request, not just exact keyword matches. However, detection isn't perfect, so we'll test several phrasings.
Important: This policy blocks the topic you define. It doesn't guarantee that every other unrelated topic will be blocked.
Step 4: Configure sensitive information filters
Now let's test what happens when someone enters personal information.
- Open Sensitive information filters.
- Select the types you want to detect, such as email addresses and phone numbers.
- Choose Mask or Block, depending on your intended behavior.
Masking replaces detected information with a placeholder. Blocking rejects content that triggers the configured policy.
For our experiment, we'll use a fake email address rather than real personal information.
A privacy reminder: Masking in a model interaction doesn't automatically remove the original text from your Streamlit chat history, logs, or other application storage. Check what your app stores and displays before handling real personal information.
Step 5: Create a version
Once you've configured the policies:
- Review your settings.
- Create the guardrail.
- Copy the Guardrail ID.
- Test the working draft, labelled
DRAFT, before creating a numbered version. - Once you've tested the configuration, create a version and copy its number.
A numbered version is a snapshot of the configuration at that point. If you change the draft later, your application won't automatically use those new settings unless you update the version it references.
Step 6: Test before connecting the app
Before changing our Python code, use the Guardrails test panel in the console.
Try these three inputs:
Test 1 — Unwanted topic
"Who won the last Cricket World Cup?"
Expected result: the denied-topic policy should block the request if it detects the topic.
Test 2 — Personal information
"My email is My email is student [at] example [dot] com. What is a deadlock?"
Expected result: the configured email filter should mask the email or block the request, depending on the policy and how it evaluates the input.
Test 3 — Normal question
"What is a deadlock?"
Expected result: the question should remain usable if it doesn't trigger any configured policy.
Record what actually happens. Don't assume a policy works just because it is enabled.
Step 7: Connect the guardrail to our chat app
Let's return to
app.py from Day 5 and connect our guardrail to the existing Knowledge Base request.a. Add the guardrail settings
Near the top of
app.py, add your Guardrail ID and version:1
2
GUARDRAIL_ID = "YOUR_GUARDRAIL_ID"
GUARDRAIL_VERSION = "DRAFT" # Use your numbered version in productionReplace
YOUR_GUARDRAIL_ID with the ID from the Amazon Bedrock console.Use
DRAFT while testing if your setup supports it. Otherwise, use the numbered version you created.b. Update the Knowledge Base configuration
Find the existing
params dictionary containing your retrieve_and_generate request.Inside its
knowledgeBaseConfiguration, add generationConfiguration with the guardrail settings:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
params = {
"input": {
"text": user_input
},
"retrieveAndGenerateConfiguration": {
"type": "KNOWLEDGE_BASE",
"knowledgeBaseConfiguration": {
"knowledgeBaseId": KB_ID,
"modelArn": MODEL_ARN,
"generationConfiguration": {
"guardrailConfiguration": {
"guardrailId": GUARDRAIL_ID,
"guardrailVersion": GUARDRAIL_VERSION
}
}
}
}
}Important: This is an example of the request structure, not a complete replacement for every Day 5 app. Keep your existing variable names, retrieval settings, and other configuration. If your app uses a conversation
sessionId, preserve that logic too.c. Show when a guardrail intervenes
Find the code where you receive the response from
retrieve_and_generate and extract the generated answer.For example:
1
2
3
4
5
6
7
8
response = bedrock_agent_runtime.retrieve_and_generate(
**params
)
answer = response["output"]["text"]
if response.get("guardrailAction") == "INTERVENED":
answer = "🛡️ Guardrail intervened\n\n" + answerThis adds a small indicator when the response reports a guardrail intervention. The response may already contain a blocked or masked result, so don't assume that every intervention means the entire answer was blocked.
d. Run and test the app
Restart your Streamlit app and test these three prompts:
- Unwanted topic: "Who won the last Cricket World Cup?"
- Personal information: "My email is student [at] example [dot] com. What is a deadlock?"
- Normal question: "What is a deadlock?"
Record what actually happens for each prompt. A denied-topic policy should block the sports question if it detects the defined topic; the email filter should mask or block matching information according to your configuration; and the normal question should remain usable if no policy is triggered.
If you get an error, double-check your Guardrail ID, version, AWS permissions, and the structure of your existing request.
The third row is especially important. A good configuration should help filter unwanted content without unnecessarily breaking normal questions.
One more experiment: Can the guardrail be too strict?
Try your normal class-notes question with your original filter settings. Then increase the filter strength and ask it again.
Did the normal question still work, or did the guardrail block it?
This experiment teaches us that stricter filtering isn't always better for every use case. We need to balance safety with usefulness.
My takeaway: Guardrails are configurable safety controls, not a magic shield. We need to test both the requests they block and the legitimate questions they allow.
What guardrails can't do
- They reduce risk, not eliminate it. Some unwanted requests may still pass through.
- They can produce false positives. A legitimate question may be blocked.
- A denied-topic policy isn't a complete topic allowlist. It only targets the topics you define.
- Masking isn't complete application-level privacy protection. Your application must also handle chat history and logs carefully.
- A source citation doesn't guarantee that every claim is correct. Continue verifying answers against your documents.
For a class-notes chatbot, combine Guardrails with clear application instructions, sensible access controls, and tests based on realistic questions.
Common mistakes
| Problem | Possible cause | What to check |
|---|---|---|
| AccessDeniedException | Missing permissions | Check your IAM permissions and access to the relevant resources |
| Guardrail seems ignored | Wrong ID, version, or request configuration | Check the guardrail ID, version, and generationConfiguration nesting |
| Normal questions are blocked | Filters may be too strict or a denied topic is too broad | Review the policy and test again |
| Personal information isn't masked | The selected type wasn't configured or detected | Check the filter settings and test with fake data |
| Results differ by language | The policy may not support that language as expected | Review current language support and test representative prompts |
These are starting points for troubleshooting; the exact cause depends on the error and configuration.
Costs and cleanup
Guardrails are billed according to the policies used and the amount of content evaluated. Model inference and other Knowledge Base services may add separate charges.
Before experimenting, check the official Amazon Bedrock pricing page and keep your AWS Budget alert enabled.
Tomorrow, we'll review the resources created throughout the series and identify what to clean up so we don't leave unnecessary services running.
Summary
- Guardrails evaluate user inputs and model responses.
- We configured content filters, a denied topic, and sensitive-information filters.
- We connected the guardrail to our classic Knowledge Base request.
- We tested both unwanted prompts and normal questions.
- Guardrails reduce risk, but they don't guarantee perfect safety.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article