STRIDE Threat Model Applied to AI Agent Tool Interfaces

STRIDE was built for a world with a clean line down the middle of the diagram: trusted process on one side, untrusted input on the other. Agent tool interfaces erase that line, and every category in the model inherits the consequences.

STRIDE's trust boundary assumption at the agent tool interface

The classic STRIDE diagram puts a trust boundary wherever control passes from one party to another: user to application, application to database, client to server. Kernel mode and user mode stay apart. Developer instruction and user input stay apart. Each threat-modeling pass walks every component through six questions, and the six categories stay clean because the analyst always knows where the attacker-controlled data starts and where the trusted logic begins.

An AI agent has no such line inside its context window. The system prompt written by the developer, the user's message, the content of a retrieved document, and the output of a tool call all arrive in the same channel and get read by the same model in the same pass. Nothing in that channel carries a stamp that marks it trusted or untrusted. A single poisoned tool output, once it lands in that window, can trigger Information Disclosure, Elevation of Privilege, Denial of Service, and Repudiation at once, because all four violations trace back to the same collapsed boundary. That is not proof the framework has failed. STRIDE's categories still describe the right properties, but if you apply them now, you need to name the collapsed boundary explicitly, not assume it the way a data flow diagram usually does. The 2026 Layered Attack Surface Model survey by Kexin Chu makes the scale of the problem concrete: it decomposes the agentic stack into seven layers, Foundation, Cognitive, Memory, Tool Execution, Multi-Agent Coordination, Ecosystem, and Governance, and shows threats forming at runtime across layers that a traditional DFD treats as one bounded process. The rest of this piece walks each STRIDE letter through that collapse, to see how far the model still reaches and where it runs out of vocabulary.

Spoofing at the tool interface: agent identity without cryptographic proof

Spoofing in classic STRIDE means impersonating a user or a service, usually solved with passwords, tokens, or certificates. In agentic systems the question shifts from "who is this user" to "who is this agent, and who is this tool," and the answer often rests on nothing firmer than a text label.

In a multi-agent setup, one agent can claim to be an orchestrator, a privileged sub-agent, or a trusted tool endpoint, and the agent receiving that claim has no built-in way to check it, because agent-to-agent communication travels through the same plain-language channel as everything else. Trent AI's 2026 STRIDE guide for agent systems lists the forms this takes in practice: forged tool execution identities, malicious plugins that claim a trust level they haven't earned, and direct impersonation of one agent by another. Tool poisoning belongs to this category too, as a supply-chain version of the same problem: a tool can present a clean interface and an innocent-looking description while carrying a payload that does something else. Johann Rehberger documented the clearest case of this in February 2026, finding hidden Unicode instructions buried inside MCP Skills. The characters were invisible, the tool's visible code and description never changed, and the tool still passed as legitimate even as it behaved differently. A 2026 comparative analysis of the MCP, A2A, Agora, and ANP protocols looked directly at how, or whether, each one binds agent identity, and found the gap sitting at the protocol layer itself, not just in how any one vendor implements it. Translating STRIDE's usual Spoofing fix, strong authentication, into this setting means cryptographic identity binding between agents, schema-validated tool registration, and provenance checks on a tool before its description ever enters the context window.

Tampering: prompt injection as the agent-layer integrity violation

Tampering used to mean you altered a file, a database row, or a packet in transit. At the agent layer it means you alter the instruction stream itself, and the attacker doesn't need write access to anything the agent is supposed to protect. The attacker only needs to put text somewhere the agent is authorized to read.

