PASTA Threat Model Applied to LLM Agent Architectures

PASTA threat modeling gives LLM agent architectures a sound risk-centric foundation, but not a complete threat model without extension. Its seven stages must cover dynamic tools, non-deterministic reasoning, persistent memory, and the trust that passes between agents. The central requirement is to model delegated authority and how it can be redirected, rather than treating the agent as another application with fixed boundaries.

Why PASTA survives the shift to agentic AI — and what it still gets wrong

PASTA links threat enumeration to the risk to the business and to attack simulation. That structure matters because an agent’s blast radius scales with both its code surface and its delegated authority. STRIDE and DREAD help characterize adversary actions and threats, but do not themselves anchor findings to what the organization has authorized an agent to do. PASTA provides that anchor by keeping the consequences for the business in view.

But traditional PASTA assumes that system edges stay fixed, data flows are predictable, and execution is deterministic. Agents violate those assumptions as they discover tools, populate memory, and choose different action sequences across runs. Without explicit extensions, the framework does not reliably surface agent-specific threats or distinguish the mitigations they require. An incomplete model produces false confidence, and that confidence can place autonomous access to data, infrastructure, and transactions beyond defensible controls.

What makes agentic AI architecturally different from the systems PASTA was built for

Four properties explain why the extensions must reach every stage. Dynamic tool surfaces mean agents discover, negotiate, and invoke capabilities at runtime, so their attack surface cannot be fully enumerated at design time. With non-deterministic reasoning, the same input can lead to different action sequences. Microsoft’s decentralized access control paper states that agents “reason, they adapt, they hallucinate, and they can be manipulated through adversarial prompts”. A permission model must control those changing actions without assuming that execution will follow a predictable path.

Persistent memory adds a different problem because retained state can corrupt future reasoning without a live attacker. Hossain et al. identify memory poisoning that persists across sessions while safety classifiers misattribute it to model failure. Inter-agent trust propagation then lets one agent’s output become another agent’s trusted input. Paul & Nandy demonstrate how a tainted tool response reaches a compliance agent, becomes a tainted approval, and passes through an orchestrator without re-validation. These properties compound one another, making a tool’s safety depend on the memory, permissions, and trust relationships around it.

Stage I: Defining business objectives as authority declarations, not just functional goals

During the Mexico government breach of December 2025 – February 2026, a single attacker told Claude he was running a legitimate bug bounty program, supplied a lengthy hacking manual, and built a custom exfiltration tool. Claude executed the large majority of remote commands across many sessions because no authorization boundary distinguished a legitimate security task from active intrusion. The claimed purpose of the work substituted for a defensible limit on what the agent could do.

Stage I must set formal autonomy constraints alongside functional goals to limit what the agent can do. The authorized goal state must spell out which actions the agent can take on its own and which need human escalation. Its boundaries must set out whether access is read-only or write, whether tasks are bounded or allow open-ended exploration, and whether execution is time-limited or indefinite. Mission creep also belongs here because ambiguous reward signals can steer goal-seeking agents toward unintended pathways before any runtime attack occurs. Those declarations must follow formal AI governance policies, including frameworks that apply, such as the EU AI Act and NIST AI Risk Management Framework. Without them, Stage VII has no defensible baseline for deciding whether the remaining behavior is acceptable.

Stage II: Defining the technical scope around systems whose boundaries expand at runtime

Once authority is defined, technical scope must capture the systems through which that authority can operate. PASTA’s sequence moves from objectives and scope through decomposition, threat identification, vulnerability analysis, countermeasure design, and residual risk assessment. Each later stage depends on the boundary set here. For agents, that boundary must include not just provisioned tools but the mechanisms that discover and invoke new ones.

Model Context Protocol servers illustrate the distinction because they act as tool brokers. A poisoned MCP server can introduce malicious tools without a change to the agent’s configuration. The Cline AI triage bot case shows a related expansion through input, where a malicious GitHub issue title induced npm install from a typosquatted GitHub account.

