Threat Modeling Frameworks Specific to LLM-Powered Agents

LLM-powered agents break the core assumptions that frameworks like STRIDE and PASTA were built on: a fixed system boundary, a known set of data flows, and a trust topology that holds still long enough to diagram. Agents violate all three by design, because they negotiate tool access, write to memory, and delegate authority to other agents while they run, not before. The Cloud Security Alliance has named the resulting failure directly: STRIDE was never built to address adversarial machine learning, data poisoning, or the autonomous, self-directed behavior that defines an agent's operation, and no amount of careful diagramming closes that gap after the fact.

Four failure modes appear repeatedly when practitioners try to force classical methods onto agentic systems. Component-level STRIDE analysis checks each piece of a system on its own, but an attack like EchoLeak passes that check at every component because the real attack path runs across components in sequence, invisible if you look at one box at a time. Trust boundaries that classical models treat as fixed turn out to be negotiated at runtime: every tool an agent connects to and every memory write it performs can open a relationship of trust that did not exist when the system was first modeled. Persistence through memory has no home in STRIDE's six categories. The ATFAA framework treats temporal persistence as its own threat domain, a recognition that an agent's memory can carry a compromise forward across sessions in a way STRIDE's spoofing-tampering-repudiation vocabulary was never built to name.

The scale of the problem is not anecdotal. If you work with agents, you need frameworks built from the ground up around persistent state, delegated authority, and multi-step tool chains, because the classical toolkit was never meant to track any of the three.

What MAESTRO actually models and where it draws the line

MAESTRO answers that need with a layer-by-layer decomposition of an agentic system, built specifically so that an analyst can trace an attack path as it moves across components rather than stopping at the edge of one. The framework breaks an agent into seven layers, and each one has threats that represent it, listed below:

| Layer | Focus | Representative threats | |---|---|---| | 1. Foundation Models | The base LLM | Prompt injection, model stealing, corrupted training data | | 2. Data Operations | Vector stores, RAG, agent memory | Memory poisoning via log tampering, poisoned embeddings | | 3. Agent Frameworks | Orchestration, reasoning loops, tool dispatch | Tool misuse, agent goal manipulation, plugin vulnerabilities | | 4. Deployment and Infrastructure | Servers, containers, networks | Infrastructure tool exploitation, resource denial-of-service | | 5. Evaluation and Observability | Monitoring and debugging | Log evasion, attribution gaps in multi-agent workflows | | 6. Security and Compliance | Governance, spanning all other layers | Auditability failures | | 7. Agent Ecosystem | Marketplaces, MCP/A2A, external integrations | Agent impersonation, marketplace manipulation |

The structural insight that sets MAESTRO apart from component analysis is the cascading path: the most dangerous attacks start at Layer 1, in the foundation model itself, and travel through to Layer 4 and beyond, picking up privilege and reach at each hop. Per-component analysis cannot see this by construction, since it was never designed to follow a thread across layer boundaries. The Cloud Security Alliance has already published working MAESTRO models for the OpenAI Responses API and for Google's A2A protocol, so you get concrete templates instead of just an abstract methodology.

None of this replaces analysis at the component level. STRIDE was never built to catch what MAESTRO catches, but the layers above still need the work STRIDE does below, and that work still needs them in turn.

What MITRE ATLAS adds that MAESTRO cannot supply

MAESTRO tells you where an attack can travel through a system. It does not, on its own, tell that analyst how real adversaries actually carry one out, and that is the gap MITRE ATLAS fills. ATLAS grounds each of MAESTRO's abstract layers in documented adversary behavior: named techniques and real incidents, not just categories.

ATLAS expanded its agentic coverage in version 5.4.0 through a collaboration with Zenity Labs, and it added fourteen new techniques aimed squarely at AI agent security. Each technique ties to case studies drawn from events that actually happened: the poisoned Postmark MCP server that exfiltrated email (AML.CS0053), the indirect prompt injection against Bing Chat (AML.CS0020), and the LAMEHUG malware attributed to the Russian state-backed group APT28 (AML.CS0044).