That delivery vector can be a document pulled in through retrieval-augmented generation, a web page the agent browses on the user's behalf, an email the agent summarizes, a calendar entry, or a comment left on a GitHub issue. This is the indirect form of prompt injection, where the payload sits inside retrieved content rather than inside the user's own message, and it stays invisible to any input validation that only checks what the user typed. Prompt injection now ranks first on the OWASP GenAI Top 10 for 2026, above every other listed risk. The CVE-2025-54135 vulnerability in Cursor shows what that ranking means in practice: an indirect prompt injection led the agent to create a malicious MCP configuration file without asking the user, and from there the attacker reached remote code execution. Tampering with the instruction stream became tampering with the filesystem in one continuous move. A 2026 paper by McHugh breaks prompt-injection artifacts down into seven parts, carrier, delivery vector, concealment, context-break, privilege escalation, payload, and return channel, giving practitioners a structured way to dissect an injection rather than describe it in loose, case-by-case language. That decomposition maps directly onto a Tampering analysis under STRIDE, while adding something STRIDE alone doesn't capture: a way to label what the attacker intended, not just how the text was worded.

Repudiation: why agent reasoning chains produce accountability voids

Classic Repudiation mitigation rests on one assumption: that what happened is legible from the logs, so a signed transaction or an audit trail can settle any dispute after the fact. Agents break that assumption quietly, because the decision to call a tool, the retrieval results that shaped that decision, and the exact system prompt version active at the moment of execution are often simply absent from production logging.

Trent AI's STRIDE guide names the gap directly: "autonomous agents produce untraceable reasoning chains, make decisions without clear provenance, and often have incomplete logging of tool calls." The guide then asks the question that actually matters for incident response: if an agent makes a financial decision or changes a security setting, how does anyone prove afterward why it did that? The Mexican government data exfiltration case, running from December 2025 into February 2026, shows what this looks like at scale, not in a single transaction. Thousands of commands executed across nine separate government agencies, with the agent acting as an autonomous executor throughout. There, the failure wasn't one unexplained action; it was an extended sequence of autonomous actions with no human-readable record tying the steps together. Closing that gap means logging at the level of individual tool calls: the arguments passed into each call, the retrieval context active at the moment of invocation, and the reasoning step that produced the call in the first place, not just the final output the agent returned.

Information Disclosure: context window leakage and the confused-deputy exfiltration pattern

Classic Information Disclosure covers unprotected storage, unencrypted transmission, and error messages that say too much. Agentic Information Disclosure can happen without any of that, because the agent doesn't need to be compromised to leak data. It only needs to be redirected, using access it already holds legitimately, to serve someone else's purpose.

This is a confused deputy: an agent tricked into using its own authorized permissions on the attacker's behalf, with no credential theft and no access control bypass anywhere in the chain. EchoLeak, documented by Aim Security in 2025, is the case that made this pattern visible in production. A hidden prompt buried inside an ordinary email steered Microsoft 365 Copilot, during what looked like routine work, into violating its own trust boundary, an LLM scope violation that let sensitive data leave the tenant with zero clicks from any user. It stands as the first documented zero-click exfiltration from a production enterprise AI assistant, and no credential was ever stolen. Context window leakage is the wider version of the same risk: when an agent's context isn't properly isolated across sessions and users, prior session data, the contents of the system prompt, documents retrieved for a different user, and tool credentials can all leak. The 2026 SoK on the attack surface of agentic AI and the LASM survey both single out memory as its own distinct leak point, since information that persists across sessions can be pulled out by a later prompt, something that has no equivalent in a stateless system.

Denial of Service: from resource exhaustion to weaponized agent infrastructure

Denial of Service in agentic systems splits into two different problems. One is familiar: resource exhaustion through recursive loops and tool chains that never terminate. The other has no clean precedent in classic STRIDE: LLMjacking, where a compromised agent remains available but becomes active infrastructure working for the attacker.

Classic DoS drains resources until the service goes down. Agentic DoS can drain resources while, at the same time, redirecting that compute toward the attacker's own goals, so the asset isn't just offline, it's working against the people who own it. The straightforward half of this is easy to picture: an agent told to call its own tools in a loop, or to spawn sub-agents with no termination condition, will burn unbounded compute and run up an unbounded bill. An agent can become active infrastructure working for the attacker while still appearing available, and STRIDE has no category for that. "My asset has become hostile infrastructure" requires extending the framework's vocabulary beyond the original six categories, and it marks the clearest point in this walk where that extension becomes necessary.

