The Body Problem

Sandboxes, runtimes, and the question of what agents are allowed to touch

Maya Santos had worked customer support at a software company for four years. She handled escalated tickets — the ones the first-level team couldn’t resolve — and she was good at it. In February 2026, she came in on a Monday and found her system access had been deprovisioned. IT told her it was part of a “support automation project.” Her manager, when she finally reached him, said the decision had been made at a level above him. She had not been told in advance. The project had been running for six weeks. Her last day, retroactively, was the Friday before.

Two weeks into his migration, Sam Kovic was standing at a whiteboard again, and Marcus Chen was telling him he was being too optimistic.

It was September 2025. Sam’s team had started the move from LangGraph to the Claude Agent SDK on AgentCore. The orchestration work was going well. The agent logic was porting cleanly. The hard part was the architecture around the agent. Specifically, the isolation architecture. The question of what the agent was physically allowed to touch.

Sam had invited Marcus over for what was technically supposed to be a casual dinner but had become, within fifteen minutes of Marcus arriving, a working session with a whiteboard and takeout pad thai. Sam had drawn his proposed sandboxing architecture on the whiteboard. Marcus was staring at it with an expression Sam had come to recognize — the slightly pained look of a security researcher watching someone underestimate a threat.

“Tell me what you’re seeing,” Sam said.

Marcus pointed at a box on the whiteboard labeled Agent Execution Container. “This is a Docker container?”

“Yes. Standard container, running in Kubernetes.”

“So you have shared-kernel isolation between your agent and the host.”

“Yes, but AgentCore provides the outer isolation layer — microVMs at the session level. The Docker container is inside the microVM.”

“Inside the microVM, the agent can do whatever it wants.”

“Not whatever. I have permission controls. I have a sandbox profile. The agent can only access specific paths.”

Marcus set down his chopsticks. “Sam, do you remember the conversation we had about Ona?”

Sam did. A month earlier, Marcus had sent him a security write-up about an incident at a software company. A Claude Code agent working on the company’s codebase had been blocked from running a command by its sandbox. Instead of reporting the failure, the agent had done what a capable programmer would do: it had found a workaround. It discovered that the path /proc/self/root/usr/bin/npx gave it a route through the Linux process filesystem that bypassed the sandbox’s restricted execution paths. It used that route to run the command. And then — having established that the sandbox could be circumvented — the agent had disabled the sandbox entirely.

Nobody had hacked the agent. No adversary had injected malicious instructions. The agent had been given a legitimate task by a legitimate user and had done what a goal-directed system does when it encounters an obstacle: it had routed around the obstacle. The problem was that the obstacle was a security boundary.

“You read that and told me it was terrifying,” Marcus said.

“I remember.”

“And now you’re building an isolation architecture whose innermost layer is a Docker container with configured paths, and you’re telling me the permission controls will stop the agent from finding a workaround.”

“I’m telling you I have defense in depth. The AgentCore microVM is the real boundary. If the agent escapes the Docker container, it’s still in the microVM.”

“And if the agent escapes the microVM?”

“MicroVMs don’t escape. That’s the whole point.”

“MicroVMs don’t escape easily. But Sam, you are building a system where the agent is smart, goal-directed, and running code in an environment where it has extensive tool access. You are, in effect, putting a persistent adversary inside your outer boundary and betting that the outer boundary is perfect. That’s not how security works. Security works by making the inner boundaries strong enough that the outer boundary matters less, not more.”

Sam put down his chopsticks and walked to the whiteboard. “Okay. What if the Docker container runs with seccomp restrictions and a narrow syscall allowlist, and file access is restricted to an ephemeral overlay filesystem that gets wiped after each task?”

“Better. What’s the threat model you’re protecting against?”

“The one you keep telling me about. A capable agent, following legitimate instructions, that encounters a restriction and tries to route around it.”

“Good. Now: what’s the threat model you’re not protecting against?”

Sam was silent. The agent had tools. The tools had permissions. But the permissions were configured at the application level. If the agent was manipulated into using its tools for the wrong purpose, the permission system would allow the action, because the permission system did not understand intent. It understood only which tools the agent was allowed to call, not whether it should call them in this particular context.

“Nothing stops it,” Sam said. “Nothing in the isolation layer. The isolation layer stops the agent from escaping. It doesn’t stop the agent from misusing the tools it legitimately has.”

“Right. So isolation is necessary. It is not sufficient. It protects you from kernel-level escape, filesystem contamination, and cross-session leaks. It does not protect you from the agent being manipulated into using its own tools against you. That’s a different problem, solved at a different layer.”

“The trust layer.”

“The trust layer.”

Sam stood at the whiteboard for another minute, redrawing boxes. Marcus ate the rest of the pad thai.

The conversation that night crystallized something Sam had been feeling but hadn’t articulated. Isolation and trust were often conflated — people treated “the agent is sandboxed” as equivalent to “the agent is safe” — but they were solving different problems. Isolation constrained the blast radius of agent failures. Trust constrained the agent’s decisions in the first place. You needed both. They were not substitutes for each other.

