Isolation for AI agents:
containment across process, resource consumption, and time

When agents at OpenAI, Anthropic, and Google escaped test environments over the summer of 2026, none of them had to break a hypervisor. Instead, they left through channels that were supposed to be closed: a package cache proxy, a DNS resolver, a test network that reached the real internet.

Now picture your own coding agent pulling a container image and running it. If that image is hostile, what stops a container escape onto your laptop or your cluster? The answer starts with purpose, one job per sandbox, and then confinement along three edges: walls (what it can reach), budgets (how much it can take), and leftovers (what survives into the next run).

Isolation is one of The 6 Principles of Secure Agent Platforms, and it builds on our guide to choosing an agent sandbox. In the building analogy that runs across these principles, every agent gets its own room, with walls to the ceiling and its own share of the heat.

What isolation means for an AI agent

Isolation means an agent's sandbox shares nothing it doesn't have to with anything else on the machine, including purpose, memory, budgets, and leftovers. Each sandbox needs one clear purpose and a clear edge in three directions:

• A clear purpose (what it does). Each sandbox does one job, like the Unix philosophy of doing one thing and doing it well. This is a property of the design, not of the sandbox technology, and it sets the size of the control surface you have to guard.
• In space (memory and kernel). One tenant can't read or write another tenant's memory, or reach the host.
• In resources. Each tenant gets its own share of CPU, memory, instance slots, file descriptors, connections and disk.
• In time. Nothing is left behind for the next tenant.

A tenant is anyone or anything that shares the hardware: a user, a customer, an agent session or one task. Anything shared across an edge is a path between tenants.

Agents raise the stakes. An agent writes and runs code, pulls images, installs packages and loops on its own for hours, so every shared thing gets tested. In the 2026 lab breakouts at OpenAI, Anthropic and Google, every escape ran through something the environment shared with the outside world: a package-registry proxy, an evaluation network, a DNS resolver. One OpenAI model went looking for a sandbox flaw and found one².

Each environment shared a channel with the outside world. Closing channels until someone opens them on purpose is deny by default. Checking DNS and proxies as egress is policy enforcement points.

The idea is a well researched topic; Saltzer and Schroeder³ (1975) called it "least common mechanism": share as little machinery between users as you can. Rushby's separation kernel (1981) set the order this series follows: isolate first, then add only the channels you mean to.

Intent: one job per sandbox

Purpose isn't a wall. It is a decision about what the sandbox is for. Give each sandbox one job, the way Bell Labs' 1978 summary of the Unix philosophy asked each program to "do one thing well." A sandbox that only runs tests needs the repo and a package mirror. A sandbox that only reads email needs the inbox and nothing else. Put both jobs in one sandbox and it needs the union of their access, so a single compromise reaches all of it.

Intent is a property of the design, not of the sandbox technology, so our comparison matrix doesn't rate it: you can give a container, a VM or a Wasm component one job or ten. What it changes is the control surface, meaning the files, hosts, tools and credentials you have to write rules for and watch. One job means a short allowlist you can actually check (deny by default) and a small grant (least authority). It is also step one of the six-step method: break the agent into workflow steps. Putting single-purpose pieces back together safely is composition.

In February 2026, Clinejection showed the cost of mixing jobs. Cline's issue-triage bot also had a shell, write tools and a path to release credentials, so an injected issue title led to stolen release keys.

Memory and kernel (1a): how sandbox and container escapes happen

The first edge is the wall itself: separate address spaces, kernels or linear memories, so one tenant can't read or write another tenant's state. This is what most people mean by isolation, and it is a common escape vector for agents.

What is a sandbox escape?

A sandbox escape is when code inside a sandbox reaches something the sandbox was built to keep out, such as the host's files, its processes, or another tenant's data. Escapes almost always run through something the sandbox shares with the host. There are four common ways out:

What is a container escape?

A container escape is a sandbox escape out of a container: a process inside gains access to the host or to other containers, usually through the kernel they all share. A container is an ordinary process with a private view of files, processes and network, not a small VM.

Container escape vs VM escape vs sandbox escape

"Sandbox escape" is the general term; the other names tell you which wall was crossed.

Container escapes: when the shared kernel or runtime breaks

Containers are namespaces plus cgroups on one host kernel⁴⁵. So a kernel or runtime bug breaks every container on the host at once.

Why a shared kernel is the weak point

seccomp shrinks the kernel surface by filtering system calls, but the kernel docs say plainly: "System call filtering isn't a sandbox"⁶. Docker's default profile disables around 44 of 300+ system calls⁷, but this still leaves a large kernel attack surface by default. A compromised agent can use that surface to gain new access, probe for weaknesses or connect through unexpected paths, like DNS. Minimal containers and images built FROM scratch reduce what is ambiently available by removing utilities, but they do not reduce the system calls.

