AI chatbot threat model
Goal: map a simple AI chatbot before building it, then identify where AI-specific and normal application risks show up.
Outcome
You should finish with a data-flow diagram, a threat list, and a mitigation plan for a basic AWS-hosted AI app.
Example AWS shape
- Frontend: static site or simple local UI.
- API layer: Amazon API Gateway or an isolated test endpoint.
- Compute: AWS Lambda for request handling.
- Model path: Amazon Bedrock model invocation in a sandbox.
- Logs: CloudWatch Logs for request IDs, errors, and guardrail decisions.
- Secrets: AWS Secrets Manager or environment variables with strict IAM access.
Threats to map
- Prompt injection that tries to override system instructions.
- User input that asks the model to reveal hidden context.
- Model output passed to another system without validation.
- Overly broad Lambda role permissions.
- Logs that accidentally store sensitive prompts or responses.
- Missing rate limits that create cost or abuse risk.
Mitigation checklist
- Define what the chatbot is allowed to answer.
- Define what data must never be pasted into it.
- Use least-privilege IAM for the compute role.
- Validate inputs and outputs before downstream use.
- Log enough for debugging without storing secrets.
- Add rate limits, budget alerts, and a disable switch.
Portfolio artifact
Create a threat model table with columns for asset, threat, impact, mitigation, and verification. This is often more impressive than a fragile demo that has no security story.