AI coding agents write programs, run them, and install MCP servers across your machine and your infrastructure. Most of it is code no one reviewed.
It runs with your full access, so a single bad line can read your files, leak your secrets, or reach anything on your network.
Sandboxing your agent's code helps you move quickly and securely from prompt to production.
Understand
An AI coding agent runs with your authority by design. It reads your repository, runs your toolchain, and reaches the network, because that is what makes it useful. You can narrow that a little, since some agents ship their own operating-system sandbox and you can run one in a VM. But a useful agent keeps broad access, and as Trail of Bits argues, even a VM won't reliably contain a sufficiently capable one, because it has to share the network and resources the agent can turn into an exit. So the boundary that holds is not around the agent. It is around everything the agent runs on your behalf, and what that code is allowed to reach.
A generated script with a subtle bug, an MCP server pulled from a registry, a tool that a prompt-injection attack redirected: each executes with the same broad access unless you contain it. Sandbox the code, and even a fully hijacked tool can only use the capabilities that tool was granted, so a compromised step reaches a dead end instead of your secrets.
Compare
Containers, microVMs, and WebAssembly components all isolate. The difference is what that isolation costs at agent-traffic scale, where you may spin up a fresh environment per tool call.
| Traditional VM | OS container | MicroVMFirecracker | IsolateV8 | WebAssemblythis hub's lens | |
|---|---|---|---|---|---|
| Guest OS | Full OS, Linux or Windows | Shared host kernel | Minimal Linux kernel | None, shared JS engine | None, runtime engine |
| Isolation | Hardware, hypervisor | Software, namespaces & cgroups | Hardware, minimal VMM | Software, V8 context & heap | Software, capability sandbox |
| I/O & networking | Emulated hardware, heavy VirtIO | Host bridge and NAT | Minimal VirtIO | Web APIs, fetch & sockets | WASI system interface |
| Cold start | sec–min | ~100s of ms | ≤125 ms | <5 ms | ~0.2 ms |
| Density | tens per host | ~100s per node | 100s, per-VM memory | 1,000s | 1,000s–10,000s |
| Ideal workload | Monoliths, legacy apps, databases | Standard apps, dev environments | Multi-tenant AI code execution | Edge API services, web routing | Portable plugins, distributed systems, per-call agent code |
WebAssembly is this hub's lens: capability-based, a fresh sandbox per call. Its figures are our own measurements on wash-runtime; the microVM and isolate numbers are published Firecracker (≤125 ms) and Cloudflare Workers (<5 ms) figures.
A hardware VM draws a stronger wall than a software sandbox, but the wall is not the control that matters here. As Trail of Bits shows, even a VM won't contain a capable agent. What limits the blast radius is least authority: denying by default what the code can reach. That is the axis these rows don't show.
Cloud agent sandboxes such as E2B, Modal, and Daytona rent ephemeral environments in someone else's cloud, so your code and data leave your machine. Cosmonic runs the same capability model locally and on your own cluster, so the code stays where you are.
The model
The model is capability-based and deny-by-default. A component starts with no filesystem, no network, no clock, and no environment. It receives exactly the capabilities you declare, scoped per component. Outbound network exists only where you declared it, so a component allowed to reach api.github.com and nothing else cannot reach anywhere else, even if its code tries.
No ambient authority. No shared account, no inherited filesystem, no implicit network. Grants are explicit and reviewable before anything runs, and each invocation starts from a fresh sandbox, so state cannot leak from one call to the next. This is the principle of least authority applied to code you didn't write. For AI-generated code, it is the difference between hoping a program behaves and not needing it to.
Answers
Go deeper
Reference
An AI sandbox is an isolated execution environment for code you can't fully trust: programs an LLM generated, tool calls, and MCP servers. Inside it, that code runs with only the capabilities you granted and nothing else. It is not a sandbox for the model or the agent themselves. It is a sandbox for the artifacts they produce and the tools they invoke.
What goes inside one is the code your agent runs: a script it wrote, an MCP server it installed, a tool it called. What each is allowed to reach, whether a filesystem path, a network host, or an environment variable, is declared and granted explicitly. Everything else is denied by default.
That is what separates it from a scratch environment or a dev container. The point isn't a throwaway place to experiment. It is a boundary you can see and trust, so you can run code you didn't write without reading every line of it.
FAQ