Privilege Escalation Paths in LLM-Powered Agents

Privilege escalation in LLM-powered agents is a structural consequence of how agents delegate authority across tools, memory, and orchestration layers, and no amount of better prompting is going to fix it. I've spent enough time in incident reviews now to know the difference between a bug and an architecture, and this is the latter.

Here's the category error, and it's an easy one to make if you haven't sat through one of these post-mortems: security teams keep asking whether a model can be tricked into saying something unsafe, as if the risk still lived inside a chatbot transcript. That question made sense back when the worst outcome was an embarrassing sentence. It stopped making sense the moment agents got tools, memory, and the ability to act on external systems on someone's behalf. The real question now is whether untrusted content can alter control flow, cross a privilege boundary, or write state that outlives the session. Those are systems questions, not language ones, and most security teams are still staffed and trained to answer the wrong one.

The mechanism underneath a rude chatbot response and a hijacked database call is identical: the model can't reliably tell instruction apart from data. What changes is the blast radius. A chatbot with no tools embarrasses you, worst case. An agent holding a database credential, an email client, and a task queue acts on the world, and every action it takes inherits whatever permissions got handed to the orchestrator or the user who started the session.

That inheritance is the whole story. Agents get authority by delegation, but almost nothing in current architectures checks whether the task actually spending those permissions is the task that was originally approved. Permissions stick to the agent, not to the intent behind any given call. Everything below is just a map of where that gap swallows people.

The three surfaces through which untrusted content enters an agent's decision-making

Three surfaces let untrusted content reach an agent's decision-making. They don't share a fix; solving one leaves the other two exactly as broken as before.

Start with the context window, because it's the oldest and least fixable of the three. Retrieved documents, tool outputs, user messages: all of it arrives as tokens, and the model has no hardware-level wall between an instruction and a piece of data. This is the root cause underneath prompt injection, and it can't be patched at the model level, because it's baked into the transformer's input format rather than being a training defect. RAG pipelines make this uncomfortably concrete. A document planted in a knowledge base, or a legitimate document quietly compromised upstream through a supply-chain flaw, carries instructions the agent treats as gospel the second it lands in context.

Memory is the second surface, and it misbehaves in a way context-window injection doesn't: it outlives the session. An attacker who manages to write a false belief into persistent memory, something as bland as "this user is authorized for admin actions," has planted something that keeps steering tool calls across many future sessions, well after whoever found the original hole has patched it. Memory poisoning corrupts what the agent thinks it's allowed to do, not just what it says in one exchange.

Third is inter-agent communication. In a multi-agent system, one agent's output becomes another agent's input, and the receiving orchestrator usually trusts that input by default, simply because it arrived from an internal component rather than an external user. Simon Willison, the co-creator of Django, has called this out directly: chaining agents multiplies the number of places an attacker can slip in a malicious instruction, because every hop is a fresh trust decision somebody has to get right. This is the setup for the cross-agent escalation path later in this piece, and it earns its own category rather than folding into ordinary prompt injection.

None of these three run in isolation, which is the part that makes triage miserable. Content pulled into a context window can steer tool selection and corrupt memory in the same breath, with no deterministic checkpoint standing between the two effects. Google researchers have logged a sustained climb in malicious prompt injection payloads sitting in ordinary web content (a 32% jump between November 2025 and February 2026 alone). The context-window surface is being seeded, in public, right now, while you read this.

How prompt injection becomes a privilege crossing rather than a text problem

OWASP puts prompt injection at the top of its 2025 Top 10 for LLM Applications, and reported attack success rates against production systems run from 50% to 84%, depending on configuration and how many attempts the attacker gets. Sit with that range for a second, because the gap between the low end and the high end has nothing to do with how clever the injection is. It comes down to whether the target agent has tools. A text-only chatbot sits at the low end because the worst it can do is say something wrong. An agent that can call a database, send email, or hit an API sits at the high end, because the same injected instruction now has somewhere to go. Some exploits against tool-using agents in production have already scored above 9.0 on CVSS, which puts this well outside academic red-teaming territory.

The mechanism is simple once you say it out loud: injection redirects tool selection, not just output. An agent authorized to read a user's email can be told, by content sitting inside that same email, to forward it somewhere else. An agent authorized to query a database can be told to package the results and ship them out through whatever channel it happens to have on hand. The model's permission set never changes in either case. What changes is which task those permissions get spent on, and the access control layer, assuming there is one, has no way to notice the swap.

Willison's "lethal trifecta" names the exact condition that makes this dangerous: private data, untrusted content, and an external communication channel, all sitting in the same agent at once. This is a completely ordinary enterprise agent, not some reckless edge-case deployment: reads internal documents, takes instructions from users and retrieved content alike, and can send messages or hit external APIs. Firewalls, network segmentation, input sanitization at the application boundary; none of it does much here, because the attack runs at the semantic layer. To any system that isn't reading for meaning, the malicious instruction looks exactly like a legitimate one.

