Why your existing threat modeling tool doesn't model agents

Traditional threat modeling assumes a data flow diagram or system boundary that accurately describes what happens at runtime. You model what the code does, then identify where an attacker could interfere. The DFD is a faithful representation of system behavior — that is what makes it useful.

STRIDE maps to this model cleanly. Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege all describe threats to the boundaries between static entities: actors, processes, data stores, and data flows. The LLM planner does not fit any of those categories cleanly. It is not an actor (it does not have a stable identity). It is not a process (its behavior is not determined by code logic). It is not a data store (it does not persist state in an auditable form). And its data flows are not fixed — they depend on runtime context.

For agentic systems, the DFD you drew at design time may have nothing to do with what happens in production. The system decides at runtime which tools to invoke, in what order, on what inputs. That decision is not in the code — it is in the model's response to its context. You cannot model it as a DFD edge.

The five gaps below are each specific failures of the determinism assumption. They are independent — closing one does not close the others.

Standard threat modeling tools model what the system can do — defined capabilities expressed as functions, API endpoints, or process boundaries. Agents have a dynamic tool surface: the LLM decides what to invoke based on context, not based on what the user explicitly requested.

The threat is prompt injection causing the LLM to invoke a tool the user did not request. The canonical example: a customer service agent with access to a refund tool and an email tool. STRIDE models both tools as assets with their own threat surfaces. It models the user invoking the refund function. It does not model the adversary path: craft a support message that convinces the LLM to invoke the email tool to exfiltrate PII.

The DFD representation of “user invokes function” and the adversarial representation of “adversary causes LLM to invoke function by manipulating input context” require different graph structures entirely. The first is a directed edge from actor to process. The second is an influence path through LLM context — not representable as an edge.

Notice what this means for defense: standard tooling will produce a control set that secures the refund tool as a function boundary (authentication, authorization, input validation). It will not produce any control that addresses the path by which the LLM decides to invoke the email tool instead. Those are different attack surfaces requiring different control categories.

In deterministic systems, the “path” through the code is modelable. You can enumerate branches, identify trust boundaries, and map data flows at each decision point. In agentic systems, the attack surface is the reasoning process itself — and reasoning is not enumerable.

Prompt injection at the reasoning level does not bypass a check. It causes the model to reason incorrectly about what it should do. The adversary is not exploiting a code bug — they are exploiting a reasoning bug. MAESTRO, the agentic AI threat framework, identifies this as a distinct threat class precisely because it has no equivalent in traditional application security.

Threat modeling tools ask “what data can be intercepted?” and “what boundary can be bypassed?” They do not ask “what context can be injected to change the model's decision?” That is a categorically different question.

Consider the difference between SQL injection and prompt injection. SQL injection works by breaking out of a data context into a code context — a well-defined structural vulnerability. Prompt injection works by providing content that the model treats as authoritative instructions. There is no structural boundary between data and instructions in the LLM context — the model decides which is which based on reasoning about the content.

Traditional threat modeling has no representation for “the model reasoned incorrectly about the authority of this input.” That omission is not a gap in the threat model. It is a gap in the methodology. The threat class does not exist in the taxonomy the tools were designed to enumerate.

Sequential tool calls create compounding blast radius that standard DFDs cannot represent. A three-step agentic sequence — retrieve customer record, draft response, send email — is individually modelable at each step. What is not modelable is the cross-step injection chain.

The attack works like this: an adversary embeds adversarial content in data that will be retrieved at step 1. That content enters the LLM's context. When the LLM drafts the response at step 2, the adversarial content influences the draft. When the draft is sent at step 3, PII is exfiltrated in the email body. No individual step is compromised. The code at each step is functioning as designed. The attack operates entirely through the LLM context that carries state between steps.

Standard DFDs represent inter-step data flows as edges with defined data types. The implicit assumption is that the data flowing on that edge is just data — it does not change the behavior of the receiving process except through defined interfaces. In an agentic system, data retrieved at step 1 enters the context window and can change the LLM's goals for steps 2 and 3. That is not a data flow — it is a goal modification channel.

