What It Does
Microsandbox is a local-first sandbox platform that runs lightweight microVMs on the developer’s own machine using libkrun (KVM on Linux, Hypervisor.framework on macOS). Unlike cloud-hosted alternatives like E2B, secrets never leave the host. The platform’s signature feature is network-layer secret injection: the guest sees only random placeholders, and real credentials are swapped in at the network layer only for verified TLS connections to allowed hosts. Built in Rust by Zerocore AI (YC X26).
The project emphasizes programmable networking — DNS inspection, HTTP interception, and domain allowlisting are all controlled from outside the sandbox. Each sandbox gets its own dedicated kernel with hardware-level isolation.
Key Features
- libkrun microVM isolation: Hardware-level isolation via KVM (Linux) or Hypervisor.framework (macOS) — stronger than Docker, comparable to Firecracker
- Network-layer secret injection: Sandbox sees placeholders; real keys swapped at network level only for verified TLS to allowed hosts — credentials cannot be exfiltrated even from compromised sandbox
- Sub-200ms startup: Boot times under 200ms with true VM-level isolation, rivaling container-based solutions
- Programmable networking: DNS inspection, HTTP interception, domain allowlisting controlled from outside the sandbox
- Dedicated kernel per sandbox: Each microVM runs its own Linux kernel, preventing kernel-level cross-sandbox attacks
- Built-in MCP support: Native Model Context Protocol server for AI agent integration
- Rust implementation: Memory-safe implementation reducing the attack surface of the sandbox runtime itself
- Cross-platform: Supports both Linux (KVM) and macOS (Hypervisor.framework)
Use Cases
- Handling sensitive credentials locally: Teams that cannot send API keys, database credentials, or customer tokens to third-party cloud sandbox providers
- Development-time agent sandboxing: Running AI coding agents (Claude Code, Cursor, etc.) with hardware isolation on developer machines without cloud dependency
- Secret-sensitive automation: Agents that need to interact with production APIs but must never have direct access to credentials
Adoption Level Analysis
Small teams (<20 engineers): Good fit for security-conscious small teams. Self-hosted on local machines with no billing. The local-first model eliminates cloud costs entirely. However, requires familiarity with VM concepts and the project is experimental.
Medium orgs (20-200 engineers): Moderate fit. The local-first model means each developer runs their own sandbox infrastructure. There is no centralized management, monitoring, or shared pool of sandboxes. For team-wide adoption, you need a convention around configuration and a way to distribute sandbox images.
Enterprise (200+ engineers): Does not fit well in its current form. No centralized management plane, no SOC2, no audit logging, no managed offering. The local-first model is fundamentally at odds with enterprise requirements for centralized governance and observability.
Alternatives
| Alternative | Key Difference | Prefer when… |
|---|---|---|
| E2B | Cloud-hosted Firecracker microVMs, managed SaaS | You want managed infrastructure and can tolerate sending code to a third party |
| Daytona | Docker-based, faster cold starts (90ms), Computer Use | You need desktop automation and can accept Docker-level isolation |
| Sprites (Fly.io) | Cloud-hosted Firecracker with persistent state and checkpoints | You need cloud persistence with checkpoint/restore |
| Zerobox | OS-native process isolation, single binary | You want even lighter isolation without VMs |
Evidence & Sources
- GitHub repository — Zerocore AI
- Pixeljets: Daytona vs Microsandbox comparison
- Medium: Microsandbox solving code execution security
- AI Agent Sandboxes Compared — Ry Walker
Notes & Caveats
- YC X26 — very early stage: This is a pre-seed startup. No production case studies, no security audits, no track record at scale. Evaluate for experimentation, not production deployment.
- No independent security audit: The network-layer secret injection mechanism is architecturally novel but has not been audited by independent security researchers. The claim that credentials “cannot be exfiltrated even from compromised sandboxes” is unverified.
- Self-hosted only: No managed offering exists or is planned. You own the entire stack.
- libkrun is less battle-tested than Firecracker: Firecracker powers AWS Lambda at massive scale. libkrun has narrower production exposure. Unknown failure modes at scale.
- Local-first means no centralized control: Each developer runs their own sandboxes. There is no central dashboard, no shared pool, no team-wide policy enforcement.
- Network interception attack surface: The network-layer secret injection introduces its own attack surface (potential MITM, DNS rebinding). These risks are theoretical but have not been formally analyzed.