And detection alone won't close this, whatever the pitch decks say. A 2026 systematic analysis cataloged 42 distinct attack techniques against LLM agents, and a critical review of 18 separate defense mechanisms found most achieve under 50% mitigation against adaptive attackers, meaning attackers who adjust after the first defense fails them. Frontier models from OpenAI, Google, and Anthropic all remain vulnerable to some slice of these techniques even with their best available defenses turned on. That's just where the field is, not a knock on any particular lab. Defense in depth is the only posture that survives contact, because no single layer, model or system, closes this by itself.

The stakes track how much these agents actually do. AI agents move roughly sixteen times more data than a human doing the equivalent task by hand, so a successful injection against a privileged agent stops being a single-user incident. It's a high-magnitude exposure event by construction, because the whole point of the agent is doing in seconds what would take a person an afternoon.

Capability creep: how a chain of authorized calls produces an unauthorized outcome

Capability creep is quieter than a single bad tool call. It's the process by which an agent accumulates access across a sequence of individually authorized steps until it lands somewhere no single task ever justified. Nobody exploited a vulnerability to get there. Every call in the chain cleared its own access check.

Walk the path. An agent reads a config file, which it's authorized to do. That file happens to contain a service credential, discovered as a side effect of an authorized read (nobody put it there for this purpose). The agent calls that service using the credential it just found, and that call is, again, technically authorized: the credential is valid, the call is well-formed. That service exposes an admin interface the agent now has access to, purely because the previous step succeeded. At no point did the agent break a rule. At every point, the access control system said yes. Nobody ever meant to authorize the endpoint it landed on.

Existing access control architectures miss this almost by design. Capability-based systems check permissions per invocation: is this specific call allowed, yes or no, then forget it happened. They hold no model of what the agent has accumulated over a session, so a chain of individually reasonable steps never trips a flag anywhere. And here's the frustrating part: the exact capability that makes an agent useful, its ability to reason toward a goal and find a path there, is the same capability that lets it find these unintended paths through access it was legitimately granted.

Closing this needs authorization logic aware of sequence, not just the call sitting in front of it right now. That's a different enforcement model than what most access control systems were ever built for, and it means static least-privilege at the tool level, while necessary, isn't enough by itself. You also need session-level scope enforcement, something that tracks what an agent has already touched in a given task and checks whether the next call still fits the original assignment, not just whether it passes on its own.

Cross-agent privilege escalation: escaping a sandbox through a trusted orchestrator

Multi-agent systems bring a failure mode single-agent prompt injection doesn't have: a compromised sub-agent hands manipulated output to an orchestrator, and the orchestrator, trusting that output simply because it came from an internal component, runs high-privilege actions the sub-agent itself was never allowed to touch directly. The attacker escapes a low-trust sandbox and lands in a high-trust execution context without ever laying a finger on the orchestrator's own inputs. Johann Rehberger documented this pattern, and it's held up as its own category ever since.

Model scale doesn't fix this, which is the part that should worry people betting on bigger models as the eventual answer. Research testing inter-agent trust exploitation found essentially every model vulnerable, regardless of parameter count. Larger models, above roughly 70 billion parameters, do resist direct prompt injection and RAG-based backdoor attacks meaningfully better. That improvement doesn't carry over here: the vulnerability isn't in how the model reasons about a suspicious instruction. It's that the instruction never looks suspicious to begin with.

The injected content never shows up in the orchestrator's context window as obviously foreign text. It arrives dressed as the verified output of a component the orchestrator was built to trust. Absent an explicit verification step baked into the protocol itself, the orchestrator has no basis to question any of it. Distrust has to be designed in on purpose; it isn't going to emerge from better judgment on the model's part, because there's no judgment being exercised there in the first place.

Closing this means treating every sub-agent's output as untrusted input at the orchestrator layer, full stop, whatever that sub-agent's identity or provenance happens to be. That's architectural distrust, not authentication. Knowing which sub-agent sent a message tells you nothing about whether that sub-agent's own reasoning got compromised upstream. And it compounds with scale: in a chain of N agents, each additional hop multiplies the number of places this can happen. Willison's warning about chaining agents applies here at the level of system architecture, not as a tip about careful implementation.

MCP and tool ecosystems as privilege escalation infrastructure

The Model Context Protocol standardizes how agents discover and call external tools, and that standardization is exactly why it matters here. It massively widens the catalog of things any given agent session can reach, and every tool added to that catalog is new attack surface, whether or not anyone meant it that way.

Tool poisoning shows this most clearly. Malicious instructions embedded right in a tool's metadata, its description, its parameter documentation, can hijack the model's decisions before a user has done anything at all. Confirmed research from April 2025 documented a poisoned math tool that read SSH keys off the host system and exfiltrated them encoded inside a math function's parameter, no user interaction required, no persistent trace left behind. The attack never touched user input. It came in through the tool description, which the model reads as instruction the same way it reads everything else.

Supply-chain compromise is the second vector, and it's arguably worse, because it defeats the instinct to vet a tool once before installing it. The Postmark MCP incident in September 2025 involved a widely installed email server package that passed standard review at install time, then, in a later update, quietly started BCC'ing every agent-sent email to an attacker-controlled domain. Nobody made a mistake at install. The trust granted then was reasonable; a later update just spent it without permission. That's a fundamentally different failure than a user clicking the wrong thing.

