How it started
We've all done it — paste something into ChatGPT without thinking twice. Sometimes that "something" has a phone number, an email, or worse.
There's nothing stopping it. No safety check. No filter.
I thought — what if the AI had a security guard? Something that checks every input before the AI sees it, and every output before the user sees it.
So I built it.
What it does
AI Content Guard — a text summarizer with a safety layer.
- Normal text → clean 2-3 line summary ✅
- Phone/email/name in text → hidden as
{PHONE},{EMAIL},{NAME}, summary still generated ✅ - Credit card / SSN → fully blocked, AI never sees it 🚫
- Hate speech, violence, prompt attacks → blocked instantly 🚫
The guardrail runs twice — once on your input, once on the AI's output. Safety before and after.
Architecture
The flow:
User → Amplify (React UI) → API Gateway → Lambda
→ Guardrail INPUT check (block or continue)
→ Bedrock AI Model (generates summary)
→ Guardrail OUTPUT check (block or continue)
→ DynamoDB (log result)
→ Response back to user
Blocked = 0.4 seconds. Success = 1.5 seconds.
Blocked is faster because the AI model is never called.
Why serverless?
- No servers to manage or patch
- Pay nothing when nobody's using the app
- Auto-scales if 100 people hit it at once
- Deploy with one command, tear down with one command
I write code. AWS runs it. That's the deal.
The stack
| Service | What it does |
|---|---|
| Lambda (Python 3.12) | Runs the logic |
| Bedrock (Nova Lite) | AI summarization |
| Bedrock Guardrails | Content safety + PII detection |
| API Gateway | REST API with rate limiting |
| DynamoDB | Audit logs (auto-deletes in 30 days) |
| SSM Parameter Store | Config without redeployment |
| Amplify | Hosts the React frontend |
| CloudFormation | Infrastructure as Code (6 templates) |
Why guardrails matter
This isn't academic. It's a real requirement now.
- Samsung banned ChatGPT after employees leaked code into it.
- EU AI Act requires safety measures. No guardrails = non-compliant.
- India's DPDP Act makes you liable for unprotected personal data.
- One screenshot of your chatbot generating hate speech = your product is dead.
Guardrails solve this at infrastructure level. You don't ask the AI to be safe. You put a wall in front of it.
For students & early-career devs
This project covers what actually comes up in interviews:
- "Have you worked with serverless?" → Yes. Lambda, API Gateway, DynamoDB.
- "How do you handle security?" → Least-privilege IAM, encryption, defense in depth.
- "Tell me about an AI project." → Built a summarizer with guardrails for content safety.
- "How do you deploy?" → Infrastructure as Code. One command.
Companies like Razorpay, CRED, Swiggy use the exact same services. Same patterns. Different scale.
My honest advice: Don't just read this. Clone it. Deploy it. Break something. Fix it.
Nobody cracked an interview by reading about Lambda. They cracked it by using Lambda. Hands-on is the only thing that sticks.
Try it
Live app: https://main.d1244888rwbz47.amplifyapp.com
Source code: https://github.com/Utkarshlearner/ai-content-guard
Run your own:
git clone [your-repo-url]
cd ai-content-guard
./deploy.sh all
./deploy-frontend.sh
5 minutes. Done.
What I learned
- Safety is infrastructure, not prompt engineering.
- Blocked is faster than success (fewer API calls).
- ANONYMIZE ≠ BLOCK — know when to be strict vs lenient.
- Config (SSM) and code (Lambda) should live separately.
- "We'll add safety later" is how companies end up in the news.
About me
I'm Utkarsh. I build on AWS and write about it.
🚀 Your turn
What would you add? Cognito login? Hindi support? Admin dashboard? Slack bot?
Fork it. Build something. Tag me.
Or just drop your ideas in the comments — I'm picking the best ones for the next version.
Build with AI. But build safe. 🛡️
Top comments (0)