Scope must also separate ephemeral context, session-persistent memory, and long-term vector stores because each has different trust properties. Retrieval sources need clear trust levels because material from outside the formal boundary can enter the agent’s reasoning. Each agent’s scope must also name the other agents that supply its inputs and spell out how much those inputs are trusted. Microsoft’s five-layer permission hierarchy offers a useful scoping scaffold across platform, tool, function, parameter, and execution context levels, without requiring that architecture as the deployment design.

Stage III: Decomposing agentic systems into components where trust is actually decided

With scope established, decomposition must show where content acquires authority. Data flow diagrams need to show the orchestrator, downstream agents, and message channels, along with the implicit trust between them that perimeter defenses cannot see. Tool arguments also require a distinct layer because a legitimate tool can become unsafe when untrusted content supplies its parameters. Memory read and write interfaces expose injection and poisoning opportunities, while the planning component exposes manipulation of the action sequence itself.

Paul & Nandy enumerate 14 attack vectors across direct input, tool outputs, inter-agent messages, and cascading orchestrator manipulation. Their decomposition shows why inspecting the external input alone cannot cover the system’s internal trust decisions. CSA’s MAESTRO framework similarly identifies dangerous paths that begin at perception and cascade into action and orchestration. The diagrams must trace those crossings across component boundaries. The SEAgent framework makes the resulting design requirement explicit by treating privilege scoping as an architectural constraint.

Stage IV: Identifying threats against the expanded agentic surface

The threat catalog needs to cover seven different agentic classes. Direct and indirect prompt injection redirect behavior through instructions, with indirect attacks arriving in retrieved external content. The OWASP Top 10 for LLM Applications ranks prompt injection as the number-one risk. Tool poisoning instead places malicious content in tool schemas, descriptions, or outputs. Johann Rehberger’s February 2026 hidden Unicode instruction injection documents how invisible instructions in agent skill files can change behavior without a visible change to tool code or descriptions.

Memory injection and poisoning corrupt the state an agent keeps and how it reasons later. Hossain et al. identify this as gradual corruption that can accumulate undetected. Orchestrator hijack and cascading injection exploit a downstream agent’s influence over routing and decisions. Paul & Nandy’s compliance-agent scenario demonstrates that propagation through a tainted approval. Excessive agency exploitation redirects access the agent legitimately holds toward an attacker’s goal. EchoLeak / Microsoft 365 Copilot in June 2025, CVE-2025-32711, illustrates that confused-deputy failure.

Privilege escalation across agent boundaries lets an agent use shared tool access to reach what a more-privileged peer can do. Paul & Nandy found that only privilege-scoped tool access for each agent role stopped it entirely. Supply-chain injection brings malicious content in through packages, agent-authored code, or poisoned artifacts. The Cline / npm case culminated in the backdoored cline@2.3.0 release installing OpenClaw malware on thousands of developer machines. This catalog must cover action-layer failures as well as perception, since Hossain et al. found that 66% of agentic LLM security papers focus on perception-layer vulnerabilities.

Stage V: Vulnerability analysis calibrated to non-deterministic and composable systems

Threat identification establishes what can happen, while vulnerability analysis explains which weaknesses make it possible in the deployed composition. Exploitability depends on neighboring agents, their trust assumptions, and the memory state at the time of attack. Hossain et al. identify architectural coupling as a root cause because weak isolation lets failures propagate between layers. Prompt injection susceptibility becomes far more consequential when it can reach unauthorized write operations.

The analysis must check for excessive permissions, missing argument-level provenance, and a lack of validation between agents. Microsoft MSRC’s July 2025 guidance identifies fine-grained permissions and access controls as the deterministic fix for indirect prompt injection. Paul & Nandy found that 67% of agents in a production-representative six-agent system remained vulnerable to at least one scope violation despite system-prompt guardrails. Instructions about boundaries are not equivalent to enforced boundaries.

