Prompt Injection Attack Prevention in Sandboxed Agents

The conventional wisdom about sandboxing holds that if you constrain what code can run, restrict filesystem access, and wall off the network, you have contained the threat. That logic was developed for a world where the dangerous thing was a program: deterministic, inspectable, and executable only through the operating system's permission layer. Large language model agents are not that. The dangerous thing in an agent is an instruction, and instructions execute in a medium the operating system cannot see.

OWASP ranks prompt injection first on its 2025 top-ten list for AI systems, and the empirical picture behind that ranking is not comfortable. Attack success rates across studied configurations run from roughly 50% to 84%, and adaptive techniques (where an attacker can observe failure and adjust) push those rates above 85%. A sandbox that restricts what code can run but leaves the model's context unguarded still loses, because the injected instruction reaches its target before any OS-level containment can act. The payload executes in language space. The firewall never gets a packet to inspect.

This creates a question worth sitting with: what does a sandbox actually need to contain, if the execution environment is not the primary attack surface?

The Three Attack Paths Most Likely to Reach Agents Inside a Sandbox

The taxonomy matters here, because defenders instinctively prioritize the attack they understand best. Direct injection (sometimes called jailbreaking) is the version most people visualize: the attacker controls the user-facing input turn and crafts a message that overrides the system prompt. It is real, it is studied extensively, and it is arguably the easier problem. The agent can, at least in principle, be instructed to treat the user turn with appropriate skepticism.

Indirect injection is structurally different and harder to defend. The malicious payload arrives through a channel the agent is supposed to use: a retrieved document, a search result, an email it was asked to summarize. The content is not the user's message; it is the agent's working material. The model has no native reason to distrust it.

Retrieval-augmented generation creates a specific variant of this problem. Research presented at USENIX Security 2025 demonstrated that as few as five crafted documents inserted among millions could achieve a 90% attack success rate in tested systems. The poisoned documents do not look like attack payloads to a human reviewer; they operate at the embedding level, designed to surface reliably when the agent queries for particular information. The attack is a supply-chain operation on the knowledge base, not a visible intrusion.

The Model Context Protocol introduces a third vector that is structurally distinct from both of the above. MCP is the emerging standard by which agents communicate with external tools and data sources. A malicious MCP server can return tool responses that contain hidden instructions; the agent processes them as trusted system output rather than user-supplied text, because that is exactly what they structurally resemble. A proof-of-concept published by Invariant Labs in April 2025 showed a single poisoned tool description exfiltrating private repository contents and message histories without any user interaction. Benchmarking across more than 45 real-world MCP servers found attack success rates exceeding 60%, with the highest-performing agent model reaching 72.8%. With more than 18,000 MCP servers listed on MCP Market as of 2025, the attack surface is not hypothetical.

The MCP case is worth emphasizing architecturally. Standard detection stacks scan user-supplied text. MCP poisoning exploits structural metadata: the tool descriptions and response schemas that the model assumes the developer authored. It is closer to a supply-chain attack on context than to anything resembling user-side jailbreaking.

Simon Willison's 2025 framing of the "lethal trifecta" captures the underlying logic cleanly: access to private data, exposure to untrusted content, and the ability to communicate externally. Any agent missing one of the three breaks the attack path. Any agent with all three is structurally exploitable regardless of how well the model was trained. That is not a statement about model quality. It is a statement about geometry.

These three attack paths require defenses at different points in the pipeline. No single control addresses all of them.

What Production Failures Show About Where Defenses Actually Broke Down

Case studies are more instructive than benchmarks here, because they reveal what broke under conditions a vendor had already tried to prevent.

EchoLeak, assigned CVE-2025-32711 with a CVSS score of 9.3, affected Microsoft 365 Copilot and was disclosed in June 2025. The attack was zero-click: an attacker sent one crafted email, Copilot processed it, accessed internal files, and exfiltrated their contents to an attacker-controlled server without any user interaction beyond opening the message. The attack chain required four sequential steps: evading Microsoft's cross-prompt injection attack classifier, bypassing link redaction using reference-style Markdown syntax, exploiting auto-fetched images, and abusing a Teams proxy permitted by the content security policy. Each individual bypass was modest. The chain succeeded because no single layer was designed to see the full sequence. Antivirus, firewalls, and static file scanning were structurally irrelevant; the payload executed entirely in natural language space.