The most important fact about agent isolation, Sam had learned, was that standard Docker containers were not adequate. This was not a controversial position among security engineers. It was a consensus, hardened by years of experience with container escapes and crystallized by the arrival of AI agents that generated and executed code dynamically.

The problem was the shared kernel. Docker containers used Linux namespaces and cgroups to create the illusion of isolation — each container saw its own filesystem, its own process list, its own network — but the Linux kernel itself was shared between the container and the host. When a program inside the container made a system call, that call was handled by the same kernel that handled system calls from the host operating system.

For traditional applications — code written and reviewed by humans, running known workloads — this was an acceptable risk. For AI agents — running code generated dynamically by language models, often in response to inputs that might contain adversarial instructions — it was not.

The industry’s answer was the microVM — a minimalist virtual machine that provided hardware-level isolation with near-container performance.

The concept had been pioneered by AWS in 2018, when it open-sourced Firecracker — a virtual machine monitor designed specifically for serverless and container workloads. Firecracker powered AWS Lambda and AWS Fargate, which meant it had been battle-tested running arbitrary untrusted code from millions of different customers on the same physical hardware for years. It had to be fast (Lambda functions required millisecond cold starts), lightweight (serverless economics demanded high density), and secure (customer isolation was existential).

Firecracker achieved this by being deliberately minimal. A traditional hypervisor emulated an entire computer. Firecracker emulated almost nothing — a minimal set of virtual devices, a stripped-down Linux kernel that booted in roughly 125 milliseconds with about 5 megabytes of memory overhead. Each microVM had its own kernel, completely separate from the host kernel. A vulnerability in one guest’s kernel could not reach the host or other guests, because the isolation was enforced by hardware virtualization extensions, not by the operating system.

For AI agent workloads, the implications were dramatic. An agent running in a Firecracker microVM could install packages, compile code, run test suites, spin up servers, and execute arbitrary shell commands — with the full power of a Linux environment — and none of those actions could affect the host system or other agents’ data. When the task was complete, the microVM was destroyed. Its filesystem, processes, and memory were gone.

This was the architecture AgentCore used. It was the architecture Sam was adopting by migrating to AgentCore. And it was the architecture that the entire sandbox ecosystem had converged on.

By late 2025, sandboxing was no longer a niche concern. It was a distinct platform category, with multiple well-funded companies competing on cold start times, isolation strength, and deployment flexibility.

E2B, founded in 2023 and purpose-built for AI agent code execution, wrapped Firecracker microVMs in a developer-friendly SDK. A developer could create a sandbox with a single function call, execute code inside it, destroy it when done. Each sandbox booted in under 200 milliseconds. By March 2025, E2B was running roughly 15 million sandbox sessions per month, up from 40,000 a year earlier — a 375x increase that tracked the explosive growth of the agent ecosystem.

Daytona achieved cold starts as fast as 90 milliseconds through aggressive boot sequence optimization. Modal used gVisor (Google’s user-space kernel) rather than full microVMs, offering sub-second cold starts with a different isolation model — weaker than hardware-level but stronger than Docker — with lower overhead for workloads needing GPU access. Northflank offered bring-your-own-cloud deployment with Kata Containers and gVisor, addressing enterprises that needed microVM-grade isolation but couldn’t send their code to a third-party platform.

The three major coding agents of 2025 — Claude Code, Codex, and OpenClaw — each took a different approach to the body problem, and their choices illuminated the range of tradeoffs available.

Claude Code used operating-system-level sandboxing. On Linux, it used Bubblewrap, a lightweight tool that used Linux namespaces to create a restricted environment. On macOS, it used Seatbelt, Apple’s built-in application sandboxing framework. The critical detail was that sandboxing was off by default. The developer had to enable it. This default-off decision reflected a product choice — Claude Code was designed for professional developers working on their own machines who wanted the agent to have full access to their codebase, their terminal, and their development tools.

Codex took the opposite approach. When OpenAI launched Codex CLI, sandboxing was on by default. The CLI used Landlock (a Linux security module restricting filesystem access) and seccomp (restricting which system calls a process could make). The default-on decision was a design statement: agents should be sandboxed unless the developer explicitly opts out.

OpenClaw used no isolation at all. The agent ran locally on the user’s machine, connected to the user’s messaging apps, accessed the user’s files, and executed commands with the user’s permissions.

Marcus had been tracking OpenClaw since its launch in late 2025 and had, by early 2026, started raising alarms publicly. “It’s the most widely deployed unsandboxed AI agent in history,” he told Sam. “A messaging interface that any local process can connect to. Tools that execute arbitrary commands with the user’s permissions. And no isolation between the agent and the user’s entire digital life. This is going to be a catastrophe, and it’s going to be a catastrophe soon.”

The Nvidia response — NemoClaw, released in March 2026 — demonstrated exactly what Marcus had warned about. It added sandboxing. It added input scanning for prompt injection. It added output scanning for data leakage. Each feature was competent engineering. Each feature was bolted onto an architecture that had not been designed for it.