Elevation of Privilege: excessive agency and argument-level enforcement as the gap STRIDE exposes

Elevation of Privilege is where a successful Tampering attack cashes out. Once an injected instruction sits inside the context window, it inherits every tool permission the agent already holds, so any prompt injection with enough reach becomes a privilege escalation by default.

Classic EoP needs a technical exploit: a buffer overflow, a misconfigured role, an escalated token. Agentic EoP can be reached with a plain-language instruction that the agent carries out using permissions it was handed legitimately. Trent AI's STRIDE guide maps three concrete versions of this: agents reaching tool access beyond what was intended, permission models loose enough to create what the field calls "excessive agency," and cross-agent privilege inheritance, where a sub-agent holding elevated permissions can be steered by a compromised orchestrator above it. The Cursor case, CVE-2025-54135, shows the mechanism end to end: the indirect prompt injection led the agent to write a malicious workspace configuration file without user approval, and the attacker turned that write permission into remote code execution. The agent's permission was never stolen. It was used exactly as granted, just at the attacker's direction. Tool-level permission checks fall short as a fix: the tool itself was authorized, and the argument passed to it was never checked. Agent-Sentry, from Sequeira et al. in 2026, addresses this by tracking where the values flowing into tool arguments actually come from, making the case that tool-use safety needs parameter-level provenance, not just a permission check on the tool as a whole. PACT, filed as arXiv:2605.11039 in 2026, pushes the same idea to full argument granularity, tracking the provenance of each individual argument in a tool call so that enforcement can happen without blocking workflows that mix trusted and untrusted inputs. Under oracle provenance conditions, PACT reached full utility and full security on its diagnostic suites, and flat invocation-level monitors couldn't match that.

STRIDE's limits and extensions

Running all six letters against an agent tool interface shows the model holds up better than its critics sometimes credit, but three structural gaps remain that no amount of careful application can close on its own.

STRIDE still names the right properties to protect: authentication, integrity, non-repudiation, confidentiality, availability, and authorization are all still at stake once an agent starts calling tools, and nothing about agentic architecture makes any of them optional. Walking through each letter in turn also forces questions that get skipped otherwise, Repudiation and its logging requirements especially, along with Spoofing and the question of agent identity, both of which stay chronically under-built in early agentic deployments.

Three gaps stand out against that strength. The first is boundary collapse: STRIDE assumes a threat analysis can be run element by element because each element carries a stable trust level, but a single piece of content in an agent's context window can be attacker-controlled and fire several categories at once, something a per-element pass simply won't catch. The second is granularity: STRIDE's authorization analysis works at the level of a process or a service, while agentic Elevation of Privilege needs analysis down at the level of individual argument values, and a permission model built around whole tools leaves the real exploit surface unexamined. The third is a missing category. ASTRIDE, a research paper from December 2025, and STRIDE-AI, an arXiv preprint from May 2026 by Tsafac Nkombong Regine Cyrille and Franziska Schwarz, both add explicit coverage for threats the original six letters can't classify: prompt injection as its own first-class threat, unsafe tool use, and reasoning subversion. Both papers land on the same conclusion independently, and that reads as a real convergence in the 2025-2026 practitioner literature toward a seventh category.

Put into practice, that points to a sequence rather than a single fix: run STRIDE first as the initial diagnostic pass, so no security property gets skipped; draw the collapsed trust boundary explicitly into the data flow diagram before applying any of the six categories to it; extend the authorization analysis down to argument-level provenance for every tool call the agent makes; and treat the added "A" category from ASTRIDE as required, not optional, whenever the system involves RAG retrieval, multi-agent coordination, or access to external tools. A threat model that only maps categories without testing whether the mapped threats can actually be exploited against an isolated version of the system leaves the collapsed boundary exactly where it started: assumed away rather than examined.