GitHub Copilot received CVE-2025-53773, with a CVSS score of 9.6, for a remote code execution vulnerability exploited via prompt injection. The specific failure was that Copilot could modify .vscode/settings.json without requiring explicit approval. That output action, the ability to write a file with downstream execution consequences, should have required a privilege gate. It did not.

Anthropic's system card for Claude Opus 4.5 published data from agentic coding benchmarks that deserves more attention than it has received. In controlled testing, indirect injection succeeded 4.7% of the time on the first attempt. At ten attempts, the success rate rose to 33.6%. At one hundred attempts, it reached 63.0%. This is a well-aligned model. The degradation under retry pressure is not a character flaw of that particular system; it reflects a structural property of how probabilistic models interact with a determined, adaptive attacker.

OpenAI stated in February 2026 that prompt injection in AI browsers may never be fully patched. That is a vendor acknowledging, publicly, that model-level resistance alone cannot close the gap.

The pattern across all of these cases is the same: failure at the boundary between trust domains, where content from one trust level crossed into a context with higher privilege without a control positioned at that boundary. EchoLeak crossed from email content to internal file access. The Copilot RCE crossed from model output to filesystem write. The Opus 4.5 retry data shows that even strong alignment does not constitute a stable boundary when the attacker controls the timing.

Why Layered Defense Works Where Single Controls Fail

Research examining defense frameworks that layer controls has found substantial reductions in attack success rates. That gap is what layering adds beyond any individual control, and the magnitude is worth taking seriously.

The principle underlying that reduction is architectural, not incremental. Treat the LLM as an untrusted component within a secure system, not as a trusted reasoner that just needs better inputs. This reframing matters because it determines where you build your controls. If the model is trusted, you invest in making the model more resistant. If the model is untrusted, you build the controls around it, in positions the model cannot override.

Google DeepMind's CaMeL, published in March 2025, makes this explicit. The system borrows Control Flow Integrity, Access Control, and Information Flow Control from traditional software security and applies them around the model, not inside it. The model's output is treated as input to a policy layer that the model itself cannot instruct to stand down.

The reason this matters is that models cannot reliably distinguish trusted instructions from injected ones. That is not a fixable bug. It is a structural property of how attention-based models process context. Everything in the context window is processed through the same neural pathway. The Opus 4.5 retry data confirms that even strong alignment degrades under sustained pressure. Asking the model to be the last line of defense is asking it to solve a problem it is not structurally equipped to solve.

The three layers this article examines, input validation, privilege constraints, and output filtering, each interrupt an injection at a different point in the pipeline. Input validation reduces what reaches the model's context. Privilege constraints limit what the model can instruct the system to do even if an injection succeeds. Output filtering catches exfiltration attempts before they leave the sandbox boundary. The analogy to defense-in-depth from network security is apt: no layer is assumed to hold alone; breaking any single layer still leaves two more.

Input Validation at the Sandbox Boundary

Input validation's job is to reduce the probability that a malicious instruction reaches the model in a form it will follow. The approaches available differ substantially in what they can catch.

Prompt classifiers and cross-prompt injection attack detectors flag known injection patterns before content enters context. They work well against known signatures and degrade against novel phrasing. Spotlighting, the technique of marking untrusted content segments with delimiters or special tokens, gives the model positional cues about trust level; it reduces injection risk without eliminating it. Instruction hierarchy enforcement, structurally separating the system prompt from the user turn from retrieved content, gives the model additional signal about what it is reading. For RAG pipelines specifically, scanning retrieved chunks for instruction-like content before embedding them into context, combined with provenance tracking for postmortem analysis, adds a layer that pure semantic filtering misses.

