Covers: Definitions; The model; Results; Design rules; Interview questions, with the follow-ups; Common mistakes; What the example does not do.
Definitions
Asset, threat, vulnerability, risk
Asset: something worth protecting (customer data, credentials, the ability to refund).
Threat: something that could go wrong (an attacker reads the data).
Vulnerability: a weakness that lets a threat happen.
Risk: likelihood and impact of a threat, given the controls.
Trust boundary, data-flow diagram
Trust boundary: a line across which data moves between different levels of trust.
Data-flow diagram (DFD): external actors, processes, data stores and flows, with trust boundaries.
STRIDE
STRIDE: a checklist of six threat types: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege.
Attack tree, minimal cut
Attack tree: a goal broken into AND and OR sub-goals down to concrete steps.
Cut: a set of mitigations that makes every path to the goal impossible; a minimal cut is the cheapest such set.
The model
Seven nodes and six flows with trust zones; flows without controls toward higher trust are red.
Threat counts from the mechanical enumeration:
Category
Count
Spoofing
5
Tampering
10
Repudiation
7
Information disclosure
10
Denial of service
10
Elevation of privilege
2
Prompt injection (added)
2
Total
46
Results
Step
Result
Flows into higher trust with no control, before
customer to agent, web to agent, agent to tools
After validation, quarantine, authorisation and approval
none
Mitigation set
Probability the goal succeeds
None
43.3%
Egress allowlist only
33.2%
Least privilege only
28.9%
Quarantine only
33.2%
All seven
0%
Cheapest blocking set (least privilege, tenant filter, trace ACL; cost 5 of 12)
0%
Probability by attack path, mitigation what-ifs and the cheapest blocking set.
Enumeration is cheap; prioritisation is the value. One structural rule (trust gap without control) cut 46 threats to three flows to fix first.
Single controls reduce risk, but only a cut removes it when several independent paths exist.
Shared controls are worth more than their price: least privilege appears in the cheapest set because it blocks two paths.
The unfixable step can stay unfixed if the chain is broken elsewhere.
Design rules
Start with assets and the attacker's goals, not with a list of attacks.
Draw the data-flow diagram with trust boundaries, including the model, tools, memory, vector stores, traces and third-party services.
Enumerate with STRIDE per element, add agent-specific threats (injection, excessive agency, memory poisoning, tool and supply-chain risks, data leakage through traces) and check the MAESTRO layers.
Flag trust-boundary crossings without controls first, and egress channels separately.
Use attack trees for the top goals, with explicit assumptions; record who provided each number.
Pick mitigations by covering all paths, counting shared controls, and keep a cost.
Record decisions: mitigate, accept (with an owner and a date), transfer or avoid.
Tie each mitigation to a test (module 8) and to monitoring (Level 9).
Revisit on change: new tool, new data source, new model, new tenant, new region.
Keep it short and living: a one-page model that is updated beats a long one that is not.
Interview questions, with the follow-ups
How do you threat-model an agent?
"I list assets and attacker goals, draw a data-flow diagram with trust boundaries including the model, tools, memory and traces, enumerate threats with STRIDE plus agent-specific ones such as prompt injection and excessive agency, and prioritise by trust-boundary crossings without controls and by impact. For key goals I build an attack tree and search for the cheapest set of controls that cuts every path. Then I turn each control into a test." Follow-up: "What is different about agents?" Untrusted text can become actions, autonomy and tools widen the attack surface, and memory and traces create new data stores; the book's MAESTRO framework adds layers for these.
Why use an attack tree?
"It makes the attacker's options explicit as AND and OR steps, so I can compute likelihood and cost and see which control cuts several paths. In my example a least-privilege control cut both the injection and credential paths and appeared in the cheapest blocking set." Follow-up: "Where do the probabilities come from?" From incident data where it exists, expert estimates otherwise; I mark them as assumptions and test sensitivity, because the ranking can change.
You cannot stop the model from following injected instructions. What then?
"Break another step in the chain: no private data in the same session, no outbound channel, or an approval on the sending action. In my tree the 'model obeys' step stayed unmitigated and the goal was still blocked." Follow-up: "Is that enough?" It blocks the modelled paths; unknown paths remain, so I add monitoring and red-teaming (module 8).
STRIDE or something else?
"STRIDE is a good checklist for components and flows. For agents I extend it with injection and excessive-agency threats and look at layered frameworks such as MAESTRO, which the book describes as seven layers from foundation models to the agent ecosystem. The framework matters less than doing it early, with the diagram, and keeping it current." Follow-up: "What about scoring?" Scores such as CVSS or DREAD give a sort order, not an objective risk; I use them for triage and show assumptions.
Common mistakes
Starting from tools or attacks instead of assets and goals.
No trust boundaries on the diagram, or the model drawn as one trusted box.
Forgetting memory, traces, vector stores and third-party services.
One-off threat model never updated.
Listing threats without decisions, owners or tests.
False precision from made-up probabilities.
Counting similar mitigations as independent.
Ignoring egress and focusing only on inbound threats.
What the example does not do
Fictional system and assumed numbers; nothing here is evidence about real systems.
STRIDE counts are mechanical: many of the 46 threats are duplicates or low impact, and a human must judge them.
Only inbound trust gaps are flagged; the email flow leaves the boundary and needs a separate egress rule.
No scoring framework (CVSS, DREAD) and no sensitivity analysis of the probabilities.
Probabilities are treated as independent across leaves; real attackers adapt and steps correlate.
Brute-force cut search is fine for seven controls and impractical for hundreds.
No tool support such as a threat-modelling tool or MAESTRO templates.
Optional real experiment (I did not run this): threat-model a real agent with a colleague in one hour, record the top five threats and decisions, and check each against a test.
Check yourself
You list the threats and mitigate each one separately. What does that miss? (Shared controls. Least privilege cut two attack paths at once; picking mitigations is a covering problem, not a per-threat checklist.)
For the curious A model is only as good as its inputs
For the fictional system, one control at a time left 33.2 percent (egress allowlist), 28.9 percent (least privilege) and 33.2 percent (quarantine) success for the attacker; all seven controls left 0. The cheapest set that blocked every path cost 5 of 12. The probabilities and costs are my assumptions: the value is the structure and the trace from threat to control to test.
What you will use daily at work
Practice
What it looks like
Draw the data flows and trust boundaries
Then ask what can go wrong at each.
Add prompt injection to the list
Any flow from less trusted data into a model.
Give each threat a decision
Mitigate, accept, transfer or avoid; with an owner.
Link each control to a test
Red-team cases in the next module.
Draft: confirm which threat-modelling framework your team uses; the framework descriptions here are from secondary sources.
What you must be able to say (one page)
Threat modelling is a structured way to ask four questions: what are we building, what can go wrong, what will we do about it, and did we do a good enough job? It turns "security" into a list of concrete threats tied to components and flows, each with a decision (mitigate, accept, transfer or avoid).
Method 1: data-flow diagram plus STRIDE per element. Draw processes, data stores, external actors, data flows and trust boundaries, then apply STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) to each element type. STRIDE is general knowledge (not re-checked). For my fictional support agent (7 nodes, 6 flows) the mechanical enumeration produced 46 threats; the real work is not the list but the prioritisation, which here came from one rule: 3 flows cross from a less trusted to a more trusted element with no recognised control (customer to agent, web content to agent, agent to tools). Adding validation, quarantine, authorisation and approval to those flows cleared all three.
Agents add threats STRIDE does not name. I added a marker "P" (prompt injection) for any flow from a less trusted source into a model node (2 found). Traditional frameworks such as STRIDE or PASTA often fall short for autonomy, dynamic learning and multi-agent interaction. MAESTRO (Cloud Security Alliance) is a seven-layer reference architecture for agents: foundation models, data operations, agent frameworks, deployment and infrastructure, evaluation and observability, security and compliance, and the agent ecosystem. It advises starting from a system diagram, assessing assets and entry points per layer, scoring risks and simulating attacks by red teaming. I applied none of MAESTRO's scoring; I only used its layers as a checklist.
Method 2: attack trees. Put the attacker's goal at the root, break it into AND and OR steps, give each step a probability and cost, and compute the probability of the goal and the cheapest attack. For "customer table leaves the company" I modelled four paths (injection through the agent, stolen service credential, insider reading traces, vector-index leak) with assumed numbers: baseline success probability 43 percent; by path 15.1, 6.0, 21.0 and 10.0 percent.
What-if on mitigations. Applying one control at a time: egress allowlist 33.2 percent, least privilege 28.9 percent, quarantine 33.2 percent; all seven controls 0. A brute-force search for the cheapest set that blocks every path found least privilege, tenant filters and trace access control at cost 5 of 12. Notice that this set never touches the step "model obeys the planted instruction": you do not need to stop the model from being fooled if another step in the AND chain is removed. This matches module 1's "assume breach".
Shared controls change the answer. Least privilege cuts two paths at once; without it the cheapest set needed four controls (also cost 5). Choosing mitigations is a covering problem, not a per-threat checklist.
A threat model is only as good as its inputs. My probabilities and costs are assumptions; the value is the structure, the discussion and the traceability from threat to control to test (module 8).
Honest limits: fictional system, assumed numbers, mechanical STRIDE counts, no scoring system such as CVSS, no validation of the model against real incidents.