Lab: Threat model

Threat modeling is the security engineer's first deliverable on any system: a structured answer to 'what can go wrong, and how bad is it?' You'll produce one for the AI system you bring to this course — the RAG app from Building RAG and/or the agent from Agentic AI, deliberately left un-hardened for these labs. That's your Harbor Lane target throughout, and this threat model is the map that directs every attack and fix in the modules ahead.

Step 1 — Get the target running

1. 1Get the target you'll harden all course. Fastest path: use the ready-made vulnerable stack that ships with this course — the Vulnerable Harbor Lane kit (course-assets/vulnerable-harborlane/): a small support assistant (triage + a tiny RAG + an agent with a refund tool) wired with exactly the holes below. Alternative (bring your own): attack the RAG app you built in Building RAG, the agent you built in Agentic AI, or both wired together — a system you own and understand. Either way you're attacking a system you're authorized to test.
2. 2Confirm the target is deliberately vulnerable — the holes are left in on purpose so you have something real to break. For the labs ahead it must have no input screening, an over-privileged unlimited refund (or equivalent write) tool, secrets in the system prompt, no output checks, and no audit log. The provided kit already has all five (plus an IDOR-style unauthenticated order lookup); if you bring your own, add each one. Every hole is closed by a later module.
3. 3Run one normal request end to end so you understand the intended data flow before you attack it. (For the provided kit: the tools run offline — poke them with python3 app/tools.py; the live agent loop that demos the injection exploits needs your own Anthropic key.)

Step 2 — Draw the data-flow diagram

1. 1Sketch every component and the arrows between them: user → triage → RAG (→ doc corpus) → agent (→ tools → order DB, refund API, ticket system).
2. 2Mark every input channel on the diagram (direct message, retrieved docs, tool results, memory) — the Module-1 attack surface, made visual.
3. 3Draw the trust boundaries as lines the data crosses: untrusted→model, model→code, model→action, action→real system.

Step 3 — Enumerate threats

1. 1For each input channel and boundary, list concrete threats: 'a product review in the corpus contains injection → agent obeys it → issues a refund'; 'a user asks the chatbot to repeat its system prompt'; 'the agent's DB tool has write access it doesn't need'.
2. 2Tag each threat with its OWASP category (injection, disclosure, excessive agency, improper output handling…). The tag connects your specific finding to the shared map and the known defenses.
3. 3Aim for 10–15 threats. Breadth now; depth in the later modules.

Step 4 — Rank by risk

1. 1Score each threat: likelihood (how easily could an attacker reach it?) × impact (blast radius at that boundary — data exposed? money moved? irreversible?).
2. 2Sort. The top of this list is your work order for the whole course — you'll attack and fix in risk order, exactly as a real assessment would.
3. 3Save THREAT-MODEL.md. It's living: every attack you land and every fix you ship updates it, and it becomes the backbone of your capstone report.