MCP-specific validation requires treating tool descriptions and response schemas as untrusted input rather than system content, verifying them against a trusted manifest before the agent processes them. This is a significant posture shift for most current implementations, where tool metadata is implicitly trusted as developer-authored.

The known ceiling on input validation is not theoretical. EchoLeak bypassed Microsoft's production-grade XPIA classifier by chaining bypasses across multiple content channels simultaneously. A classifier designed to inspect inputs one at a time cannot see a sequence that distributes its payload across several. PoisonedRAG-style attacks are, by design, structurally indistinguishable from legitimate content to a content-level scanner; the attack payload is in the retrieval behavior, not the document text.

Input validation has a hard ceiling, and a well-designed architecture acknowledges it. The next layer must assume some injections will get through.

Privilege Constraints Inside the Sandbox

The governing principle here is least privilege applied per tool, per data source, per action type. Not an agent-wide permission set; not a role that grants broad access because the agent might need it. Granular, task-specific, revocable grants.

CaMeL implements this through structural separation. A privileged LLM generates the execution plan from the trusted user query only. A quarantined LLM processes untrusted external data with no tool access. A custom interpreter sits between them, tracking data provenance and enforcing security policies before each tool call. The model cannot instruct the interpreter to skip this check; the check is not part of the model's context. In testing on the AgentDojo benchmark, the system completed 67% of tasks securely with near-total protection against injection attacks. The cost is real: roughly 2.82 times the input tokens and 2.73 times the output tokens compared to an unprotected architecture. That is an engineering tradeoff, not a rounding error, and any team evaluating this approach should budget for it honestly.

Willison's lethal trifecta functions as a privilege design checklist. The question to ask during architecture review is whether the agent genuinely needs all three of private data access, untrusted content exposure, and external communication capability simultaneously. If the task can be decomposed so that the component handling untrusted content never holds credentials and cannot initiate external requests, the attack path breaks structurally regardless of what the injected instruction says.

Human-in-the-loop gates deserve a more prominent place in production architectures than they currently occupy. Payments, deletions, credential use, and external HTTP requests should require explicit approval before execution. The failure mode that CVE-2025-53773 illustrated was precisely the absence of this gate on a state-changing file operation.

ceLLMate, published in December 2025, takes a different angle: browser-level sandboxing at the HTTP layer rather than the model layer. The observation is that all side-effecting UI operations in a browser ultimately produce network communication; HTTP-level policy enforcement can therefore block state-changing requests regardless of what the model was instructed to do. The system runs as an agent-agnostic browser extension, pairs mandatory website-authored policies with an automated policy-prediction layer derived from the user's natural-language task, and works across agents without per-agent integration. VIGIL, from January 2026, addresses tool stream injection specifically: a verify-before-commit protocol for cases where manipulated metadata and runtime feedback in the tool stream hijack execution flow without triggering input-side filters.

CaMeL's known weakness is worth naming directly. Security policies must be defined by users, and user fatigue from repeated approval prompts is a documented failure mode. An agent that asks for approval on every small action will eventually encounter a user who approves without reading. The human gate is itself an attack surface if it is overloaded, and any architecture that relies on it needs rate-limiting and tiered approval logic, not just the gate itself.

Output Filtering as the Last Line Inside the Sandbox

An injection that succeeds in reaching the model and in getting the model to generate a response containing sensitive data still has to exit the sandbox. Output filtering is the control positioned at that exit.

EchoLeak's mechanism makes the concrete case for this layer: the attack exfiltrated data by encoding it into an auto-fetched image URL. The model's output was itself the exfiltration channel. No tool call was required; the data left the sandbox inside a Markdown image reference that a browser renderer resolved automatically.

The output boundary should inspect several categories of content. Generated text should be scanned for patterns matching API keys, tokens, and internal identifiers before the response leaves the sandbox. URLs warrant inspection for unusual query parameters or Base64 payloads consistent with data-in-URL exfiltration. Markdown constructs, reference-style links, auto-fetched image tags, and similar elements that downstream renderers will resolve without user intent are a specific category that standard text scanning misses. Content Security Policy enforcement at the agent's outbound layer restricts which external domains the agent's outputs can reference.