The consequence is that the blast radius of any single compromised data source in an agentic workflow extends to every subsequent step in the chain. A threat model that evaluates each step independently will systematically underestimate the impact of injection at any step that precedes a high-privilege operation.

The context window is an attack surface unique to LLM systems. Everything in context — system prompt, tool results, user messages, retrieved documents, conversation history — can influence model behavior. There is no equivalent in traditional application architecture.

RAG pipelines are particularly exposed. Documents retrieved from external sources enter the context window and can contain adversarial instructions. The retrieval system performs a semantic search and returns the most relevant documents. “Relevance” does not imply “safe to place in model context.” An attacker who controls any document that may be retrieved has a path into the context window of any agent that uses that retrieval system.

Standard threat models represent this as “data in transit” (securing the retrieval pipeline) or “data in storage” (securing the document store). Neither representation captures the semantic attack: the adversary does not intercept data. They cause the model to act on stored data as instructions. The data store is not compromised. The retrieval system is not compromised. The attack succeeds because the model cannot reliably distinguish between data it was told to read and instructions it is supposed to follow.

Securing the context window requires a different control category entirely: content sanitization before injection, instruction/data separation at the prompt architecture level, and — where possible — structural compartmentalization between context zones. None of these controls appear in a standard threat model output because the context window is not a modeled entity in any standard threat modeling taxonomy.

Traditional systems make trust decisions in code. The logic is static, auditable, and deterministic: a role check, a permission flag, a validated token. Threat modeling tools can enumerate these decision points and map what happens if each one is bypassed.

Agents make trust decisions based on LLM judgment. The user says they are a doctor; the agent decides to share clinical details. The user provides a plausible-sounding business justification; the agent decides to proceed with a sensitive operation. These are not code paths. They are reasoning decisions made by the model at runtime based on the content of its context. They cannot be found in a DFD because they do not exist in the code.

Jailbreaking is a direct exploit of dynamic trust decisions. The adversary does not find a code vulnerability. They convince the model to override its own guardrails. Standard threat modeling asks “what code can be bypassed?” It does not model “what reasoning can be manipulated?”

The control gap is structural. You cannot write an access control policy that says “reject claims that the user is a doctor.” The judgment about whether to act on that claim is made by the model, not by a policy engine. Defending against this threat class requires a different approach: constraining what actions the model can take regardless of its reasoning, rather than trying to make its reasoning correct. That is a capability-based security model — and it is not what standard threat modeling tools produce.

The five gaps are not argument for abandoning existing tools. They are argument for knowing exactly what those tools cover and what they do not. Microsoft Threat Modeling Tool, IriusRisk, and Threagile can model components of an agentic system — particularly the infrastructure layer — if you are deliberate about the mapping. They cannot model the five gaps above at all. What they produce is necessary but not sufficient.

A complete threat model for an agentic system requires five additional components that standard tools do not produce:

Commercial tools — Microsoft Threat Modeling Tool, IriusRisk, Threagile — can model component 1 and parts of component 2 if you work creatively within their data model. They cannot model components 3, 4, or 5. Those three components require a threat modeling methodology designed for systems where context and reasoning are first-class attack surfaces.

This is not an argument against using existing tools. Use them for the infrastructure layer — transport security, service identity, network boundaries, dependency vulnerabilities. Those threats are real and the tools model them well. The argument is for knowing exactly where the coverage ends, and for treating the five gaps above as the non-negotiable remainder that must be addressed separately.

The existing tools are not wrong for what they were designed for. They were designed for deterministic systems. Agentic AI is not deterministic. The threat model has to match the system — not the other way around.

For further reading on the specific agentic threat taxonomy that closes these gaps, the OWASP Agentic AI Top 10 and the MCP server threat model cover the specific threat classes and controls in detail.