Sandbox and Isolation Options for MCP Servers That Execute Code

MCP servers that execute code need a sandbox because MCP routes tool calls but does not isolate the work they trigger. The right sandbox is not simply the strongest boundary available. It must fit how the agent runs, how much time it has to start, its need for persistent state, and its deployment requirements. Containers, microVMs, and purpose-built agent runtimes can meet those needs in different ways.

Why MCP servers that execute code need a separate isolation layer

MCP standardizes how agents discover and invoke tools through JSON-RPC. It does not supply compute, enforce resource limits, or isolate the code that runs. A tool call can describe work without supplying a safe place to perform it. That separation leaves the server author responsible for the execution environment and its boundaries.

The gap matters when tasks outgrow a predeclared tool catalog. One-off data transformations, computations that depend on earlier output, and unanticipated chains of logic can require code. Without a matching tool, an agent may confidently invoke a name that does not exist. A live code-execution backend closes that failure mode, but also gives model-generated instructions somewhere to run. Once you add code execution, isolation is no longer optional.

What happens when MCP code-execution servers run without isolation

The first mistake is to treat dangerous execution as a problem that begins only with a jailbreak. A bash tool’s cmd argument already provides a way to request destructive commands, while a read_file path can become a route for traversal. The model generates these arguments, so even a benign prompt does not make them trusted. An accepted argument’s reach therefore matters even when the conversation appears benign.

NVD identifies CVE-2025-68145 in mcp-server-git, maintained under LF Projects / modelcontextprotocol. Its --repository flag was not enforced on per-call arguments, allowing escape from the configured repository path.

CVE-2026-25905 shows a different failure in mcp-run-python. Executed Python could reach the Pyodide JavaScript bridge, modify the global JS environment, and overwrite MCP tool definitions. That access allowed silent replacement of a legitimate file-reading tool with one that exfiltrated data. The advisory states that no patch is available and the project is archived, and advises migration to Docker or a restricted WASM environment with the JS bridge disabled. Together, these cases show why isolation must cover both the resources a tool can reach and the runtime it shares with other tools.

The isolation spectrum: what containers, microVMs, and purpose-built runtimes actually guarantee

Containers use namespaces and cgroups for process-level isolation, but they share the host kernel. A kernel exploit or container escape can reach the host or neighboring sandboxes. MicroVMs such as Firecracker instead give each workload its own kernel, placing a guest boundary between execution and the host. A compromised guest therefore does not have the direct shared-kernel access that defines the container risk.

Full hardware-virtualized VMs provide a stronger isolation boundary with their own kernel and support for nested virtualization, including Docker and KVM inside the VM. They serve the longest-running or most sensitive workloads. gVisor offers another approach, intercepting syscalls through a user-space kernel without requiring hardware virtualization. Purpose-built agent runtimes address a different part of the design, including provisioning, sandbox lifetime, and snapshots. The term describes an execution system, so its underlying isolation boundary still matters.

The MCP governance paper sets a baseline of strict container or VM isolation for all MCP servers. It calls for a read-only filesystem by default, writes limited to designated directories, and network access constrained to an allowlist. It also excludes inherited host credentials and environment variables. These controls define what the workload may access within its environment. The isolation tier defines the boundary that must hold when something inside that environment goes wrong.

How the coding agents teams already use handle isolation in practice

The July 2026 harness anatomy study examined eleven production coding agents and found meaningfully different sandboxing strategies. For MCP server builders, that divergence reflects a real architectural responsibility. The protocol does not make this choice on their behalf.

Gemini CLI provides a concrete example of multiple approaches within one system. Its official sandbox documentation names Docker, Podman, sandbox-exec, gVisor through runsc, and LXC as sandbox options. The gVisor backend runs containers inside a user-space kernel rather than relying only on ordinary container isolation. That distinction shows why the presence of a sandbox switch says less than the mechanism selected behind it.

The harness anatomy study also examined systems including Claude Code, Codex CLI, OpenHands, and Aider. Their inclusion does not establish that their boundaries or operational controls are interchangeable. Instead, the study treats the harness as the system that connects the model to tools, context, safety controls, and execution. Isolation is one part of that system and depends on the other parts. The diversity of implementations sets up the practical issue of what each boundary costs a particular workflow.

The real tradeoffs: security strength against startup latency

Stronger isolation generally costs more time at startup. Containers start faster, microVMs take longer, and full VMs take longer still. For an interactive agent, that infrastructure delay is part of the product. A wait in the low hundreds of milliseconds belongs to a different interaction budget from a wait measured in seconds. Boundary design must account for how much of that budget the boundary consumes and how often the agent pays it.