Two properties make ATLAS usable inside an actual engineering workflow, not just as a reference document. The data ships in STIX 2.1 format, so you can pull it directly into detection pipelines as machine-readable intelligence instead of copying it by hand out of a PDF.

The two frameworks are not competing for the same job. MAESTRO shows you where an attack travels as it crosses a system's seven layers. ATLAS shows how adversaries actually execute each step along that path, with technique IDs, incident references, and mitigation mappings attached. A practitioner who adopts one and skips the other is left with either a map with no documented routes on it, or a list of routes with no map to place them on.

OWASP's Agentic Work and the Springer Threat Catalog

MAESTRO and ATLAS define the structural and technical core of agentic threat modeling, but you won't find your front door into the subject in either one. That role belongs to OWASP's Agentic Top 10, alongside the most rigorous academic threat catalog assembled so far, from Raciti, Bella, and Van Landuyt. Together, the two show what the practitioner community has agreed sits inside the scope of agentic security, and the catalog's own numbers show how much bigger that scope is than any single framework currently captures.

OWASP's Agentic Security Initiative released the AIUC-1 Crosswalk in May 2026, mapping governance requirements against a dedicated Top 10 for Agentic Applications. Its categories include agent goal hijacking, tool misuse, identity and privilege abuse, agentic supply chain vulnerabilities, unexpected code execution, memory poisoning, insecure inter-agent communication, cascading failures, trust exploitation, and rogue agents. This is a separate document from the general LLM Top 10, built around the specific behaviors that distinguish an acting agent from a chatbot answering a prompt.

Raciti, Bella, and Van Landuyt presented their work at SEC 2026, first published online on June 3, 2026. The paper backs its taxonomy with a test framework built from 7 concrete test cases, each anchored to a specific threat, validated across 5 different LLMs. Test every model you want: their own results show current LLMs stay vulnerable to the threats the catalog identifies. The catalog runs to 159 distinct threats, and that figure backs up the claim that no single framework, however well built, covers the full territory agents actually expose.

A distinction surfaces clearly across both the OWASP and Springer work: attacks on an agent, meant to corrupt its behavior directly, and attacks through an agent, which use it as a pivot to reach the databases, APIs, and infrastructure sitting downstream of it. The second category matters more for practical defense, because an agent that is never directly compromised can still serve as the exact path an attacker needed into a system it would otherwise never have reached. A newer timing problem compounds both categories: in agent-authored development workflows, a new module can appear in seconds, while manual threat modeling of that module takes hours. In the window between the two, an agent can change code, call tools, write to memory, and update dependencies before anyone runs a check against a repository checkpoint.

The coverage gaps that no current framework closes

MAESTRO, ATLAS, and the OWASP and Springer catalogs together cover a wide and well-documented span of agentic threats, and none of them cover all of it. Systematic blind spots remain, and the honest accounting is that the frameworks themselves do little to make those blind spots visible to the practitioner relying on them.

The LASM framework, proposed in April 2026, decomposes the agentic stack into seven layers of its own, Foundation, Cognitive, Memory, Tool Execution, Multi-Agent Coordination, Ecosystem, and Governance, and adds something none of the other frameworks carry: a four-class temporality axis spanning instantaneous, session-persistent, cross-session cumulative, and sub-session-stack threats. Mapping existing coverage against that axis produces an uncomfortable result. The upper layers of the agentic stack, especially where threats propagate across the full stack or unfold over long horizons, remain sharply under-explored, and multiple attack regions documented in the mapping have no corresponding defense.

One instance makes the gap concrete rather than theoretical. As of June 2026, OpenAI's Codex began encrypting the messages its MultiAgentV2 sub-agents exchange with each other (tracked in GitHub Issue #28058), so defenders lost the readable task audit trail that had let them see what instructions one agent was passing to another. The agentic security survey's broader finding holds here too: agentic systems are fragile by default, and defending one requires controls spanning its full lifecycle rather than a patch applied at a single layer.

Two further results sharpen the point. Testing shows MCP tool poisoning evades output-based safety checks in most cases, so if a check only validates an agent's visible response, it will miss the compromise sitting inside the tool call that produced it. If you lean on any single framework, however rigorous, you will carry blind spots you cannot see from inside that framework alone. That is the practical argument for running MAESTRO, ATLAS, and the OWASP and Springer catalogs together rather than choosing one, and for treating the two concrete threat surfaces below as the proving ground for whether that layered approach actually holds up.

