Key takeaways
- Local-first microVM sandboxes with hardware isolation and sub-200ms startup — secrets never leave the host
- libkrun-based architecture provides stronger isolation than containers with near-container startup speed
- YC X26 batch with 5K+ GitHub stars — early stage but shipping fast with SDKs for Python, JavaScript, and Rust
FAQ
What is Microsandbox?
Microsandbox is an open-source tool for running untrusted code in hardware-isolated microVMs on your own machine, designed for AI agents that need secure code execution without cloud dependencies.
How does Microsandbox differ from E2B?
Microsandbox is self-hosted and local-first using libkrun microVMs, while E2B is a cloud-hosted platform using Firecracker. Microsandbox keeps secrets on-host; E2B offers managed infrastructure at scale.
What languages does Microsandbox support?
Microsandbox provides SDKs for Python, JavaScript/Node, and Rust, with OCI-compatible images supporting any language runtime.
Is Microsandbox production-ready?
Microsandbox is still experimental. It works on macOS and Linux, with Windows support in progress. Expect breaking changes as the project matures.
Executive Summary
Microsandbox is an open-source, self-hosted sandbox platform that uses libkrun microVMs to provide hardware-isolated execution environments for AI agents. Built in Rust by Zerocore AI (YC X26), it offers sub-200ms startup times with true VM-level isolation — combining the security of traditional VMs with the speed of containers.
| Attribute | Value |
|---|---|
| Company | Zerocore AI |
| Founded | 2024 |
| Funding | Y Combinator (X26 batch) |
| Founder | Stephen Akinyemi |
| Headquarters | Unknown |
Product Overview
Microsandbox takes a fundamentally different approach from cloud-hosted sandbox platforms like E2B. Instead of sending code to remote infrastructure, Microsandbox runs lightweight microVMs locally on your own machine. Secrets never leave the host, networking is programmable from the outside, and each sandbox gets its own dedicated kernel.
The project was created by Stephen Akinyemi, who previously built infrastructure at Zerocore AI. He has articulated the thesis that containers are insufficient for running truly untrusted AI-generated code — shared kernels mean sophisticated attacks can escape. MicroVMs solve this with hardware-level isolation while maintaining the speed developers expect.
Key Capabilities
| Capability | Description |
|---|---|
| MicroVM Isolation | Each sandbox runs in its own VM with a dedicated kernel via libkrun |
| Sub-200ms Startup | Boot a full VM faster than most container solutions |
| Secret Injection | Credentials injected at the network layer — the guest never sees real values |
| Programmable Networking | Inspect DNS, analyze HTTP traffic, block exfiltration at the IP level |
| OCI Compatible | Works with standard container images (Docker Hub, GHCR) |
| MCP Server | Built-in Model Context Protocol server for AI agent integration |
Product Surfaces / Editions
| Surface | Description | Availability |
|---|---|---|
| CLI | msb command for server, sandbox, and project management | Beta |
| Python SDK | pip install microsandbox | Beta |
| JavaScript SDK | npm install microsandbox | Beta |
| Rust SDK | cargo add microsandbox | Beta |
| MCP Server | Native MCP integration for AI agents | Beta |
| Project Sandboxes | Sandboxfile-based project config (like package.json for sandboxes) | Beta |
Technical Architecture
Microsandbox uses libkrun, a lightweight virtualization library from the containers project that leverages KVM (Linux) or Hypervisor.framework (macOS) for hardware isolation. Unlike Firecracker (used by E2B and AWS Lambda), libkrun includes its own Virtual Machine Monitor and uses Transparent Socket Impersonation (TSI) for networking — avoiding the overhead of virtual network interfaces.
┌──────────────────────────────────────┐
│ Host Machine │
├──────────────────────────────────────┤
│ ┌──────────┐ ┌──────────┐ │
│ │ Sandbox │ │ Sandbox │ ... │
│ │ (microVM)│ │ (microVM)│ │
│ │ own │ │ own │ │
│ │ kernel │ │ kernel │ │
│ └────┬─────┘ └────┬─────┘ │
│ │ │ │
│ ┌────┴──────────────┴─────┐ │
│ │ libkrun (KVM / HVF) │ │
│ └─────────────────────────┘ │
│ ┌─────────────────────────┐ │
│ │ msb server (Rust) │ │
│ │ + secret injection │ │
│ │ + network policy │ │
│ └─────────────────────────┘ │
└──────────────────────────────────────┘
Key Technical Details
| Aspect | Detail |
|---|---|
| Isolation | libkrun microVMs (hardware-level, KVM/HVF) |
| Cold Start | ~187ms (measured) |
| Persistence | Files saved to ./menv directory on host |
| Language | Rust (core), with Python/JS/Rust SDKs |
| Open Source | Yes (Apache 2.0) |
| Self-Hosting | Self-hosted only — no cloud service (yet) |
| Platforms | macOS (working), Linux (working), Windows (WIP) |
Secret Management — The Killer Feature
Microsandbox's most innovative feature is network-layer secret injection. When you provide an API key with an allowed host:
- The sandbox sees only a random placeholder (e.g.,
msb_placeholder_a7f3...) - When the sandbox makes a verified TLS connection to the allowed host, Microsandbox swaps the placeholder for the real credential at the network layer
- If the sandbox tries to send the placeholder to any other host, only the worthless placeholder is transmitted
This means even if malicious code reads environment variables and tries to exfiltrate them, the real credentials never leave the host. DNS rebinding protection, cloud metadata blocking, and DNS-to-IP binding activate automatically.
Strengths
- True hardware isolation — Each sandbox has its own kernel; container escape attacks are irrelevant
- Local-first — Secrets and data never leave your machine; no cloud dependency
- Secret injection — Network-layer credential management prevents exfiltration by design
- Fast startup — Sub-200ms boot for a full microVM is impressive, nearly matching container speed
- Programmable networking — DNS inspection, HTTP interception, DLP, and domain allowlisting built in
- Apache 2.0 — Permissive license with no AGPL restrictions (unlike Daytona)
- Rust codebase — Memory-safe foundation for security-critical infrastructure
- OCI compatible — Use standard Docker/container images; no proprietary format
Cautions
- Experimental — Project explicitly warns of breaking changes and missing features
- No cloud offering — Self-hosted only; teams wanting managed infrastructure need to look elsewhere
- Small team — Community-driven with ~3 contributors; bus factor is a concern
- No GPU support — CPU-only microVMs; ML inference workloads need alternatives
- Windows not ready — Only macOS and Linux are working; Windows is WIP
- Limited ecosystem — 5K stars vs E2B's 6K+ with 1M monthly SDK downloads; early adoption curve
- No enterprise features — No SOC2, no RBAC, no audit logging (yet)
Pricing and Licensing
| Aspect | Detail |
|---|---|
| License | Apache 2.0 (permissive) |
| Cost | Free and open source |
| Cloud Service | "Launching soon" per website |
| Self-Hosted | Fully supported, single curl install |
Microsandbox is currently free. The website indicates a cloud product is coming ("Launching soon"), which will presumably be the monetization path. YC backing suggests a cloud-hosted or managed version is on the roadmap.
Competitive Positioning
Direct Competitors
| Competitor | Differentiation |
|---|---|
| E2B | E2B is cloud-hosted with Firecracker; Microsandbox is local-first with libkrun. E2B has enterprise scale; Microsandbox has stronger secret management |
| Daytona | Daytona is a full dev platform (Docker-based); Microsandbox is a focused execution primitive with hardware isolation |
| Modal | Modal offers serverless GPU compute; Microsandbox is local, CPU-only, security-focused |
| CodeSandbox | CodeSandbox targets browser-based dev; Microsandbox targets agent-driven code execution |
When to Choose Microsandbox Over Alternatives
- Choose Microsandbox when: Running untrusted AI-generated code locally, secrets must stay on-host, or you need maximum isolation without cloud costs
- Choose E2B when: You need managed infrastructure at enterprise scale with compliance certifications
- Choose Daytona when: You need a complete development platform with team collaboration features
- Choose Modal when: You need GPU access for ML workloads
Ideal Customer Profile
Best fit:
- AI agent developers who need to execute untrusted code locally with maximum security
- Teams handling sensitive API keys who cannot tolerate credential exposure to third parties
- Self-hosting enthusiasts who want cloud-grade isolation on their own hardware
- Developers building MCP-integrated tools that need sandboxed execution
- Security-conscious startups building coding agents or data pipelines
Poor fit:
- Enterprise teams needing managed cloud infrastructure with SLAs
- Organizations requiring SOC2 compliance and audit trails
- Teams needing GPU access for ML workloads
- Windows-only development environments
- Teams wanting a mature, battle-tested production platform today
Viability Assessment
| Factor | Assessment |
|---|---|
| Financial Health | Early — YC X26 backing, no announced funding round |
| Market Position | Challenger — Differentiated on local-first and secret management |
| Innovation Pace | Rapid — Active development, frequent commits, new features shipping |
| Community/Ecosystem | Growing — 5K+ GitHub stars, 238 forks, active Discord |
| Long-term Outlook | Promising — Strong technical thesis, YC backing, but needs to ship cloud product and grow team |
Microsandbox occupies a unique position in the AI sandbox space: it is the only major player betting entirely on local-first, self-hosted microVM isolation. If the thesis is correct that AI agents will increasingly run on developer machines (not just in the cloud), Microsandbox could become the default execution layer. The secret injection feature alone is a meaningful innovation that competitors will likely copy.
Bottom Line
Microsandbox is the most security-focused AI sandbox available today. The combination of hardware-isolated microVMs, network-layer secret injection, and programmable networking makes it technically superior to container-based alternatives for running truly untrusted code.
The trade-off is maturity. This is experimental software from a small team with no cloud offering yet. You are betting on the project and the thesis, not on proven enterprise infrastructure.
Recommended for: Developers building AI agents locally who need maximum isolation and cannot tolerate secret exposure to third-party infrastructure.
Not recommended for: Enterprise teams needing managed, compliant, production-grade sandbox infrastructure today.
Outlook: With YC backing and a compelling technical story, expect a cloud product launch in 2026. The local-first positioning and secret management innovation give Microsandbox a real shot at carving out a significant niche alongside E2B. Watch for the cloud launch and first enterprise customers.
Research by Ry Walker Research • methodology