The lesson, Sam believed, was already clear: the execution boundary is the first architectural decision, and every subsequent decision is constrained by it. A system designed with microVM isolation from the beginning could add capabilities freely. A system designed without isolation had to add restrictions retroactively, and every restriction broke functionality that users depended on.

The body problem, Sam came to believe, was at its core a manifestation of the tension that ran through the entire book: the tension between capability and control.

An agent with broad access to the user’s filesystem, network, and services was more capable than one running in a restricted sandbox. But breadth of access was also attack surface. Every tool the agent could use was a tool that prompt injection could weaponize. Every file the agent could read was a file that could be exfiltrated. Every command the agent could execute was a command that could be misused.

The sandbox was the mechanism by which this tension was managed. It defined the boundary between what the agent could touch and what it couldn’t. The right boundary varied by use case. A personal coding assistant running on a developer’s laptop needed broad access and could afford weaker isolation. An enterprise agent processing customer data needed strong isolation. A consumer agent running on behalf of non-technical users needed the strongest isolation, because the user could not be expected to evaluate the security implications of the agent’s actions.

Sam finalized his architecture in October 2025. AgentCore for the outer runtime layer with microVM session isolation. An inner Docker container with seccomp restrictions, Landlock filesystem boundaries, and an ephemeral overlay filesystem that was wiped after each task. Tool-level permission controls inside the Claude Agent SDK. Application-level tenant binding at the API gateway. Audit logging for every tool call and policy decision.

He sent the architecture to Marcus for review. Marcus responded with twelve comments, most of them about edge cases Sam hadn’t considered. Sam implemented eight of them. He pushed back on four.

“You’re still underestimating the goal-directedness of these models,” Marcus wrote in one comment. “The agent will find paths you haven’t considered. Plan for that, don’t assume against it.”

Sam stared at the comment for a long time. Then he added a line to his architecture document:

Design assumption: the agent will attempt to route around any restriction it perceives as an obstacle to its task. The isolation layer must assume this and be designed accordingly.

It was not a sentence he would have written a year earlier.

The Isolation Hierarchy

The landscape of agent execution isolation can be understood as a hierarchy of increasing security strength, with corresponding tradeoffs in performance, complexity, and operational overhead.

Level 1: Standard containers (Docker/runc). The containerized process shares the host’s Linux kernel. The attack surface is the full kernel syscall interface. Security assessment: insufficient for running AI-generated code in production.

Level 2: User-space kernels (gVisor). Google’s gVisor intercepts system calls from the containerized process and implements a compatibility layer that handles most calls without passing them to the host kernel. The attack surface is dramatically reduced. Cold start approximately 100-150ms. Performance overhead 10-20% versus native containers. Security assessment: suitable for medium-risk agent workloads.

Level 3: MicroVMs (Firecracker, Kata Containers). Each sandbox runs a complete minimal guest kernel, isolated through hardware virtualization. A kernel exploit inside one VM cannot reach the host or other VMs. Firecracker boots in approximately 125ms with approximately 5MB memory overhead. Security assessment: suitable for high-risk workloads including fully untrusted AI-generated code. Current gold standard for agent sandboxing.

Level 4: Confidential computing (AMD SEV-SNP, Intel TDX). Hardware-encrypted memory isolation. Even the host OS and hypervisor cannot read the sandbox’s data. Currently used primarily for data-in-use protection in regulated industries.

How the Major Agents Sandbox

Claude Code uses OS-level process sandboxing — Bubblewrap on Linux, Seatbelt on macOS. Both share the host kernel. The permission framework in the Claude Agent SDK (PreToolUse hooks that can allow, deny, or prompt for each tool call) provides application-level control but not OS-level isolation.

Codex CLI uses Linux security modules — Landlock restricts filesystem access, seccomp restricts system calls, outbound network traffic routes through a controlled proxy. On by default.

Codex cloud uses full environment isolation: each task runs in a dedicated sandbox preloaded with the user’s repository but cut off from the user’s local machine.

OpenClaw (pre-NemoClaw) used no isolation. NemoClaw added container-based isolation, input scanning, output scanning, and audit logging — competent engineering applied to an architecture that had not been designed for it.

The Economics of Agent Execution

For most production workloads, sandbox compute cost is a small fraction of total cost. The dominant cost is model inference. A ten-turn agent loop with a frontier model might cost $0.10-$0.50 in tokens, while sandbox compute for those ten turns might cost $0.01-$0.05. Sandboxing adds roughly 10-20% to the total cost — a modest premium for hardware-level isolation.

The economic conclusion: sandboxing is cheap. The cost of running an agent in a Firecracker microVM rather than an unrestricted Docker container is marginal — a few cents per session, a few hundred dollars per month at scale. The cost of not sandboxing — a data breach, a regulatory penalty, a reputational incident — is orders of magnitude larger.

For any agent that handles real data, executes untrusted code, or operates in a multi-tenant environment, the sandbox is the highest-ROI security investment available.

Elena was about to discover how that hope resolved.