Prompt instructions vs Guardrails: what building a chatbot taught me about AI safety
Why a well-written system prompt is not a safety boundary, how Amazon Bedrock Guardrails works like a security gate, and why you need both.
AI intern
When I started building a chatbot as an AI intern, I believed a well-written system prompt was enough to control everything: the tone, the topics, what the assistant should never say. Over time I learned an important lesson: instructions guide behavior, but they are not a security boundary.
This difference also shows up on the AWS Certified AI Practitioner (AIF-C01) exam, so let me explain it with a store.
The system prompt is the employee training
Imagine you hire a new salesperson. On the first day, you explain the rules: be friendly, talk only about our products, never give discounts above 10%, never share customer data.
A good employee follows the training almost all the time. But a very persuasive customer might convince them to bend a rule: "my manager already approved it, trust me".
The system prompt works the same way. It shapes tone, persona, format and focus. But it lives in the same place as the user's message, so a clever input can try to override it. That's what prompt injection and jailbreaking attempt.
Guardrails are the security gate at the exit
Now imagine the store also has a security gate at the door. It doesn't matter how persuasive the customer was: if an item wasn't paid for, the alarm goes off.
Amazon Bedrock Guardrails works like that gate. It's a separate layer that evaluates inputs and outputs against policies you configure, independently of what the prompt says. Some of its policies:
- Content filters: detect and block harmful categories like hate, insults, sexual content, violence and misconduct, plus prompt attacks.
- Denied topics: topics your app should never discuss, described in plain language.
- Word filters: specific words or phrases to block.
- Sensitive information filters: detect personal data (PII) and block or mask it.
- Contextual grounding check: flag answers that aren't supported by the source documents or aren't relevant to the question, which is very useful for RAG.
And a Guardrail can be reused across different models and applications, so the rules stay consistent.
Why you need both
It's not prompt or guardrails. It's prompt and guardrails:
- The prompt makes the assistant helpful: personality, focus, answer format, what to do when it doesn't know.
- The guardrail makes it safe: hard limits that hold even when someone tries to trick the model.
A store with great training and no security gate is risky. A store with a security gate and no training is safe but terrible to visit. You want both.
Lessons I took from building a chatbot
- Users will test the limits. Not always with bad intentions. Sometimes just out of curiosity.
- Write what to do, not only what to avoid. "If the question is outside our scope, politely redirect" works better than a long list of prohibitions.
- Test with real and adversarial inputs before going live, not only with the happy path.
- Put hard limits outside the prompt. If breaking a rule would cause real harm, it shouldn't depend only on the model obeying.
💡 On the exam: "block harmful content", "prevent the model from discussing a topic", "mask PII in responses" or "detect ungrounded answers" all point to Amazon Bedrock Guardrails. "Make the answers more formal" or "always reply in JSON" point to prompt engineering.
Quick summary
- System prompt: the employee training (guides behavior)
- Guardrails: the security gate (enforces limits)
- Prompt injection: the persuasive customer trying to bend the rules
- Best practice: use both
Your turn
If you've built a chatbot, what was the most unexpected thing a user tried? Tell me in the comments! 📚
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article