microsandbox
microvmmicrovm-toolopen sourceA self-hostable sandbox that boots OCI images in ~100ms via libkrun, with a careful filesystem-passthrough and model.
microsandbox runs untrusted workloads, AI agents, user code, CI jobs, inside fast local via libkrun (KVM on Linux, HVF on macOS), booting OCI images in under ~100ms and spawning each VM directly from an SDK with no daemon. A code-level security review rated its hardware isolation and filesystem-passthrough containment highly, finding no path-traversal or symlink escape. Its structural gap is the second wall: there is no seccomp, Landlock, or namespace confinement of the host process, so a memory-safety bug in a host-side device backend would land with the launching user's full authority.
Strengths
- Real hardware isolation via libkrun (KVM/HVF), booting OCI images in ~100ms
- Filesystem passthrough is carefully contained, no traversal/symlink escape found in audit
- Zero information leakage across the June 2026 study's 28 probes, tied best in that set
- Keeps its engine current on a 1-3 month bump cadence, the opposite of the frozen-pin problem that affects e2b and arrakis
- Daemonless, self-hostable, driven directly from an SDK
Limitations
- No seccomp/landlock/namespace confinement of the host VMM process, no second wall (our source review's H2 finding, independently measured as seccomp mode 0 on all 16 threads with 11 of 14 kernel-LPE primitives reachable)
- Ships no engine-side hardening at all: all seven standard layers in that study were left to the operator to stack
- Zero published CVEs, but with no upstream fuzzer this is the absence of a finding rather than evidence of soundness
- Default ingress fails open on published ports
- The 'unexploitable secrets' claim reduces to upstream TLS cert verification, not the advertised DNS pin
Files & editor
edit-insideProgrammatic microVMs (MCP/SDK-driven); you run code in them rather than edit interactively.
How you get your project into the environment and edit it. Shared-kernel routes bind-mount host files for your desktop editor; own-kernel routes keep files in the guest, so a desktop editor attaches over remote, or you edit inside. Mounts and remote editing.
Secrets
secrets: brokeredSecrets are interpolated into outbound requests by the egress proxy, so the sandboxed code only ever sees a placeholder. It cannot read or exfiltrate the real value; stealing a secret reduces to defeating the proxy's upstream TLS verification.
The realistic agent threat is exfiltration, not a kernel escape. Keeping credentials out of the code's reach is what defends against a prompt-injected agent stealing your keys. Keeping keys out of the blast radius.
VMM second wall
VMM second wall: noneno seccomp or Landlock confinement of its own host process (verified in source, and independently measured at seccomp mode 0 across all 16 VMM threads).
The second wall confines the VMM itself, so a compromised device backend can't own the host. It's separate from the hardware boundary every microVM already has. The two walls, explained.