Threat-model the deployment, not the catalog. A data-flow diagram, an impact assessment and an attack tree on one specific agent find risks no generic threat list ranks correctly. The worked example’s central finding is that a control which looks decisive can leave overall risk completely unchanged.

The mechanism

The catalogs are inputs to a model the firm owns, and they are insufficient rather than wrong. Microsoft’s own agentic failure taxonomy explicitly disclaims completeness. OWASP notes that STRIDE and PASTA are rooted in traditional cyber vulnerabilities and must be expanded or mapped to AI vulnerabilities, and deliberately follows no single methodology itself.

The sequence worth copying comes from MATRA, a peer-reviewed workshop framework that adapts NIST SP 800-30 risk methodology to a specific agent deployment. Four stages, impact-first:

1. System analysis. A data-flow diagram naming processes, data stores, external actors and trust boundaries. This is the step people skip and the one that does the work.
2. Impact assessment. Rate business impact on confidentiality, integrity and availability before enumerating threats, so the exercise stays anchored to what the firm would actually mind losing.
3. Attack tree construction. Decompose each impact into architecture-specific paths.
4. Risk quantification. Combine likelihood and impact per node.

Two scoring lenses matter, and running only the first is the common mistake: weakest-link risk (the single easiest path) and full attack surface (everything reachable). The second is what shows whether a mitigation moved the number.

The worked finding is the reason this page exists. MATRA’s case study models a real self-hosted personal-agent runtime with shell, file, browser, messaging and memory access, the exact shape of a capable citizen agent. Applying the obvious control, sandboxing the execution path in Docker with networking disabled, blocks curl-and-exec exfiltration entirely. Overall risk stays Very High, because the messaging tools and the rendered-markdown channel run outside the container. The sandbox is real, the improvement on the weakest-link lens is real, and the full-surface risk did not move. That is the most useful thing here, the numerical version of the argument that cutting one leg of the lethal trifecta only counts if it is cut everywhere it exists.

A threat model needs no ceremony. The design-patterns paper’s ten case studies each state the attacker’s capability and the attacker’s goal in two sentences, then score candidate designs on utility and security separately. Two sentences and a table is a usable threat model; a twelve-page document nobody rereads is not.

Two published components can be lifted rather than written. OWASP’s KC6 grades agent capability into limited versus extensive across API access, code execution and database access (read-only or parameterized versus full CRUD) and maps privilege compromise as highest-risk precisely in the extensive tiers, a ready-made rubric row. A threat model of the Model Context Protocol decomposes it into five components (host and client, LLM, server, external data stores, authorization server) across 57 threats, published as an editable Threat Dragon file rather than only as a paper, so a firm running MCP starts from someone else’s model of MCP.

The composition finding is worth carrying into every model a firm builds: rate paths rather than findings. In a measurement study of real remote MCP servers, two individually unremarkable OAuth flaws (an open redirect and a PKCE downgrade) chain into full account takeover: a mutated redirect URI plus a stripped code challenge means the authorization code is issued with no recorded challenge and can be exchanged with no verifier. (The researchers report obtaining CVE identifiers; no public advisories were resolvable at the time of writing.)

If four stages is too much for a tier-2 agent, Microsoft documents a lighter repeatable pass: take a concrete use case, walk it against six responsible-AI principles, plot impact against likelihood, and commit to one action plus one recurring habit for the top two or three risks. It is reusable at design, pre-release, post-incident and in ongoing operations. Underneath either version sit the Threat Modeling Manifesto’s four questions, which remain the skeleton when everything else is stripped away: what are we working on, what can go wrong, what are we going to do about it, did we do a good enough job.

One ordering principle comes from an unexpected direction. A legal practitioner’s framework argues that liability provisions get drafted before anyone defines what the system does, accesses or decides, and that the ordering is backwards: visibility, then autonomy mapping, then system access, then decision-authority boundaries, then liability. Responsibility should follow control, and control should follow visibility. That is one lawyer’s proposal with no adoption evidence, and it is the right sequence.

What to do

Draw the data-flow diagram first, on one page, by hand. Processes, data stores, external actors, trust boundaries. Then ask the trifecta question of it: does anything on this page read untrusted input, touch sensitive data, and reach the network. If yes, the model’s centre is found before anything gets written down.

Assess impact before enumerating threats. Starting from the catalog produces a long list ranked by someone else’s context; starting from “what would we mind losing” produces a short list ranked by the firm’s own.

Score both lenses and report both. A mitigation that improves weakest-link risk and leaves full-surface risk unchanged is exactly the Docker finding above, and reporting only the first is how a control becomes a claim.

Write the attacker in two sentences: what they can do, what they want. A team that cannot has no threat model yet.

Reuse published component models: the MCP threat model is downloadable and editable, and OWASP’s KC6 capability grading drops straight into a rubric. Model the composition, which is firm-specific; don’t re-derive the components, which are not.

Attach it to the gate. The full pass belongs at promotion for agents above the lowest tier, redone on scope change rather than on a calendar, with residual risk recorded in the registry so someone can see it later.

How you’d know it’s working

Gate reviews produce agent-specific findings the generic catalogs missed. If every threat model in the registry reads the same, that is a template being filled in.

At least one proposed control has been rejected because it didn’t move full-surface risk. That is the exercise doing its job rather than ratifying decisions already made.

Someone can produce last quarter’s threat model for a named agent and say what changed. A model nobody revisits is a document, not a control.

What this doesn’t solve

The numbers are structured expert judgment, not measurement. MATRA says so in its own limitations section: coarse scales and auditable per-node ratings bound the subjectivity, and calibration would need red-teaming-benchmark or operational-log data that nobody has. The same applies to the MCP paper’s DREAD scores, which are author-assigned. Treat all of it as ordering, never magnitude, and never quote a score without its scale.

Completeness is bounded by the analyst’s catalogs, which the framework’s authors also concede. A threat nobody at the firm has heard of never appears in the attack tree, and the surveys that would broaden the catalog (a seven-layer decomposition of the agentic stack, for instance) are single-author and unreviewed, useful scaffolding rather than authority.

A threat model is a snapshot. Nothing in it monitors drift, and an agent whose behaviour is generated rather than written changes between models. Pair it with runtime guardrails and re-run on model or scope changes.

It scales only with triage. Doing this properly for every agent in a sprawling estate is impossible, and tiers exist for that reason: the agents nobody modelled are the ones nobody scored rather than the ones scored low.

Finally, it inherits the modeller’s blind spots, and the pre-agentic guidance closest to hand inherits worse ones. AWS’s AI threat-modelling material predates tool use, MCP and delegation entirely, and elsewhere prescribes input validation to segregate data from instructions, which this wiki argues against as a primary control, so it serves as lineage rather than as current guidance.

See also

• The lethal trifecta — the first question the data-flow diagram has to answer.
• Risk-tier assignment — which agents earn the full four-stage pass.
• Promotion gates — where the threat model is required and reviewed.
• Data exfiltration — the impact the worked example’s attack tree lands on.
• Sandboxing — the control the case study shows is necessary and, on its own, insufficient.
• MCP — the component model not worth re-deriving.
• Templates and checklists — the printable version of this exercise.