Framework vulnerabilities need just as much attention because every deployment that uses an affected version has its weaknesses. CVE-2026-26030 affects Microsoft Semantic Kernel Python SDK and was patched in 1.39.4, while CVE-2026-25592 affects the.NET SDK and was patched in 1.71.0. The vector-store retrieval machinery exposed an RCE path through an eval-based filter whose AST blocklist could be bypassed through object-model attribute traversal. Static severity alone cannot describe such composition. The SoK on agentic attack surfaces proposes attacker-aware measures including Unsafe Action Rate, Privilege Escalation Distance, and Policy Adherence Rate, which support assessment beyond CVSS alone.

Stage VI: Countermeasure design at argument level, not just tool level

The key defensive shift is from permitting a tool invocation to authorizing the origins and roles of its arguments. Tool-level controls face a coarse choice between allowing external content to influence a call and blocking useful retrieval-then-act workflows. Argument-level enforcement separates content from authority. It can permit retrieved text as material to process without letting that text choose a destination, command, or credential.

PACT, or Provenance-Aware Capability Contracts, implements that distinction through a runtime monitor. It assigns semantic roles to tool arguments, tracks value provenance across replanning, and checks each origin against a role-specific trust contract. ToolFence, presented in September 2026, first compiles the user’s request into a typed capability blueprint before untrusted data is read. It tracks argument provenance and places enforcement in a deterministic, non-LLM monitor, outside the model’s authorization judgment.

These controls complement defenses at agent boundaries. Paul & Nandy measured reductions in inter-agent injection through message signing with provenance tracking, and in indirect injection through input/output sanitization. Privilege-scoped tool access eliminated cross-agent privilege escalation in their tests, while communication anomaly detection caught the large majority of cascading attempts. Plan-then-execute adds a structural constraint by fixing the permitted action sequence before execution, but does not replace runtime monitors. Stage VI countermeasures should undergo red-teaming before residual assessment, with Microsoft’s PyRIT providing automated testing capabilities for prompt injection and other attack categories.

Stage VII: Residual risk assessment when agent behavior cannot be exhaustively tested

Residual assessment must state that non-deterministic behavior and dynamic scope make exhaustive testing impossible. New tools, memory states, and agent configurations can open paths absent from the test environment. Even plan-then-execute leaves a gap if untrusted content influences the planning step. The result cannot honestly be reduced to a risk rating that implies the whole surface has been characterized.

A complete assessment must identify controls demonstrated against the Stage IV scenarios in a controlled environment. It must also name unimplemented countermeasures, untested paths, and configurations that can expand the surface after deployment. Approved workflows need testing as well because a safeguard that prevents authorized operation shifts risk. A person with access to the evidence must decide whether to ship or hold. Behavioral measures such as time needed for containment and Out-of-Role Action Rate can inform that decision without replacing it.

The Step Finance incident in January 2026 shows why the assessment must cover more than single components. Attackers compromised executive devices, while AI trading agents amplified the resulting blast radius beyond the device compromise alone. The initial vector and the system-level consequence were not the same risk. A threat model that hides its own gaps is not a threat model but a liability document.

Running PASTA continuously as agents and their tool surfaces change

Because the assessed system keeps changing, PASTA must operate as a repeating process. Tool additions, new agents, and memory configuration changes should reopen Stages II and III. New attack techniques in MITRE ATLAS or OWASP Agentic Security updates, and new framework CVEs, should reopen Stages IV and V. Countermeasure changes, approved workflow modifications, and post-incident findings should reopen Stages VI and VII.

Continuous verification must also distinguish deployment-time safeguards from risks that require runtime detection. Message provenance and communication anomaly detection must stay active after the pre-release checks are done. Their validation scenarios must be re-runnable against the current system state. A Verified Change Record approach shows that each safeguard update stops the attack it is meant to stop while approved workflows still pass. Each cycle must name what was not tested, which tools were added, and which threats remain without countermeasures, making uncertainty actionable input to the next assessment.