What a Browser Sandbox Can and Cannot Stop When Running AI Code

A browser sandbox can contain hostile web content without containing the harm an AI agent can cause. The distinction is architectural. Browser isolation limits what a process can reach, while agent security must also govern instructions, tools, credentials, and persistent state. Understanding that difference explains both what browser sandboxes protect and why they cannot serve as the whole security boundary for AI-generated code.

Why browser sandboxes are architecturally mismatched for AI code execution

Johann Rehberger’s ZombAIs test of Claude Computer Use showed a hidden prompt injection on a web page causing the agent to download and execute a binary and connect to a command-and-control server. The browser did not need to be broken. The attacker instead redirected an agent that already had the capabilities needed to follow those instructions. That is a different threat from malicious web content trying to escape a renderer and reach the host.

Browsers are built to guard against that latter threat. Multi-process separation, restricted system call access, and Mojo IPC at security boundaries constrain untrusted web content. Chromium site isolation, Firefox Fission, and WebKit2’s split-process model keep web content separate from the UI process, though some platforms do not have full site-identity enforcement. These boundaries map onto sites and browsing sessions, leaving the authority of an autonomous agent generating and executing arbitrary code outside their scope.

WebAssembly adds lightweight isolation for compute-intensive browser tasks, but it does not change that underlying model. Client-side execution and persistent, hardware-isolated server execution solve different problems. An environment’s sandbox boundary must therefore surround the actions and resources through which an agent can cause harm.

What browser-level isolation actually stops, and why that matters less for agents

Within its intended scope, browser sandboxing provides substantial protection. It constrains malicious scripts from compromised pages, drive-by malware execution, and direct OS-level access from web content. Site isolation also restricts lateral access between sites by placing distinct origins in distinct processes. This separation has reduced the impact of speculative-execution attacks and cross-origin data theft.

Rather than relying on a single exploit, an attacker may need a chain that compromises the renderer and then crosses another security boundary. That extra work excludes commodity attacks built around single-exploit payloads. Imperfect isolation can still be valuable isolation.

The difficulty is transferring that protection to agent behavior. What happens when the attacker does not need a browser exploit at all? An agent can use its existing permissions to send information, operate a page, or invoke another tool after reading hostile instructions. Process isolation can hold throughout that sequence because the attack changes the agent’s decisions while leaving the process’s privileges unchanged.

Prompt injection as a semantic bypass that process isolation cannot see

Prompt injection exploits the point at which an agent interprets external content as an instruction. Hidden commands in ordinary HTML or instructions disguised as data payloads can influence that interpretation without changing the browser’s execution rules. The sandbox sees normal rendering and actions that its rules allow. It has no process-level violation to stop.

Brave’s research showed prompt injections that still worked on an LLM even though people reviewing the page could not see them. That finding sharpens the structural problem. A person inspecting the page and an agent interpreting it may not encounter the same apparent instructions. In ZombAIs, the agent followed the injected instruction without a sandbox escape or an exploited CVE. The dangerous transition came when page content gained the power to direct the agent’s next action.

Could input filtering or output guardrails catch the instruction before that transition? They can address anticipated patterns, but adversarial inputs are designed to fall outside those patterns. Invisible instructions also limit what human review can establish. Smarter system prompts alone cannot make a process boundary also control how an agent interprets content. Semantic protection is a separate requirement, even when the resulting action looks entirely legitimate to the browser.

Code execution inside the renderer is already a dangerous starting point

A browser’s Trusted Computing Base has GPU processes, media codecs, complex font rendering, and AI-native features. As that base grows, auditing it becomes harder, and new capabilities require the sandbox architecture to account for new interactions. Time-of-check-to-time-of-use vulnerabilities and race conditions can arise in those interactions. Being inside the renderer is not a harmless position.

Arbitrary code execution there can already let an attacker steal cookies, control the page, and act as the authenticated user. The host filesystem need never be touched. For an agent workflow, tokens, sessions, and delegated access may be the valuable assets. The sandbox separates the renderer from the operating system while potentially leaving the user’s identity exposed to an attacker in the renderer.

Extensions complicate that distinction further because their permissions are not equivalent to those of ordinary page content. Extension code remains subject to OS-level sandboxing, whether it runs in a dedicated extension renderer or as a content script in an ordinary renderer. However, elevated extension API permissions can grant access beyond what site isolation alone governs. Both the possibility of process escape and the authority code already holds inside that process consequently matter.

Configuration injection and how sandbox escapes reach the host through agent tooling

Agent tooling creates another route out that does not require a browser vulnerability. Pillar Security describes how files produced inside an agent sandbox can be consumed by tools outside it, including Python extensions, Git integrations, VS Code task files, hook engines, and Docker Desktop sockets. The file crosses a trust boundary before its contents become executable behavior. Configuration becomes the bridge to host authority.

CVE-2026-25725, with a CVSS score of 7.7, illustrates that route. An attacker with code execution inside the sandbox can create a malicious .claude/settings.json hook file. When Claude Code is subsequently restarted on the host, the injected hooks execute with host privileges. The protected process need not directly break out, because a later configuration-loading step performs the privileged execution.

