Sanbox's MicroVM Isolation: How Batteries-Included Sandboxes Change Agent Security Boundaries

A prompt is not a security boundary. Agents need files, tools, credentials, state, and network access. The question is where you draw the isolation line: process, container, or virtual machine.

Sanbox launched on Show HN with a batteries-included sandbox platform that uses MicroVM isolation, persistent filesystems, and resumable execution. It integrates with the OpenCode SDK as the execution harness and supports CLI usage from Codex, Claude Code, Cursor, and CI pipelines. Each sandbox runs in a dedicated MicroVM with configured resource limits, network policies, and filesystem snapshots that preserve artifacts, agent state, and conversation history.

This is among the first production-ready platforms to combine MicroVM isolation with resumability and persistent state for agent execution. Previous agent security tooling focused on process isolation (Swarm), browser-side orchestration (AG2B), and SOAR workflows (Tracecat), but none offered VM-level isolation with persistent state and snapshot-based resumability. The architecture raises specific questions about attack surface, snapshot mechanics, and the trade-offs between isolation strength and operational complexity.

Isolation Models: Process, Container, MicroVM

Agent sandboxing typically uses one of three isolation layers. Each exposes different attack surfaces and operational costs.

Isolation Layer	Attack Surface	Snapshot Mechanism	Resumability	Network Control	Startup Latency
Process (chroot, seccomp)	Shared kernel, syscall boundary	Process state dump	Limited (state dump)	iptables, network namespaces	<100ms
Container (Docker, gVisor)	Container runtime, shared kernel	Filesystem overlay, CRIU checkpoint	Partial (filesystem only)	CNI plugins, network policies	200-500ms
MicroVM (Firecracker, Cloud Hypervisor)	Hypervisor boundary, minimal guest kernel	VM snapshot, memory snapshot, filesystem overlay	Full (VM + filesystem)	Virtual network interface, firewall rules	Variable (platform-dependent)

Sanbox uses MicroVMs. This means each agent run gets a dedicated kernel, isolated memory space, and a virtual network interface. The hypervisor enforces resource limits (CPU, memory, timeout) and network policies at the VM boundary. An agent that exploits a kernel vulnerability or escapes a language runtime still cannot access the host or other sandboxes.

The cost is startup latency. MicroVMs typically take longer to boot than containers or processes. For long-running agent tasks (minutes to hours), this is acceptable. For sub-second function calls, it is not.

Resumable Execution: Snapshots vs. Replay

Sanbox claims resumable sandboxes. This could mean three things:

VM snapshot: Pause the MicroVM, save memory and disk state, resume later.
Filesystem checkpoint: Snapshot the filesystem, replay agent state from conversation history.
Event replay: Log tool calls and model activity, replay from a specific event.

The platform documentation mentions “filesystem snapshots with artifacts, agent state, and conversation history” and “resume from a saved filesystem snapshot with agent state and conversation history intact.” This suggests filesystem checkpointing, not full VM memory snapshots.

Note: The platform documentation does not publicly specify the exact snapshot mechanism (VM memory, filesystem overlay, or event replay). The analysis below infers filesystem checkpointing based on the mention of “filesystem snapshots” and “conversation history,” but this should be confirmed with the Sanbox team.

In practice, this likely means:

The filesystem is snapshotted at the block or overlay level (likely using copy-on-write).
Agent state (conversation history, tool call results, intermediate outputs) is serialized to disk.
When you resume, the MicroVM boots with the snapshotted filesystem, and the OpenCode SDK harness reloads the agent state.

This is cheaper than full VM snapshots (no memory state to save) but requires the agent runtime to serialize and deserialize state correctly. If the agent uses in-memory caches, database connections, or open file handles, those will not survive the snapshot.

OpenCode SDK Integration: Where Tool Calls Cross the Boundary

The OpenCode SDK is the execution harness. It sits inside the MicroVM and orchestrates the agent loop: read input, call the model, execute tool calls, write output.

Tool calls originate inside the MicroVM and produce effects (network requests, filesystem writes, subprocess spawns) that cross the isolation boundary:

Network egress: The agent makes HTTP requests to external APIs (model providers, data sources, webhooks). These requests leave the MicroVM through the virtual network interface, where network policies can log, rate-limit, or block them.
Filesystem writes: The agent writes files, logs, and artifacts to the persistent filesystem. These writes are captured in the snapshot and preserved across resume operations.

Subprocess spawns (e.g., running git, npm, or python) happen inside the MicroVM. The guest kernel enforces resource limits (CPU, memory, timeout) and prevents escape to the host. If the agent spawns a malicious subprocess, it is still contained within the VM boundary.

