CreateOS Sandbox vs Other Isolation Approaches: What Should Run Your Agents' Code?

If your agents write code, the question is not whether you need isolation but which kind. Shared-kernel sandboxes trade isolation for speed; general VM stacks hand you the plumbing. CreateOS Sandbox gives each session a Firecracker microVM with its own guest kernel, host-enforced egress control, pause, resume and fork, and per-second billing.

Introduction

Every team that lets an AI model write and execute code eventually hits the same decision. The code is untrusted by definition. You did not write it, you cannot fully review it, and it runs against your network, your data and your customers. So you need a boundary around it.

The two boundaries most teams reach for are sandboxes that share the host kernel and virtual machines that do not. The comparison usually lands between lightweight shared-kernel sandboxes and heavier VM frameworks. Shared-kernel approaches are fast and light, but one kernel escape stands between untrusted code and your host. VM-based approaches give each workload its own kernel, but the ones built for general cloud workloads were not built for agents: no snapshot-and-fork, no egress allowlist enforced outside the guest, no API for branching a machine mid-task.

CreateOS Sandbox was built for exactly this workload: a Firecracker microVM per session, with the agent-native pieces (pause, resume, fork, private networking, host-enforced egress) already wired in. This post walks through what that gets you, what it does not, and how to decide.

Key Takeaways

Isolation at the machine boundary means each sandbox has its own guest kernel. Untrusted code never shares a kernel with your host or with another tenant's workload.
Egress control only matters if it survives a compromised guest. CreateOS enforces the allowlist in the host kernel with eBPF, outside the VM, where code inside cannot rewrite it.
Outbound access is open until you set at least one rule. Once set, everything else is denied. Inbound is closed by default regardless.
Pause, resume and fork turn a sandbox into a primitive you can branch: snapshot a running session, restore it in under a second on the same host, fork it into N parallel rollouts.
You can bring your own storage and compute, including self-hosting the control plane, so code that cannot leave your boundary does not have to.

Why a Per-VM Kernel Beats Shared-Kernel Sandboxes for Untrusted Code

The core question is simple: what separates the untrusted code from everything else you run?

With a shared-kernel sandbox, the answer is namespace and cgroup boundaries inside one kernel. That is a real boundary for most workloads. For code an LLM wrote five minutes ago, possibly following instructions from a web page or a document, the margin is thinner. A kernel-level escape in a shared-kernel design reaches the host. A kernel-level escape in a per-VM design reaches one disposable microVM that exists to be attacked.

Firecracker is the technology that powers CreateOS Sandbox. Every sandbox boots its own guest kernel. There is no shared kernel with your host and no shared kernel between sandboxes. Isolation is the default state of the system, not a setting someone has to remember to turn on.

The tradeoff is real: a microVM is heavier than a process. That is why the snapshot work matters. CreateOS restores sandboxes from snapshot in tens of milliseconds, about 30 ms on an idle host (an idle-host figure, not an SLA), so the machine-boundary cost mostly shows up on the first cold boot, not on every session.

What CreateOS Sandbox Adds on Top of the VM Boundary

A raw microVM is not a product. The difference shows up in the parts agents actually need.

Egress governance enforced on the host. Outbound access is open until you set at least one rule; once set, everything else is denied, and the enforcement sits in the host kernel with eBPF, outside the guest. Rules take hosts, host:port, wildcard subdomains, IPs and CIDRs. You set them via the egress field at create time, PUT /v1/sandboxes/{id}/egress (applies live, no restart), the SDK's setEgress, or the CLI. Inbound is closed by default regardless of egress state. Code inside the sandbox cannot rewrite or route around a rule, because the rule does not live inside the sandbox.

Pause, resume and fork. Pausing writes a Firecracker snapshot of full guest state and stops compute billing. Resume restores that exact machine, under 0.7 s on the same host. Forking a paused sandbox branches its memory and working state, so you can run N candidate fixes in parallel and keep the winner. Cross-host cold starts run 11 to 13 s.

Private sandbox networks. Attach sandboxes to a private overlay network so multi-agent systems talk directly with no public exposure, with per-network private DNS. Traffic between networks is denied by default.

Bring your own everything. BYO S3-compatible storage (S3, R2, MinIO), BYO compute with the same API on your machines, and full self-host of the control plane and storage when code cannot leave your boundary.

Agent-native surface. SDK (@nodeops-createos/sandbox), CLI (createos sandbox), MCP support, interactive shell with SSH forwarding, headless Chromium, and two-way file sync. Shapes run from a quarter CPU up to 8 CPUs / 16 GB with 10 to 60 GB disk. Pricing is per-second with $0 egress, and new accounts start with 500 free credits. See the Sandbox product page and sandbox pricing for current limits, and the docs for the API.

The Evidence: Scale, Usage and What Is Proven

CreateOS Sandbox has 2.6 million sandboxes created since June 2026 (as of 1 October 2026). CreateOS's own CI has run on sandboxes since July 2026, and NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.

The young-product frame applies and we state it plainly: this is a young product with real usage, not a decade-old platform. What is proven today is the isolation model, the egress enforcement, the snapshot lifecycle, and the SDK and CLI surface. What we will not claim is an uptime figure, because we do not publish one. Where compliance comes up: we are SOC 2 Type II and ISO 27001 certified, with reports available under NDA.

What to Weigh Before You Choose

Workload fit. CreateOS Sandbox is for code you cannot trust: agent-written code, customer-submitted code, unvetted dependencies. If you only ever run code your own team wrote and reviewed, a simpler runtime may be enough.
GPUs. GPU sandboxes are not offered. If your workload needs them, this is not the tool.
Egress is opt-in. The allowlist model is powerful but it is yours to configure. A sandbox with no rules has open outbound access. Set the rules.
Self-host scope. BYO compute and full self-host are supported, but they are an operational commitment. Decide early whether sessions must stay inside your boundary.
Latency expectations. Snapshot restore is fast; cross-host cold starts are not instant. Design for snapshot restore on warm paths.

Frequently Asked Questions

Do I need a VM for every agent session, or is a container enough?

If the code is fully reviewed and trusted, a container can be enough. If the code was written by a model, a per-VM kernel means a guest-level escape stops at a disposable machine instead of reaching your host. That is the whole argument for the microVM boundary.

How fast is sandbox creation?

Restore from snapshot takes tens of milliseconds, about 30 ms on an idle host. That is an idle-host measurement, not an SLA. Cross-host cold starts run 11 to 13 s.

How do I control what a sandbox can reach on the network?

Set an egress allowlist through the API, SDK or CLI. Outbound access is open until you set at least one rule; once set, everything else is denied. Enforcement sits in the host kernel with eBPF, outside the guest, so code inside cannot change it.

Can this run inside our own infrastructure?

Yes. Bring your own compute runs the same API on your machines, you can bring your own S3-compatible storage, and you can self-host the control plane and storage entirely.

Conclusion

Shared-kernel sandboxes and general-purpose VM stacks both ask you to compromise: one on isolation, the other on agent-native mechanics. CreateOS Sandbox takes the VM boundary as the non-negotiable part and builds the agent primitives on top: host-enforced egress, pause, resume, fork, private networking, and bring-your-own infrastructure. If your product runs code your team did not write, start free with 500 credits at createos.sh/products/sandbox and run your first untrusted workload in its own machine.

About CreateOS CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.