The threat surfaces that require framework coverage: prompt injection and multi-agent escalation

In casual conversation, people treat prompt injection and multi-agent escalation as one problem, but they call for coverage at different MAESTRO layers and different stages of the ATLAS kill chain, and if you conflate them you leave gaps on both sides. Prompt injection holds the number one spot on the OWASP Top 10 for LLM Applications 2025, but inside an agentic system the threat is no longer just a matter of input sanitization. It is architectural: the LLM at the center of the system has no reliable way to tell a trusted instruction apart from untrusted data sitting in the same context window.

Production exploits with assigned CVEs show the risk is not hypothetical. AWS Kiro had an arbitrary code execution flaw in its original finding with no CVE assigned, though a later variant picked up CVE-2026-10591. Google Jules suffered an invisible prompt injection that enabled backdoor code execution, with a separate exploit chain allowing remote control of the agent through indirect prompt injection.

EchoLeak (CVE-2025-32711, CVSS 9.3) stands as the clearest case of MAESTRO's cross-layer logic in practice. A zero-click prompt injection against Microsoft 365 Copilot exfiltrated internal files with no user interaction at all, and the mechanism was a confused deputy: the agent used access it legitimately held, granted for a legitimate purpose, to serve an attacker's goal instead. STRIDE's spoofing and tampering categories have no clean way to represent that, because nothing was spoofed and nothing was directly tampered with, and the agent simply did what it was authorized to do, on behalf of the wrong party.

Multi-agent escalation takes that same mechanism and stretches it across a chain of agents instead of just one. Research published in March 2026 describes promptware-powered command-and-control infrastructure run through prompt injection: a botnet where the individual bots are AI agents rather than infected machines. The attack needs only one poisoned document that a single agent somewhere in the chain will eventually process. ATLAS's newest techniques map this pattern directly: AI Agent Context Poisoning and Exfiltration via AI Agent Tool Invocation describe exactly the cross-agent staging that trips up any analysis still working one component at a time.

The threat surfaces that require framework coverage: memory, RAG, and the tool layer

If prompt injection and multi-agent escalation define the moment an attack enters and spreads, memory, retrieval, and tool access define where it persists. A prompt injection that only lasts for one exchange is a bad afternoon. If a prompt injection writes itself into an agent's memory or poisons the embeddings behind its retrieval system, it can outlast the conversation that introduced it, appearing again when the agent pulls from the same vector store or recalls the same prior interaction.

MAESTRO's Layer 2, Data Operations, names this directly: memory poisoning through log tampering and poisoned embeddings sits alongside the vector stores and retrieval-augmented generation pipelines that make an agent useful. The retrieval mechanism that lets an agent answer questions about a company's internal documents is the same one an attacker can use to plant instructions those documents never contained. ATLAS assigns this exact behavior a technique ID, RAG Credential Harvesting (AML.T0082), so you get a documented method tied to the abstract category instead of just a theoretical risk.

The tool layer carries its own separate exposure. MAESTRO's Layer 3, Agent Frameworks, covers the orchestration and tool dispatch logic where tool misuse, goal manipulation, and plugin vulnerabilities live, and the Model Context Protocol has become the connective tissue linking agents to the tools they call. A dedicated taxonomy for that protocol, MCP-38, lays out 38 distinct threat categories built specifically around MCP's semantic attack surface: tool description poisoning, indirect prompt injection carried through tool metadata, parasitic tool chaining, and dynamic trust violations that emerge only once two systems start negotiating access at runtime. None of those four problems were adequately captured by the frameworks that came before MCP existed. A protocol-specific taxonomy was needed for that reason.

The through-line across memory, retrieval, and tools is persistence and delegated trust. Each layer gives an attacker a way to plant something once and have it executed later, by a different component, acting on authority it was never meant to abuse. You need coverage at MAESTRO's structural layers, technique-level grounding from ATLAS, and the practitioner-facing categories OWASP built for exactly this purpose, and you need them applied together, not in isolation.