Manifold Security’s September 2026 GitSpawn research documents eight flaws across Claude Code, Codex, Cursor, Goose, Hermes Agent, Qwen Code, and Grok Build, with four unpatched at publication. Untrusted repositories set Git configuration execution sinks such as core.fsmonitor, which run when an agent calls Git for context, outside both the sandbox and an approval step. The eight findings span the seven named agents.

Microsoft Security Research’s May 2026 work describes a complementary risk in which prompt injection chains through a vm2 sandbox escape into host-level remote code execution. Configuration injection, by contrast, can succeed while the sandbox itself holds. The distinction between that toolchain problem and a sandbox problem exposes the gap in treating browser isolation as the complete perimeter. Its protection ends before the agent’s external tooling does.

What browser sandboxing cannot enforce at the policy and identity layer

Even without either kind of escape, an organization still needs to control who has legitimate access and what they can do with it. SaaS sessions, contractor connections, and browser-based AI tools converge in the browser, making it a control point for identity and data. Process isolation does not decide which extension should be allowed or which information an AI tool may receive.

An employee pasting source code, contracts, or customer data into an AI tool may be performing an ordinary browser operation. Sandboxing does not itself prevent or log that disclosure as a policy event. Security teams can therefore lack visibility over where sensitive information goes despite having an intact sandbox. The same holds when an agent acts for the employee.

Delegated identity makes this especially consequential for agents. A legitimate API call can become a channel for credential abuse or data exfiltration if hostile instructions redirect its purpose. No host compromise is required for that loss. Weak extension governance, uncontrolled uploads, and excessive reliance on isolation leave these paths open because the sandbox boundary and the policy boundary sit in different places.

The isolation spectrum practitioners now reason about — and what it covers

The execution-isolation spectrum offers a way to compare those functions more precisely. At the stronger end, Firecracker and Kata microVMs give each workload its own kernel. gVisor interposes a user-space kernel, providing stronger isolation than ordinary containers with broader compatibility, but adding I/O overhead. Browser isolates apply browser-based sandboxing to web-content workloads, while Docker containers use Linux namespaces for process isolation and share the host kernel.

Sharing a kernel is the decisive container tradeoff. A kernel exploit can undermine that boundary, making defense in depth necessary. Firecracker has fast cold starts with little memory overhead, while the extra work gVisor does on the host can slow I/O and reduce host density. Which tradeoff fits depends on the workload. Stronger separation does not eliminate the need to understand what runs on each side.

Language runtimes have scope limits too. A memory-safety flaw in CPython can let malicious AI model templates escape code sandboxes and execute arbitrary code inside inference servers. The Python Security Response Team treats execution of untrusted Python within a sandbox as outside CPython’s security threat model. That caveat prevents a runtime’s presence from being mistaken for an unconditional security guarantee.

Stateful execution and long-running agents expose a gap that isolation strength alone does not close

Isolation strength says little about whether an environment can preserve a workflow. A coding agent may need a stateful environment for hours, while a code-interpreter task may last only seconds. A browser automation flow may need to pause for a person to step in and then resume. A session-bound sandbox that resets at the end cannot support all those patterns. Persistence is a separate architectural requirement.

A suitable execution model can be ephemeral per task, persistent across a session, resumable from a snapshot, or long-running in the background. Snapshots that capture filesystem and memory state allow an agent to resume where it stopped with its environment intact. They also allow developers to fork from an existing execution point. Browser sandboxing itself cannot do the same for a full machine.

For demanding workloads, hardware-virtualized Linux VMs can combine a separate kernel, nested virtualization, real root access, and full-machine snapshots, with running VMs forked in milliseconds. DeltaBox’s research, identified as arXiv:2605.22781, explores millisecond-level checkpoint and rollback for stateful agents.

Continuity also has a security consequence. When an ephemeral environment discards the state needed to reconstruct an agent’s actions, it can discard the evidence needed for an audit. Statefulness and auditability therefore intersect, although retaining execution state is not by itself a complete audit policy.

What purpose-built runtimes for AI code execution actually provide

A purpose-built runtime must combine execution containment with controls over the agent’s authority and lifecycle. Kernel-level or hardware isolation addresses host access, but the boundary must also cover toolchain paths that would otherwise execute outside it. Per-agent identity and credential injection control access while keeping secrets out of the agent’s reach. Semantic-layer protection addresses hostile instructions, while snapshot and resume support interrupted workflows. No single isolation primitive supplies all of these.

Operational requirements add further constraints. Sub-second provisioning keeps isolation from becoming a latency tax at scale. Docker-native deployment lets teams use existing images rather than rebuild their stack for a new abstraction. Customer-managed compute, or BYOC, keeps data and cost control with the team outside a shared multi-tenant environment. These capabilities concern deployment and governance as much as containment.

Compliance also requires separate judgments. SOC 2 Type II does not make an agent platform HIPAA compliant, because the frameworks address different obligations and must be assessed independently. GDPR considerations extend to runtime handling of personal information, including context window limits and avoiding persistent PII in agent memory. A compliance label cannot stand in for those specific controls.

For teams evaluating an execution environment, the minimum baseline includes non-root containers, network egress filtering, read-only mounts, and strict timeouts on every agent task. Those controls remain useful whether the environment is purpose-built or retrofitted. Teams must also assess what remains outside those controls, especially configuration loaders, delegated credentials, and persistent state. A browser sandbox can be one boundary in that design, but it cannot define the whole design.