Threat Modeling AI Agents: What STRIDE Misses

STRIDE was designed for a different era. When Adam Shostack and the Microsoft team formalized it, the systems being modeled had clear boundaries - a service received input, processed it, returned output, and sat still. The threat model worked because the system did. Agentic AI does not sit still. It makes decisions, calls tools, spawns sub-agents, reads from memory, and acts on instructions that arrive mid-execution from sources it cannot always verify. Applying STRIDE to that kind of system is not wrong exactly - it just leaves most of the attack surface unmapped.

Threat modeling for agentic AI systems requires starting over from a different set of assumptions. Not because the old vocabulary is useless, but because the failure modes that matter most in autonomous pipelines are not spoofing or tampering in the classical sense. They are trust failures that look correct from the outside - an agent confidently executing instructions that were never supposed to be there, calling a tool it should never have reached, or leaking context through a channel nobody thought to monitor. This piece works through what those gaps look like and how to think about filling them.

What Threat Modeling for Agentic AI Systems Actually Covers

Threat modeling, in the conventional sense, is the practice of asking where a system can be attacked before an attacker finds out. You map components, identify trust boundaries, enumerate the ways an adversary could move across them, and design controls accordingly. For traditional web applications or APIs, this is tractable. The inputs are finite. The execution path is deterministic. The blast radius of a misconfiguration is usually bounded by the service itself.

Agentic AI changes every one of those assumptions. An agent does not execute a fixed function - it interprets a goal, selects from a set of tools, reasons about intermediate results, and decides what to do next. That reasoning process is itself an attack surface. The agent's context window - the running log of instructions, tool results, and memory retrievals that shapes its behavior - can be manipulated by anything that contributes to it. A hostile document retrieved from the web, a poisoned database record, a compromised API response: any of these can rewrite what the agent believes it is supposed to be doing.

Threat modeling for agentic AI systems, then, has to account for that dynamic execution model. It means mapping not just data flows and trust boundaries in the architectural sense, but the instruction pathways that govern agent behavior at runtime. Where does the agent's context come from? Who can write to it? What happens when something in that context conflicts with the original directive? These are the questions a STRIDE analysis will not prompt you to ask.

What the Gaps Actually Look Like in Practice

The most common gap is the one that gets the least attention in threat model reviews: corrupted context. An agent operating in a multi-step pipeline pulls information from external sources - search results, file contents, email threads, database outputs. Any of those sources can carry embedded instructions. Prompt injection at this level does not look like an attack. It looks like the agent doing its job. The model reads a document, encounters text formatted as a directive, and follows it. There is no error. There is no anomalous behavior flag. The agent just does something it was not supposed to do, and does it with apparent confidence.

The second gap is dynamic tool sourcing. Agents that can install plugins, call third-party APIs, or chain to sub-agents introduce supply chain risk at execution time - not at build time. An attacker who controls an API endpoint an agent calls can return responses that alter the agent's subsequent behavior. If the agent has permissions to write files, send messages, or trigger downstream processes, the blast radius of that single compromised endpoint can be substantial. The vulnerability is not in the code. It is in the trust the agent extends to any source that returns a well-formed response.

The third gap, and the one that tends to produce the largest incidents, is authentication and authorization at the agent action layer. Most teams secure the interface into the agent. Very few apply the same rigor to the actions the agent takes on behalf of the user. An agent authenticated as a specific user should not be able to take actions that user would not have permission to take directly. In practice, the tool layer often has broader permissions than the human it is acting for - because granting the agent wide access felt easier than mapping permissions precisely. That shortcut becomes an escalation path the moment the agent is manipulated.

Why Standard Frameworks Underperform Here

STRIDE gives you six threat categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Each maps cleanly onto a class of attacks against systems with static components and defined interfaces. The problem with applying STRIDE to agentic pipelines is that the most dangerous threats do not fit cleanly into any of those bins.

Prompt injection is not quite spoofing - the attacker is not pretending to be someone else. It is not tampering in the data-integrity sense. It is closer to instruction substitution: replacing the agent's goal with a different goal, without ever touching the system's authentication layer. STRIDE has no category for that. It also has no category for trust transitivity - the way an agent's permissions propagate outward when it calls a tool, which calls another service, which returns data the agent acts on. Each hop in that chain carries the agent's authority. A single weak link can hand an attacker effective control of everything downstream.

OWASP's agentic AI guidance and NIST's AI Risk Management Framework both move closer to the problem, because they were built with autonomous systems in mind. OWASP's framing covers prompt injection, tool misuse, memory risks, and communication boundary failures in a way that maps directly onto real agentic architectures. NIST's four functions - Govern, Map, Measure, Manage - provide an organizational layer that STRIDE never attempted. Neither framework is complete on its own. But they start from a more honest description of what an agentic system actually is.

How to Approach Threat Modeling for Agentic Pipelines

The place to start is not the threat categories. It is the instruction pathways. Before you enumerate threats, map every source that can write to an agent's context - system prompts, user inputs, tool results, memory retrievals, sub-agent messages. For each one, ask who controls that source, whether the agent can distinguish legitimate instructions from injected ones, and what the agent is permitted to do on the basis of what it reads there.

From that map, the threat analysis becomes more tractable. You are looking for places where an external source that should be data is treated as instruction. You are looking for tool permissions that exceed what the orchestrating user actually has. You are looking for memory writes that persist across sessions and could carry state from a previous, compromised run. None of these are exotic attack scenarios. All of them appear in production systems that were not built with this lens.

Authentication and authorization deserve a dedicated pass that treats the agent as a principal - not just a relay for human credentials. Every action the agent can take should be scoped to the minimum permission set that task requires. This is tedious work. Mapping it precisely takes longer than granting broad access and assuming the agent will behave. But the shortcut creates the escalation path. The precision is the control.

Visibility is the other layer that gets skipped. An agent that operates without logging its reasoning steps, its tool calls, and the contents of its context window is an agent you cannot audit after something goes wrong. Monitoring for behavioral anomalies - tool calls outside expected patterns, context that suddenly references external domains, unusually long instruction chains - requires that logging to exist in the first place. Build it in before the system goes anywhere near production, not after an incident creates the business case for it.

When a Standard Threat Review Is Not Enough

If an agentic system touches sensitive data, executes actions with real-world consequences, or operates with any degree of autonomy in an environment shared with external inputs, a standard threat review is not enough. That is not a warning about edge cases. It describes most production agentic deployments being built right now.

The signal that your current process is falling short is usually architectural: the threat model was produced by reviewing the system prompt and the API surface, and nobody asked what happens when a retrieved document tells the agent to ignore previous instructions. Or the tool permissions were set by the engineering team and never reviewed by anyone with a security background. Or the agent can write to a persistent memory store, and nobody has modeled what a poisoned memory write looks like three sessions later.

At that point, the gaps are not in the threat categories you are using. They are in the model of the system itself. Bring in someone who has actually built agentic pipelines and knows where the seams are. Red-team the instruction pathways, not just the external interfaces. And do not wait for a large event to surface the assumptions that are currently holding the architecture together.

The autonomous decision-making that makes these systems useful is exactly what makes them dangerous when the threat model has not kept pace. That is not an argument against building them. It is an argument for taking the threat modeling seriously enough to match the actual architecture - not the simpler one that fits inside STRIDE.

Related reading: AI agents and their architecture

Related reading: AI agent architecture and behavior