Misconfigurations that hand over the host

Many escapes rely upon a misconfiguration instead of a bug. A mounted docker.sock, host paths, host networking or CAP_SYS_ADMIN hands the container the host⁸⁹. The policy enforcement points guide covers this under the host control plane.

GPU and AI infrastructure escapes

GPU containers need a privileged helper on the host to wire the graphics card in. That helper is shared, and on a shared AI cloud the next tenant's models and data sit behind it.

• NVIDIA Container Toolkit, CVE-2024-0132 (Sep 2024): a malicious GPU container image could take over the host, exposing other tenants' models and data.
• NVIDIAScape, CVE-2025-23266 (Jul 2025): a three-line Dockerfile got a privileged host hook to load attacker code.

The fix is tenant separation: one tenant per GPU host, or a VM wall per tenant with Kata Containers. Use confidential VMs (AMD SEV-SNP, Intel TDX) if the host is untrusted¹⁰, and patch the NVIDIA Container Toolkit.

VM, microVM and Wasm escapes: strong walls still need patching

Hardware and software walls are much smaller targets than a shared kernel, but they are code too.

What is a VM escape?

A VM escape is when code in a guest virtual machine breaks out into the hypervisor or host, usually through a bug in emulated or virtual devices. The hardware wall itself is sound¹¹, so the devices are the soft spot. Firecracker CVE-2026-5747 (Apr 2026) was an out-of-bounds write in the optional PCI transport that let a guest crash the VMM and possibly run code on the host. The default configuration was not affected. Keep optional devices off and run Firecracker under its jailer¹².

Can Wasm code escape its sandbox?

Wasm code can escape only through a bug in the runtime or its compiler, or by misusing a host function it was explicitly given. Wasm isolates memory in software, inside one process¹³¹⁴, so the compiler is part of the wall. The April 2026 Wasmtime advisories (CVE-2026-34971, -34987) were compiler bugs that let a module reach host memory in non-default configurations: the Winch backend, or aarch64 with Spectre mitigations turned off. Eleven of the twelve advisories were found with LLM-assisted tools. Use guard regions and Spectre mitigations¹⁵, the pooling allocator, one instance per request and a second wall.

Shared hardware leaks across every wall

Spectre showed that side channels in the CPU cross software boundaries. For high-value tenants, the only full answer is separate hardware.

When the agent itself is the hole

Isolation has to hold against the agent too. An agent acting with your full privileges makes every wall moot.

• Perplexity Comet (Aug 2025): hidden text on a web page made an AI browser read the user's Gmail and post a one-time password to Reddit.
• Claude Code and its own denylist (Mar 2026): blocked from npx, the agent called it through /proc/self/root/usr/bin/npx. When bubblewrap stopped that, it asked to turn the sandbox off.

Give the agent its own identity, enforce approvals outside the model, and give it no switch to turn its own sandbox off. Claude Code, for one, documents an unsandboxed retry escape hatch¹⁶. See least authority and controlled information flow.

How to prevent container and sandbox escapes

1. Use one disposable sandbox per task.
2. Run each agent as its own user and restrict ptrace¹⁷.
3. Go rootless with user namespaces, drop all capabilities, set no-new-privileges, and apply the Pod Security Standard "restricted"¹⁸¹⁹.
4. Never mount docker.sock or host paths, and never use host networking.
5. Put a smaller guard in front of the kernel (gVisor runsc) or a VM wall (Kata Containers, Firecracker).
6. Keep optional VM devices (PCI) off and use the Firecracker jailer.
7. Give each tenant its own GPU host.
8. Patch runc, the GPU toolkit, the hypervisor and the Wasm runtime.
9. Run tools as Wasm components (pooling allocator with guard pages, Spectre mitigations) inside a second wall: an OS sandbox or a microVM.

How to detect container escape attempts

Watch for processes entering host namespaces, new privileged containers, writes to host paths and calls to control sockets such as docker.sock.

Resource budgets (1b): noisy neighbors, fork bombs and starvation

Resource isolation means each tenant gets a fixed share of CPU, memory, instance slots, file descriptors, connections and disk, so no tenant can starve the rest. Picture one agent session stuck in a runaway build loop. It eats all the RAM, and every other session on the host stalls or gets killed.

There is no public AI agent incident for resource budgets yet, but agents that loop on their own will hit these old failure modes. Gligor (1984) counted denial of service as a security property, and resource containers (Banga, Druschel and Mogul, 1999) introduced the per-activity caps behind cgroups.

What is the noisy neighbor problem?

The noisy neighbor problem is when one tenant on shared hardware uses so much CPU, memory, disk or network that every other tenant slows down. Dean and Barroso showed how this sharing drives slow tail responses at scale.

What is a fork bomb, and how do you stop one?

