During threat modelling, we ask four major questions. These questions help the security engineer, developer, solutions architect and even the product owner to really understand the product and its potential threats.
1.What are we building?
2.What can possibly go wrong?
3.What can we do about it?
4.Have we done a good job?
Now let’s answer each question.
- What are we building?
From the quoted diagram, it’s likely a web application with an AI chat interface (maybe AI support or something similar).
- What can possibly go wrong?
This is where most of the work is done.
There’s no one-size-fits-all here; the way person A thinks about a possible scenario will be different from person B.
There are several threat modelling techniques that can help you list what can go wrong. The most popular and battle-tested is STRIDE. It stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
Now let’s take each letter in STRIDE and draft potential attack scenarios (2 each).
S – Spoofing
1. Attacker steals a session / abuses weak auth and logs in as a user.
2. Attacker calls the AI Model API directly (no mTLS/API key), pretending to be the web app.
T – Tampering
1. Requests/responses between Web App —> AI API —>DB can be modified if there’s no TLS or signing.
2. Compromised admin panel on the shared host edits chat history or user records in the DB.
R – Repudiation
1. User denies sending a prompt because actions aren’t strongly logged with signed audit trails.
2. Admin/dev denies exporting or viewing sensitive chats since access isn’t logged per identity.
I – Information Disclosure
1. Shared hosting leak gives an attacker DB creds / env vars and full user data.
2. Logs store full chats + PII in plaintext, accessible to anyone with log access or via a breach.
D – Denial of Service
1. Bot floods the AI Model API, exhausting DB connections and making the app unusable.
2. Unbounded chat history + logs fill disk and crash the shared host.
E – Elevation of Privilege
1. Bug/RCE in the web app on the shared host lets an attacker reach the DB and AI API with system-level rights.
2. Poor route protection lets normal users hit admin endpoints or debug AI API paths with admin powers.
- What can we do about it?
Now that we’ve identified potential attacks, this is where you tell architects to redesign or you draft security requirements / mitigation controls. For example:
1. Use strong authentication & API authorization (JWT/mTLS/API keys per service).
2. Enable full TLS + request signing and integrity checks between all components.
3. Implement immutable audit logs with user-specific attribution (timestamp + IP + action).
4. Encrypt all sensitive data at rest, redact/mask logs and apply data minimization.
5. Add rate limiting, WAF and resource throttling (timeouts & quotas) to prevent abuse.
6. Apply strict RBAC, least privilege and network segmentation (avoid shared hosting).
- Have we done a good job?
This is where you reflect as a team: review the identified issues using STRIDE and check if your security requirements capture most of the major/likely security issues.