Output filtering is also the appropriate place to enforce response format constraints. If the agent is supposed to return structured JSON and it returns free-form text containing instruction-like content, that deviation is itself a signal worth acting on.

The honest limitation: output filtering catches known exfiltration patterns. A sufficiently novel encoding, or a slow-drip attack that distributes sensitive data across many responses that each appear innocuous in isolation, may evade signature-based scanning. Output filtering is a backstop, not a guarantee.

How the Three Layers Reinforce Each Other in Practice

The integration point that makes layering more than additive is data provenance tracking: knowing where each piece of content in the model's context originated, so privilege and output policies can be applied relative to trust level rather than just content characteristics. A document retrieved from an unverified external source should carry a different trust label than a document from an internal database with access controls, and that label should follow the data through the pipeline.

CaMeL's interpreter is the clearest current implementation of this integration. It connects input trust labeling, privilege enforcement on tool calls derived from that data, and output policy on responses containing that data into a single consistent mechanism. The model does not manage this. The interpreter does, and the model cannot override it.

The substantial reduction in attack success cited earlier represents what this compound effect achieves. Input validation alone, privilege constraints alone, or output filtering alone each leave substantial gaps. The compound effect closes most of the residual because each layer catches what the others miss. EchoLeak required four sequential bypasses because each individual control was not designed to see the full sequence. A system where each layer independently checks trust level and provenance breaks the chain at whichever link it catches first.

A practical note on implementation sequencing: privilege constraints offer the highest architectural leverage and should be established first. Input validation reduces the attack surface that reaches the model and should come second. Output filtering is the backstop and is most effective once the first two layers are in place. Implementing in the reverse order, which is common because output filtering is the easiest to bolt on, leaves the highest-leverage layer for last and creates a period of false confidence in the interim.

The tradeoffs are real and should be surfaced honestly in any implementation decision. The token overhead from dual-LLM architectures like CaMeL is substantial and affects both latency and operating cost. Human approval gates add friction and introduce user fatigue as a failure mode. Policy prediction, as implemented in ceLLMate, introduces its own accuracy surface: a mispredicted policy can block legitimate actions or permit unintended ones. None of these are arguments against layering. They are arguments for measuring the tradeoffs precisely rather than assuming the architecture is costless.

Where This Architecture Still Has Open Edges

OpenAI's February 2026 statement that prompt injection in AI browsers may never be fully patched is not a counsel of despair. It is a precise description of the problem's structure. The attack surface is the model's reasoning process, and that process is probabilistic, context-sensitive, and adaptive to inputs in ways that a static defense cannot fully anticipate. The goal of the architecture described here is resilience under attack, not elimination of the attack surface.

Several edges remain genuinely open. Policy definition in systems like CaMeL depends on users specifying what they want protected; users do not consistently know what they want protected, and the gap between a user's mental model and the actual data the agent touches can be large. User fatigue at approval gates degrades the human layer over time in ways that are difficult to detect until an incident occurs. Policy prediction introduces classification error into the privilege layer itself. Novel exfiltration encodings remain ahead of output filtering signatures until someone documents them.

The MCP ecosystem is expanding rapidly, and the structural trust assumption that tool metadata is developer-authored is not going to be easy to reverse across 18,000 servers. Provenance verification for tool descriptions at scale remains an unsolved operational problem. Slow-drip attacks that distribute exfiltration across many innocuous-looking outputs are not well-addressed by any of the three layers as currently implemented.

What the architecture provides is a meaningful reduction in attack surface, a set of independently valuable controls that degrade gracefully when one fails, and a framework for reasoning about where new attack variants will interact with existing defenses. That is a more defensible position than a sandbox that restricts code execution while leaving the model's context unguarded, but it is not a closed system. The question worth asking continuously is not whether the architecture is complete, but whether each new capability added to an agent, each new data source connected, each new tool granted, changes the geometry of the lethal trifecta and requires revisiting where the controls sit.