Critical security gap: The platform documentation mentions “controlled network” and “network policy,” but does not specify whether egress is allow-by-default or deny-by-default. For production agent workloads, you want deny-by-default with explicit allow rules for known API endpoints. This detail is not publicly documented and represents a blocking security issue that must be clarified before production deployment.

Persistent Filesystem: State Isolation Between Runs

Each sandbox has a persistent filesystem. This raises the question: how does state survive across sessions without leaking data between agent runs?

The answer depends on the snapshot mechanism:

Ephemeral base image: Each sandbox starts from a clean base image (e.g., Ubuntu 22.04 with Python, Node.js, and the OpenCode SDK). The filesystem is copy-on-write, so writes are isolated to the sandbox instance.
Persistent overlay: Writes are saved to a persistent overlay layer. When you resume, the MicroVM boots with the same overlay, so files, logs, and agent state are intact.
Snapshot cleanup: When you delete a sandbox, the overlay is deleted. No state leaks to the next run.

This is standard for container and VM platforms, but it requires careful management of secrets and credentials. If the agent writes an API key to disk, that key is preserved in the snapshot. If you share the snapshot or resume it in a different context, the key is exposed.

The platform should provide a secrets management layer (e.g., environment variables injected at runtime, not persisted to disk) and a cleanup policy (e.g., delete snapshots after N days, redact secrets before export).

Run Events: Observability and Audit Trails

Sanbox records a “live trail of run events” including tool calls, model activity, and agent state. This is critical for debugging, auditing, and compliance.

The event log should capture:

Input boundary: What task and files entered the sandbox.
Tool calls: Which APIs the agent called, with request and response payloads.
Model activity: Which model was called, with token counts and latency.
Filesystem writes: Which files were created, modified, or deleted.
Network egress: Which external endpoints the agent contacted.
Resource usage: CPU, memory, and timeout metrics.

The platform documentation shows an example event log:

00:02 harness.input.ready Input dossier extracted
00:05 agent.turn.started Agent turn started
00:11 agent.tool.completed

This is a good start, but production workloads need structured logs (JSON or protobuf) with full payloads, not just event names. You also need log retention policies, export to external observability platforms (e.g., Datadog, Grafana), and redaction of sensitive data (e.g., API keys, PII). The publicly available documentation does not show full payload examples or structured log formats.

Self-Hosting: Compliance and Control Plane Separation

Sanbox offers a self-hosting option for compliance requirements. This is critical for regulated industries (finance, healthcare, government) that cannot send agent workloads to a third-party cloud.

Self-hosting raises two questions:

Control plane separation: Does the self-hosted deployment include the control plane (API server, scheduler, snapshot storage), or does it phone home to Sanbox’s cloud for orchestration? “Phone home” means periodic license validation, telemetry reporting, or orchestration API calls to Sanbox cloud infrastructure. In air-gapped environments (no internet access), any phone-home requirement breaks the deployment.
Hypervisor requirements: Does the self-hosted deployment require a specific hypervisor (e.g., Firecracker, Cloud Hypervisor, KVM), or can it run on any VM platform?

The ideal architecture is a fully self-contained deployment with no external dependencies. The control plane, hypervisor, and storage layer all run in your VPC or on-premises cluster. The Sanbox cloud provides a hosted version for convenience, but the core platform is open and portable.

If the self-hosted deployment requires a phone-home connection for licensing, telemetry, or orchestration, that is a deal-breaker for air-gapped environments. The platform documentation does not clarify this point, and it should be confirmed before committing to self-hosting for compliance-sensitive workloads.

Architecture: CLI, Control Plane, MicroVM Fleet

The platform architecture has three layers:

CLI: Installed via npm, runs on the developer’s machine or CI job. Sends task bundles to the control plane, watches run status, and retrieves artifacts.
Control plane: API server, scheduler, and snapshot storage. Receives task bundles, allocates MicroVMs, enforces resource limits and network policies, and stores run events and snapshots.
MicroVM fleet: Pool of MicroVMs running the OpenCode SDK harness. Each MicroVM boots from a base image, loads the task bundle, executes the agent loop, and snapshots the filesystem on stop.

The CLI can fan out parallel runs (e.g., “evaluate an acquisition” with four agents: Financials GPT, Contract risks GLM-OCR, Market scan Kimi, Security posture GLM). Each run gets a dedicated MicroVM with isolated state and network access.

