In June 2025, Microsoft patched a CVSS 9.3 vulnerability in Microsoft 365 Copilot that let an attacker exfiltrate sensitive corporate data , emails, SharePoint files, and Teams messages with a single crafted email. No clicks required. No malware. No code execution. The payload was pure natural language, hidden inside an ordinary-looking business document.
The researchers who discovered it, Aim Security, called it EchoLeak. They classified it as the first confirmed zero-click exploit against a production AI agent. And here’s the part that should keep security architects awake: if you’d run a textbook STRIDE analysis on Microsoft 365 Copilot before this attack, you almost certainly would not have found it.
Not because you’re bad at threat modelling. Because STRIDE wasn’t built for systems like this.
The Trust Model That No Longer Holds
Most traditional threat modelling frameworks built around data flow analysis, STRIDE, OCTAVE, Trike, rest on a foundational assumption: there’s a clear boundary between code (trusted, deterministic) and data (untrusted, to be validated). You draw your data flow diagrams, mark your trust boundaries, enumerate threats at each boundary crossing, and you’re done.
Agentic AI breaks that boundary in a genuinely novel way. The LLM at the centre of an AI agent is simultaneously executing logic and processing untrusted input. It doesn’t separate instructions from data; it treats everything in its context window as a single stream of tokens to reason over. When Copilot ingested that malicious email, it wasn’t processing a “payload” in the traditional sense. It was doing exactly what it was designed to do: reading context and acting on it.
This isn’t a new vulnerability class you can bolt onto your existing threat model with an extra column. It’s a category violation. And it’s why a PwC survey of 300 executives found 88% plan to increase budgets for agentic AI ,while security teams scramble to figure out what “trust boundary” even means when the boundary itself is made of language.
Where STRIDE Actually Fails, With Specifics
I’ve written before about the MAESTRO framework and how CSA designed it specifically for the layered complexity of agentic AI. But understanding why STRIDE fails matters more than knowing a replacement exists. If you don’t understand the failure mode, you’ll misapply the new framework too.
Christian Schneider, a security architect who conducts regular reviews of enterprise agentic AI implementations, identifies three specific patterns that STRIDE doesn’t naturally model. I’ve seen the same patterns repeatedly in my own work, so let me walk through each with the EchoLeak attack as our running example.
Semantic state accumulation. STRIDE doesn’t ask: “What if future reasoning depends on attacker-controlled text?” In agentic systems, context persists across turns and sessions. An attacker can inject instructions into a document that sit dormant until a future query activates them. In EchoLeak, the malicious email sat idle in the inbox for days or weeks before Copilot’s RAG engine retrieved it as “relevant context” for a completely unrelated user query. No STRIDE category captures “latent attacker intent that activates on a future trigger.”
Cross-zone attack causality. The EchoLeak attack chain was: malicious email → RAG retrieval → prompt injection → XPIA filter bypass → Markdown link injection → CSP-approved proxy abuse → data exfiltration. The academic analysis documents six trust boundary crossings in a single attack, each of which appears legitimate on its own. STRIDE evaluates threats at individual components or boundary crossings. An attacker treats the entire chain as one operation. Try classifying EchoLeak under STRIDE: is it “Information Disclosure” at the RAG retrieval step? “Tampering” at the context assembly step? “Elevation of Privilege” at the proxy abuse step? It’s all of them and none of them, because the threat isn’t at any single point; it’s in the chain.
Abuse of legitimate functionality. No spoofing occurred. No data was tampered with at rest. No privilege was elevated in the traditional sense. The agent used its own legitimate capabilities, reading email, summarising content, and generating responses, exactly as designed. The OWASP Agentic AI threat taxonomy captures this as “Agent Goal Hijack” (ASI01) ,a category that effectively has no equivalent in STRIDE because STRIDE assumes the system’s intended behaviour, if followed, is safe.
Adam Shostack himself, the person most responsible for popularising STRIDE through his book and work on Microsoft’s SDL, has acknowledged this type of limitation. On Security Stack Exchange, he described STRIDE as “a poor taxonomy and an excellent mnemonic,” noting that once you’ve found a threat, trying to force it into STRIDE’s six categories frequently leads to analytical dead ends. STRIDE was created by Loren Kohnfelder and Praerit Garg at Microsoft in 1999 for a world of deterministic software with predictable code paths. That’s not the world we’re building in anymore.
The Incident Record Proves the Pattern
EchoLeak is the poster child, but it’s far from alone. 2025 produced a rolling series of agentic AI security failures, and every single one shares the same structural characteristic that STRIDE can’t model: the attack exploits the agent’s reasoning process, not a traditional software vulnerability.
Consider how each maps, or fails to map, to STRIDE’s categories:
The Postmark MCP supply chain compromise saw attackers modify a legitimate email-sending tool to silently BCC every outgoing email to an attacker-controlled address. In STRIDE terms, is this “Tampering”? The tool was tampered with, but the agent itself was never compromised. It faithfully executed a tool that behaved exactly as its metadata described. The OWASP MCP Top 10 classifies this as “Tool Poisoning”, a category that maps to supply chain security rather than application threat modelling.
The GitHub MCP vulnerability allowed a malicious public issue to hijack an AI assistant and exfiltrate private repository contents. “Information Disclosure”? Technically, yes, but the disclosure occurred because the agent reasoned that the attacker’s instructions were legitimate, not because of a missing access control or broken encryption.
The Supabase/Cursor incident involved poisoned support tickets that triggered SQL exfiltration via an overprivileged AI agent. The three factors that combined catastrophically, privileged access, untrusted input, and an external communication channel, don’t map to a single STRIDE category because the vulnerability was emergent from the agent’s architecture, not present in any individual component.
As CrowdStrike’s analysis concluded, the breach occurs in the reasoning layer, and traditional DLP tools miss it because the exfiltration appears to be a normal tool invocation.
What to Do Instead: A Practitioner’s Approach
OWASP’s Agentic Security Initiative has done substantial groundwork. The OWASP Top 10 for Agentic Applications 2026, released in December 2025 with input from over 100 experts, including representatives from NIST, Microsoft, and AWS, identifies the ten highest-impact risks. ASI01 (Agent Goal Hijack), ASI02 (Tool Misuse), and ASI03 (Identity & Privilege Abuse) occupy the top three spots.
Critically, OWASP introduced the principle of “Least Agency”: don’t just constrain what an agent can access, constrain how much autonomy it has to act on that access. I think of this as the agentic equivalent of Least Privilege, and it’s a dimension that no traditional threat modelling framework captures.
But risk lists tell you what to worry about. The practitioner’s question is how to find these threats in your specific architecture. Here’s the approach I recommend, synthesised from Schneider’s scenario-driven methodology, the OWASP Agentic AI threat taxonomy, and the MAESTRO layered model:
Step 1: Map Your Architecture to Threat Zones
Traditional DFDs show data moving between components. For agentic AI, you need to map five zones where attacks enter and propagate: the input/retrieval zone (RAG pipelines, emails, documents), the reasoning zone (LLM context assembly and decision-making), the action zone (tool calls, API invocations), the state zone (memory, session persistence), and the coordination zone (agent-to-agent communication).
For each zone, explicitly mark every channel through which external data enters the agent’s context. Most teams discover entry points they hadn’t considered, especially tool response channels that return attacker-influenced content the agent trusts implicitly.
Step 2: Trace Attack Scenarios as Chains, Not Events
This is the critical shift from STRIDE-style thinking. For each entry point, construct a concrete scenario and trace it through all five zones.
Here’s what this looks like for EchoLeak: an attacker sends an email containing hidden instructions (Zone 1: input). Copilot’s RAG engine retrieves the email as relevant context for a user query (Zone 1→2: retrieval-to-reasoning). The hidden instructions manipulate Copilot’s response generation to embed sensitive data in a Markdown link (Zone 2→3: reasoning to action). The link is auto-fetched via a Microsoft Teams proxy permitted by CSP (Zone 3: action). Data reaches an attacker-controlled server. No memory poisoning in this case, but note the four-zone traversal: each step is individually legitimate, collectively catastrophic.
If you’d applied STRIDE to each zone separately, you’d have flagged “Information Disclosure” at the output step and perhaps “Tampering” at the input step. You would not have identified the chain as a single coordinated attack, nor would you have found that the CSP-permitted proxy was the critical enabler.
Step 3: Validate Against Four Agentic Factors
After tracing scenarios, validate coverage against: non-determinism (the same input can produce different outputs, how does this affect your threat model’s reproducibility?), autonomy (which agent actions occur without human approval?), agent identity (how are agent actions attributed and scoped?), and agent-to-agent trust (how are inter-agent messages validated?). If your threat model doesn’t address each of these, you have gaps.
Step 4: Formalise High-Risk Chains as Attack Trees
Convert your highest-risk scenarios into attack trees, tagging each node back to the OWASP agentic threat taxonomy. This creates a direct mapping from discovered attack paths to OWASP’s mitigation playbooks , giving your engineering team actionable remediation guidance rather than abstract risk categories. If you’ve ever done red teaming against generative AI systems, this step should feel familiar; you’re formalising the attack paths you’d test.
What You Can Do This Week
Let me be direct: this isn’t just a problem for teams building AI agents. If your organisation uses Microsoft Copilot, GitHub Copilot, Salesforce Einstein, or any SaaS product with embedded AI capabilities, you are already running agentic AI systems whether you choose to or not. Palo Alto Networks estimates that machine identities now outnumber human identities by 82:1 in the average enterprise. Even discounting that as a vendor projection, the directional truth is clear: most of those machine identities are increasingly agentic.
So here are three concrete, time-boxed actions:
Today: Draw your five-zone map. Take your current architecture diagram for any system that includes an AI agent or LLM integration. Overlay the five threat zones. Highlight every point where external data enters the agent’s context. You’ll almost certainly find entry points nobody has explicitly evaluated ,especially in RAG retrieval pipelines and tool response channels.
This week: Run one EchoLeak-style scenario walkthrough. Pick your most business-critical AI integration. Construct a scenario: “An attacker embeds instructions in [document type] that the agent will process.” Trace it through all five zones as I demonstrated above. Don’t propose mitigations yet; first, understand the complete attack path. You’ll likely discover that your existing threat modelling methodology was never designed to catch what you find.
This month: Adopt the OWASP Agentic Top 10 as your baseline. The OWASP Top 10 for Agentic Applications was developed from real incidents and peer-reviewed by experts from NIST, Microsoft, AWS, and the Alan Turing Institute. Map your current security controls against ASI01-ASI10. The gaps you find are your roadmap.
STRIDE gave us a generation of better threat models. It earned its place, and it still works well for the deterministic systems it was designed for. But the systems we’re building now, non-deterministic, autonomously reasoning, language-driven, have moved past what they can see. The question isn’t whether your agentic AI systems have security gaps. It’s whether your threat modelling methodology can find them before someone else does.