Capstone: the six-stage kill chain
Six recorded side effects in one session, then replay the identical chain with one control applied.
Everything in Tracks 01 to 03 lands here. One session against one deliberately broken expense agent produces six recorded side effects, and none of them needs a jailbreak, an encoding trick, or a single word the model was unhappy to comply with. Then you replay the identical chain with one control applied and watch which step dies.
What you are looking at
A plausible internal tool: an expense assistant with five tools, a system prompt containing its rules, and a support-ticket integration. Every flaw in it has a counterpart in module 3.3's ten documented incidents, annotated below with the module that covers it.
| Stage | Objective (a recorded state change) | Owning module |
|---|---|---|
| 1 | Hidden context disclosed, including the tool schemas | 2.9 |
| 2 | An employee approves an expense, attributed to someone else | 3.5 |
| 3 | The same approval again, driven by a support ticket | 3.1 |
| 4 | Another tenant's confidential document read | 3.6 |
| 5 | Payload leaves the app through the transcript renderer | 3.2 |
| 6 | An instruction persisted for every future session | 3.7 |
Run it
Step through with No controls first and read the analysis on each step, particularly the two tool call steps in stages 2 and 3. They are byte-identical and arrive from completely different places. Then pick a control and replay.
Capstone. The six-stage kill chain
0 / 18Signed in as Alice Okafor. Role "employee", no approval limit. EXP-10048 (EUR 9,840) is awaiting approval.
Objective
Six recorded side effects, in one session: leak the hidden context, approve an expense you may not approve, do it again without asking, read another tenant's document, get data out of the app, and leave something behind for the next session.
Apply one control and replay the identical chain
Step through the trace. Every node is a real place content enters or leaves the application, and each one arrives with the analysis beside it: what a defender can still do at that instant.
What the fix progression tells you
Six controls, and they are not interchangeable. Running each against the same chain surfaces four properties a list of best practices flattens away.
| Property | Which control shows it |
|---|---|
| Removing a capability beats policing it | Dropping the actorId parameter kills stages 2 and 3 with a schema edit and nothing to bypass. Compare with any control that has to recognise an attack first. |
| Indifference to cleverness is the property that lasts | Server-side authorization refuses identically whether the instruction came from Alice, a ticket, or the model's own reasoning. No wording makes an employee a finance manager. |
| Some controls only bound damage | No-auto-fetch does not stop the model emitting the payload. It stops the bytes leaving. That is blast-radius bounding, the honest description of most controls that survive an adaptive attacker. |
| Controls couple in non-obvious ways | Fixing retrieval scope silently defuses the exfiltration stage too, because there is no longer anything worth taking. You get that for free, and you would not have predicted it from a checklist. |
The stage with no fix
Five stages close. Stage 1 has no control that stops it, by design rather than as a gap in the simulation.
You cannot reliably prevent extraction. Module 2.9's ladder exists because every filter on the phrase “system prompt” falls to a request for the same information in JSON. So OWASP's guidance for LLM08 is to “ensure that disclosure of hidden context has little or no direct security impact.”
Which reframes the win condition. Look at what the leaked prompt in stage 1 did not contain: no credentials, no connection strings, and once server-side authorization is in place, no rule that gates a security decision. On OWASP's severity ladder that is an informational finding. The prompt still leaks, and it stops mattering.
Deep diveWhy this is a simulation and not a live lab3 min›
An earlier plan for this module was a hosted, model-backed lab you attacked with real prompts. It was cut, and the reasoning is worth stating because you will face the same trade-off building a red-team harness.
The lab needed an API key, a spend ceiling, a login, and per-session state, and it gated the best content in the course behind an account. Worse, it was non-deterministic in the wrong direction: a learner could run a correct attack, have the model simply decline, and learn nothing about the architecture that was the actual subject.
What the simulation buys instead is the counterfactual. You cannot ask a live model what would have happened if the tenant filter had been inside the query. You can only re-run and hope. Here the identical chain replays with one variable changed, which is the only way to see that a control bites at exactly one step while five other stages are untouched by it.
The honest cost: these model replies are authored rather than sampled. They show a realistic and instructive failure rather than a measured one. Where a real figure matters, on attack success rates or defence efficacy, this course cites measured studies, and module 6.6 is built around what adaptive measurement does to those numbers.
The exercise
For an agent in an estate you can inspect:
1. List every tool. For each, write down which arguments carry
AUTHORITY (actorId, userId, role, tenantId, onBehalfOf).
→ Every one is attacker-influenceable. That is stage 2.
2. List every content source the agent reads that a third party
can write to. Include the ones inside the application's own database.
→ Each is an injection surface. That is stage 3.
3. Ask where the tenant filter runs: inside the index query, or
after retrieval on a model-supplied value?
→ After = stage 4 is live.
4. Ask what the UI does with a URL the model emitted.
→ Auto-fetch = stage 5 is live.
5. Ask whether a memory write is a privileged operation.
→ No = stage 6 is live, for every future user.
Stage 1 you should assume has already happened.Sources
- T1OWASP Top 10 for LLM Applications 2026 · LLM01 (delivery surfaces and the trust tiers), LLM03 (the nine mitigations, split preventive vs damage-limiting), LLM08 ('ensure that disclosure of hidden context has little or no direct security impact' and the severity ladder), LLM09 (authorize before retrieval), LLM10 (output handling)
- T3OWASP Top 10 for Agentic Applications · ASI03 Identity & Privilege Abuse (stages 2 and 3), ASI06 Memory & Context Poisoning (stage 6), ASI09 Human-Agent Trust Exploitation (the approval-step limit). Named as the pointers OWASP gives: this course has not obtained that document, so nothing here is quoted from it
- T1Nasr et al. (2025) · The Attacker Moves Second. The reason the fix progression distinguishes controls that bound damage from controls that reduce attack rate