The authorization layer makes it worse. Authentication is optional under the current OAuth 2.1 framework in the MCP authorization spec, and a scan of the public internet in July 2025 found at least 1,862 MCP instances answering unauthenticated requests. As of May 2026, at least seven confirmed high- or critical-severity CVEs span major MCP-integrated platforms, including MCP Inspector, LiteLLM, Cursor, LibreChat, and Windsurf. That spread, across tools with wildly different user bases, says the pattern is systemic to the ecosystem, not a quirk of one bad implementation.

Tools are trust boundaries. That has to be the starting assumption, not the conclusion you reach after the incident report. Every entry in a tool registry is a potential escalation path the moment its metadata or behavior can be nudged by an adversary, and none of the convenience MCP offers changes that.

What it takes to actually close each path

There's no complete fix for prompt injection today. Frontier models stay vulnerable even after their best defenses go on, so any serious answer has to be layered: detection, model-level constraints, system-level enforcement, working together rather than any one of them carrying the whole load.

For the context-window path: structural separation of instructions from retrieved data wherever the underlying API actually allows it (current LLM interfaces don't always make that possible), input validation at the retrieval layer itself rather than just where a user types something, and treating every externally sourced document as untrusted by default, no matter how respectable the source looked when it entered the knowledge base.

For capability creep: session-scoped authorization that tracks cumulative access across a whole chain of tool calls, permission checks that persist across calls instead of resetting after each one, agents given the minimum toolset their current task actually requires and nothing more, and audit logs reviewed as sequences of related events rather than a pile of individually boring log lines.

For the cross-agent path: the orchestrator treats sub-agent outputs as untrusted input, full stop, no exceptions for which sub-agent sent it. Where the stakes justify the overhead, cryptographic attestation or signed output envelopes give the orchestrator something to actually verify instead of an identity claim it just has to take on faith. On the evaluation side, sandboxed testing that isolates agents in containers specifically to catch escalation attempts, plus full-runtime adversarial evaluation suites built for tool-using agents, are becoming the bar this kind of architecture gets checked against before it ships.

For the MCP and tool-ecosystem path: verification at runtime, not just at install time. The Postmark incident is about as clean an argument as you'll find for why install-time review alone doesn't cut it. Authentication should be required for every MCP server a system talks to, whatever the spec treats as optional. Tool versions get pinned, and every update requires re-verification instead of inheriting automatic trust from whatever version came before it.

One requirement runs under all four of these. Any control has to be checked to make sure it works without breaking the workflows it's supposed to protect. A safeguard that stops the attack but also stops the agent from doing its job isn't viable, because someone will quietly turn it off the first time it costs real productivity. One approach worth watching here treats agent behavior as something that should be correct by construction rather than caught after the fact: the agent produces functional code alongside formal verification artifacts, and an iterative loop feeds counterexamples back in until verification actually passes. That's a different engineering discipline than catching problems in a post-deployment scan, and it's closer to how safety-critical software gets built outside of AI entirely.

Why runtime enforcement must be verified before anything ships

There's a real gap between a system tested before deployment and a system verified to stay safe afterward, and that gap is exactly why continuous monitoring and runtime policy enforcement stopped being optional. Tools change. Prompts change. Agent configurations get updated on a schedule nobody fully tracks. A pre-deployment check, however careful, is a snapshot of a system that refuses to hold still.

Folding agent-focused test suites into standard CI/CD closes part of that gap. Benchmarks out of ICLR 2025 and NeurIPS 2025, built specifically for agent security evaluation, are becoming the bar for what a serious test looks like, and any team shipping agents with real tool access should measure against that bar instead of inventing its own.

Runtime enforcement has three things it needs to prove, and none of them are optional. It needs to confirm the smallest control capable of closing a given escalation path doesn't break the legitimate workflows the agent is supposed to run. It needs to confirm every one of those approved workflows still passes once the control is in, not just that the original attack fails now. And it needs to leave behind a verification record that another engineer, someone who wasn't in the room, can reproduce on their own. A finding nobody else can reproduce doesn't carry much weight as evidence, whatever confidence the person who found it has in it.

Changes to agent security configuration need a human in the loop, and the record of that change has to be reproducible by someone other than whoever made it. A quietly merged change to how an agent's permissions work is the same species of invisible trust violation the Postmark incident showed at the tool level, just one layer further up the stack.

This isn't a distant threat. CrowdStrike's 2026 Global Threat Report documented threat actors injecting malicious prompts into legitimate generative AI tools at more than 90 organizations over the course of 2025. Adversaries aren't waiting around for the security community to finish agreeing on the ideal framework, and they won't wait for the next one either.

So here's the actual bar. Anything shipped with access to real credentials and real systems needs a verifiable, signed record: what attack was actually proven against the system, what control went in response, and which approved workflows got confirmed to still work afterward. That record has to rest on reproducible testing, not a risk opinion, not a checklist, not a scan that happened to come back green. Something another qualified person can pick up, check, and reproduce themselves, without having to take anyone's word for it.