The control plane schedules runs across the MicroVM fleet, enforces quotas (e.g., max concurrent runs per user), and handles snapshot lifecycle (create, resume, delete).

Code Example: CLI Dispatch and Configuration

The CLI supports detach and reattach without stopping the run. This is useful for long-running tasks that outlive a terminal session.

# Start a run with resource limits and network policy
sanbox run \
  --template opencode-runner \
  --model kimi-k2.7-code \
  --cpu 2 \
  --memory 4GB \
  --timeout 15m \
  --network-policy deny-egress-except=api.openai.com,*.github.com \
  --detach

# List active runs
sanbox list

# Reattach to a run
sanbox attach 8fc2

# Resume a stopped run from snapshot
sanbox resume 8fc2

The --detach flag starts the run in the background and returns a run ID. The attach command reconnects to the run’s event stream. The resume command boots a MicroVM from the saved snapshot and continues execution.

The --network-policy flag (syntax inferred, not documented) should allow deny-by-default egress with explicit allow rules for trusted endpoints. Without this capability, the sandbox cannot enforce least-privilege network access.

This workflow assumes the control plane maintains a registry of active and stopped runs, with metadata (run ID, template, model, status, snapshot location). The CLI queries this registry to list, attach, and resume runs.

Questions to Validate with Sanbox

The following security-critical details are not documented and should be confirmed before production use:

Network policy default: Is egress allow-by-default or deny-by-default? Can you specify per-run network policies with explicit allow/deny rules?
Snapshot mechanism: Does resumability use VM memory snapshots, filesystem overlays, or event replay? How are in-memory state (database connections, open file handles) handled across resume?
Self-hosting control plane: Does self-hosting require phone-home to Sanbox cloud for orchestration, licensing, or telemetry? Can it run fully air-gapped?
Snapshot corruption recovery: How does the platform handle corrupted snapshots (disk failure, incomplete write)? Is there rollback to the last known good snapshot?
Network partition handling: If the MicroVM loses connectivity to the control plane, how long before it is killed? Is there a heartbeat protocol?
Resource exhaustion: What happens when the MicroVM fleet is full? Do new runs queue, fail, or trigger autoscaling?

Without answers to these questions, the platform’s security posture and operational reliability cannot be fully assessed.

Technical Verdict

Use Sanbox if:

Agent code is untrusted (third-party plugins, user-submitted scripts, code generation from LLMs) AND you need kernel-level isolation to prevent escape attacks.
Task duration is longer than 5 minutes AND resumability is required (e.g., multi-hour code review, compliance checks, data analysis that cannot complete in a single session).
Compliance audit trail is required (regulated industries, security orchestration, forensic analysis) AND you need full observability of tool calls, network egress, and filesystem writes.

Avoid Sanbox if:

Latency SLA is under 500ms (MicroVM startup overhead makes this infeasible for interactive UIs or high-frequency function calls).
Agent tasks are stateless function calls (no persistent state, no resumability needed, no benefit from snapshot overhead).
Agent code is fully trusted (internal tools, pre-vetted libraries) AND process or container isolation is sufficient.

Critical blocker: Confirm network policy default (allow vs. deny egress) with Sanbox before production deployment. If egress is allow-by-default, the sandbox is not secure-by-default and requires manual hardening for every run. A secure-by-default platform should deny all egress except explicitly allowed endpoints. Without this confirmation, the platform cannot be recommended for untrusted agent code.

Compared to alternatives:

vs. Tracecat SOAR: Sanbox provides stronger isolation (MicroVM vs. container) and resumable state, but Tracecat is purpose-built for security orchestration workflows with pre-built integrations. Use Sanbox for general-purpose agent execution with untrusted code; use Tracecat for security-specific workflows with trusted tools.
vs. AG2B browser isolation: AG2B isolates browser-based agents in separate processes with network sandboxing. Sanbox provides VM-level isolation for arbitrary code execution. Use AG2B for web scraping and browser automation; use Sanbox for code generation, data processing, and system-level tasks.
vs. Swarm process isolation: Swarm uses process-level isolation with resource limits. Sanbox uses MicroVM isolation with persistent state and snapshots. Use Swarm for lightweight, stateless agent tasks under 1 minute; use Sanbox for long-running, stateful workflows over 5 minutes that require resumability and stronger isolation.

Disclaimer: This analysis is based on public documentation as of the Show HN launch. The security-critical details listed above (network policy default, snapshot mechanism, self-hosting control plane) are not documented and must be confirmed with Sanbox before production use. Without these answers, the platform’s security posture cannot be fully assessed.