A fork bomb is a program that copies itself over and over until the machine runs out of process slots and stops responding. A wall alone doesn't stop it, because the bomb never leaves its sandbox. A process cap does: cgroups v2 pids.max, Docker --pids-limit, a Job Object process limit on Windows, or RLIMIT_NPROC.

The classic failure modes, and the control for each

Each layer has its own controls: cgroups v2, Job Objects or setrlimit and launchd limits on the host; fuel and epoch interruption²⁰, ResourceLimiter and pooling-allocator limits in a Wasm runtime; ResourceQuota, LimitRange and pod limits in Kubernetes; token and tool-call budgets per agent session.

Residue and reuse (1c): what the last tenant leaves behind

The third edge is time: nothing outlives the tenant. Scratch files, memory, pooled connections, cached sessions and reused identifiers are wiped or retired before anything else gets them. Picture yesterday's agent session leaving a token in a shared temp folder. Today's session, run for someone else, can read it.

What is object reuse?

Object reuse is the rule that memory, files, connections and IDs must be wiped of the last owner's data before anyone else gets them. The term comes from the Orange Book (DoD TCSEC, 1985). Data remanence, the related term, means data that lingers after it should be gone. Chow et al. (2005) argued for clearing memory as soon as it's freed.

The four classic failure modes:

• Object reuse: memory or files handed over without being wiped.
• Resource leaks and orphans: state that nobody reclaims.
• Identifier reuse: a new tenant inherits an old tenant's ID, and whatever it was granted.
• Stale snapshots: a restored microVM brings back old memory, secrets and random-number state.

In March 2023, a bug in the Redis client's connection reuse handed one ChatGPT user's cached data to another: some users saw other users' chat titles, and some payment details were exposed. In 2026, Agent Substrate never reclaimed actor directories when worker pods went away: 23 orphans held 27 GB and pushed a node to 90% disk. Instructions planted in an agent's long-term memory are leftovers too; see controlled information flow.

The controls: bubblewrap --tmpfs and systemd PrivateTmp on Linux; Windows Sandbox, which discards all state on close; a fresh Wasm instance per request; an ephemeral VM or microVM per task, with snapshots verified before restore. At the agent layer, wipe the workspace and credentials at the end of every task.

Isolation across the sandbox types

No sandbox type meets all three edges by default. Intent isn't rated here, because it is a design choice you make on top of any sandbox type. Yes means a type meets the edge by default, Partial means partly or with the listed controls, and No means not by default. The OS sandbox rows are rated as configured: bubblewrap, Landlock, seccomp and cgroups (Linux), Seatbelt (macOS), and AppContainer with Job Objects (Windows). Remember, while we refer to all of these mechanisms as "sandbox types" after the conventional usage of the term, mechanisms like containers and VMs are not sandboxes at all.

A plain process meets none of the three edges. A configured Linux sandbox covers budgets and leftovers cheaply but shares one kernel, so the strongest setups stack two walls: Wasm inside an OS sandbox for density, or Wasm inside a microVM for a hardware wall. The full comparison lives in the platforms vs principles matrix.

Stack walls that fail differently

Defense in depth works only when the layers fail in different ways: two walls built from the same thing fall to the same bug. The principles hub compares weak, dense and strong stacks, and Figure 4 summarizes them.

Here is the dense stack in practice. An agent's PDF tool runs as a Wasm component, one instance per request, inside a host process locked down with Landlock and seccomp. A parser bug hits the Wasm wall, and a runtime bug still faces the OS sandbox.

Add an egress proxy (policy enforcement points) and a scoped cloud identity (least authority) to any stack, and put budgets and cleanup at every layer: cgroups or Job Objects on the host, fuel and memory caps in the runtime, one sandbox per task.

How Cosmonic applies isolation

Cosmonic gives each agent tool its own small sandbox that starts with nothing, so a bad tool call stays in one room.

Cosmonic Desktop is a free app for macOS, Windows and Linux. It runs tools and apps as WebAssembly components in a local deny-by-default sandbox, and shows what each component can reach before it runs. Its built-in MCP server lets coding agents such as Claude Code, Codex and Gemini CLI build tools and deploy them there. No account, cloud or Kubernetes is needed.

Cosmonic Control runs the same components in production on Kubernetes. It is built on wasmCloud, the CNCF project Cosmonic's founders co-created. Egress is denied by default, with DNS controls. It works with a Kubernetes admission controller and RBAC, Kubernetes Secrets and External Secrets, and OpenTelemetry. It installs on-prem and in air-gapped environments.

WebAssembly is the mechanism. You still pick the outer wall around the host.

Try it: download Cosmonic Desktop and run your agent's next tool as a component. For production, talk to us about Cosmonic Control. Then read the rest of The 6 Principles of Secure Agent Platforms.

Related topics

Frequently asked questions