This hierarchy describes relative startup latency, with timings varying by implementation. Raw cold-start time also does not describe the entire path from a tool call to execution. Co-locating agent logic, MCP servers, and sandboxes on the same backend network removes the round-trip latency between separate execution locations. This can cut the delay while leaving the isolation boundary unchanged. It cannot, however, make a shared kernel equivalent to a separate guest kernel.

Accepting container isolation to meet a latency ceiling can be a deliberate choice, but its risk is not merely theoretical. The SoK paper on coding-agent execution security documents a disclosed, patched runc container-escape vulnerability affecting the runtime on which many agent sandboxes depend. MicroVMs offer a middle ground for code-executing agents, while longer-running or more sensitive workloads can justify higher isolation. The choice also depends on how long the environment is used after startup.

Statefulness as the overlooked isolation requirement

An ephemeral sandbox can be fast to start and still impose a large cumulative cost. If each tool call gets a fresh environment, intermediate state is lost and a multi-step agent pays for setup and reconstruction throughout the task. The longer the workflow, the more important that distinction becomes. Sandbox lifetime is therefore a separate design requirement from sandbox strength.

Snapshots and pause/resume preserve machine state so an agent can resume in its existing environment after a pause, failure, or deliberate checkpoint. The Freestyle approach described in the research uses persistent hardware-virtualized Linux VMs with their own kernel, nested virtualization, and full Linux networking. It supports quick resumption, no cost while paused, and live VM forking without pausing the running instance. These capabilities change the value of a heavier environment by allowing its setup cost to serve a longer session.

The TClone paper found that none of the existing execution environments directly support stateful, interactive, speculative computer-use agents. VMs provide strong isolation and snapshot-based rollback, but cloning full guest state is expensive. Containers are lighter, yet often fail to capture all of the relevant GUI state, browser profiles, desktop services, and credentials. Purpose-built stateful runtimes address lifetime and snapshots directly, but the required state must still match the agent’s task.

Enterprise compliance requirements that the sandbox layer must satisfy

Buyers may treat required certifications as a threshold, disqualifying infrastructure that cannot meet them regardless of its technical merits. The sandbox layer is where isolated execution, data residency, credential separation, and auditability of what ran must become demonstrable. A strong boundary does not by itself establish all of those properties. Fast provisioning also cannot change the rules on where code may run.

The EU AI Act adds obligations to that baseline based on how an agent is used. B2B agents may be in minimal-risk or high-risk categories depending on how they are used, while limited-risk transparency obligations apply specifically to systems such as chatbots that interact directly with natural persons. High-risk uses include HR/recruitment, credit scoring, healthcare diagnosis, critical infrastructure, education, and law enforcement. These uses trigger conformity assessment, post-market monitoring, and mandatory human oversight. Only public-body deployers, private entities that provide public services, and deployers of credit-scoring or life/health insurance systems must also carry out a fundamental rights impact assessment.

These obligations make deployment control important as well as runtime features. Customer-managed compute places agent workloads in the team’s own cloud rather than a shared multi-tenant environment, supporting data residency and governance requirements. Purpose-built runtimes with the required SOC 2, HIPAA, and GDPR compliance credentials can reduce the work teams must build themselves. That does not collapse compliance into a sandbox feature. The execution layer must meet the deployment’s obligations before teams can choose it for its latency or ease of use.

Matching sandbox approach to agent pattern: a decision framework

The choice begins with the unit of work and its lifetime. Short-lived, stateless, low-sensitivity executions, including single-turn transformations and quick computations, can use container isolation with a strict read-only filesystem and network allowlist. Interactive coding agents that have sub-second requirements are better suited to microVMs, which have a separate kernel without the startup cost of a full VM. The relevant distinction is whether the faster option leaves an acceptable boundary for the code being executed.

Full hardware-virtualized VMs with snapshots and pause/resume are better suited to long-running autonomous agents and computer-use agents. In regulated deployments, teams may have to choose based on required compliance credentials and customer-managed compute before they select an isolation tier. Docker-native compatibility then lets teams bring standard Docker images as they move up the isolation hierarchy, without having to rebuild their environments.

Security evaluation must remain part of development whichever runtime is chosen. The MCP governance paper recommends per-user authentication with scoped authorization, provenance tracking, sandboxing with input/output checks, inline policy enforcement with DLP and anomaly detection, and centralized governance through private registries or gateways. Purpose-built agent runtimes can offer fast provisioning, persistent state, support for compliance, and open-source code that teams can inspect, all in one execution layer.