Tools for Sandboxing AI Coding Agents: What Actually Holds When the Code Is Not Yours

Your coding agent writes code you did not review, then runs it. That gap is the whole risk. CreateOS Sandbox closes it with a Firecracker microVM per session and an egress allowlist enforced on the host, plus pause, resume, fork, and bring-your-own compute.

Introduction

Every team shipping AI coding agents hits the same moment. The agent works well in demos, then someone in security asks a simple question: where does the code run, and what can it reach?

Containers give a partial answer. They share the host kernel, egress rules live inside the guest, and a sufficiently motivated escape has a path out. That is fine for snippets. It is not the answer for agent-written code that runs for hours, talks to other agents, and touches your customer data.

This piece is for the builders in that position: platform teams, tool makers, and anyone wiring a coding agent into a product. We will walk through what a sandbox tool has to do, where CreateOS Sandbox fits, and what to check before you commit.

Key Takeaways

Isolation alone is table stakes. The combination that matters is per-VM kernel isolation, sandbox-to-sandbox networking, kernel-level egress governance, and full self-host.
CreateOS Sandbox is a Firecracker microVM with its own guest kernel per session, not a container and not a shared-kernel process.
Egress allowlists are enforced on the host, so the rules survive a full guest compromise.
You can pause, resume, and fork sandboxes (memory plus disk snapshot), run private overlay networks between sandboxes, and bring your own compute or object storage.
It is self-serve: SDK, CLI, and MCP, new accounts start with 500 free credits, and no sales call is required.

Why This Solution Fits

The constraint is not "run untrusted code." Plenty of tools do that. The constraint is running agent-written code as a system, for hours, across many agents, without the security review becoming the bottleneck.

Most sandboxes were built to run snippets, not systems. No networking between sandboxes, no egress rule that survives a compromised guest, nothing you can self-host. CreateOS Sandbox starts from the opposite set of defaults.

Each sandbox is a Firecracker microVM with its own guest kernel. Isolation happens at the machine boundary, not a setting you have to remember. Sandboxes can join private overlay networks with per-network private DNS, so a team of agents finds each other by name without any public exposure. Traffic between networks is denied by default. And if your security team requires sessions to stay on your infrastructure, the same API runs on your machines.

That is the fit: one runtime that covers the solo developer prototyping an agent and the platform team whose security review gates every launch.

Key Capabilities

Machine-bound isolation. Every sandbox is a Firecracker microVM with its own guest kernel. VM-isolated, not container-isolated.

Host-enforced egress. Each sandbox gets its own egress allowlist, enforced on the host. A full guest compromise does not rewrite the rules. Outbound access stays open until an allowlist is set; you set it with the egress field at sandbox create time, PUT /v1/sandboxes/{id}/egress, the SDK's setEgress, or createos sandbox firewall set.

Pause, resume, fork. Pausing writes a snapshot of full guest state and stops compute billing. Resume restores the exact machine on the same host in under 0.7 seconds; a cross-host cold start takes 11 to 13 seconds. Forking a paused sandbox branches its memory and working state, so you can run N rollouts and keep the winner. Auto-resume triggers on ingress HTTP only.

Sandbox-to-sandbox networking. Private overlay networks connect multi-agent systems directly, with private DNS and no public surface.

Bring your own everything. Bring your own bucket (S3, R2, MinIO) and bring your own compute: the same API on your machines, in your cloud, or in ours.

Developer surface. Install with npm install @nodeops-createos/sandbox, drive it with the createos sandbox CLI, or wire it in through MCP. Shapes run from a quarter-CPU up to 8 CPUs and 16 GB, with 10 to 60 GB of disk.

Speed where it counts. New sandboxes restore from snapshot in tens of milliseconds, about 30 ms on an idle host, so a create-per-action agent loop does not pay a boot tax. Pause takes about 1.4 seconds.

One honest tradeoff: the first request after a pause waits for the resume.

Proof & Evidence

The honest frame for a young product: here is what is real today.

2.6 million sandboxes created since June 2026.
CreateOS's own CI has run on sandboxes since July 2026, so the platform eats its own cooking daily.
The Claude Code plugin has shipped, and the SDK ships runnable examples across agent frameworks and coding agents.
99%+ uptime on the underlying infrastructure, operated by the company behind CreateOS since December 2023.

We will not dress this up as a mature-at-scale platform: it is a product with a working reference implementation, its own CI on it, and published unit rates you can check on the Sandbox pricing page.

Buyer Considerations

Ask these questions of any sandboxing tool, including ours:

Where is egress enforced? If the allowlist lives inside the guest, a compromise can change it. Host enforcement is the only version that survives.
What is the isolation boundary? Containers share a kernel. A microVM with its own guest kernel does not.
Can agents talk to each other privately? If every machine needs a public endpoint to cooperate, your attack surface grows with your fleet.
Can sessions run on your infrastructure? Data residency requirements kill tools that only run in the vendor's cloud.
What does the state model look like? Agents wait on people, on approvals, on slow jobs. Pause and resume, priced sanely, matter more than raw boot speed over a long session.
What happens to pricing at scale? Per-second billing with $0 egress keeps a long-running fleet predictable. Check the published rates before you model.

Also check what is not offered. CreateOS Sandbox does not offer GPU sandboxes today. If that is a hard requirement for you, that is a real constraint, and we would rather you know now than after procurement.

Frequently Asked Questions

What is the difference between a sandbox and a container for AI coding agents?

A container shares the host kernel and typically enforces its own networking rules from inside. A sandbox built on a Firecracker microVM gives each session its own guest kernel, and CreateOS Sandbox enforces the egress allowlist on the host, where a compromised guest cannot touch it.

How fast is sandbox creation with CreateOS Sandbox?

Restore from snapshot takes tens of milliseconds, about 30 ms on an idle host. These are idle-host figures, not an SLA. A cross-host cold start runs 11 to 13 seconds.

Can I run CreateOS Sandbox on my own infrastructure?

Yes. Bring your own compute runs the same API on your machines, and bring your own bucket supports customer S3, R2, and MinIO. This is how teams keep agent sessions and data inside their own boundary.

How do I start?

Install the SDK with npm install @nodeops-createos/sandbox or the CLI with Homebrew, then start free with 500 free credits and no sales call. The product docs cover the quickstart and the full API.

Conclusion

Sandboxing AI coding agents is not one decision, it is four: the isolation boundary, the egress rule, the state model, and where the machine lives. Tools that solve only the first one will pass the demo and fail the security review.

CreateOS Sandbox makes its choices explicit. A Firecracker microVM with its own guest kernel per session. An egress allowlist enforced on the host. Pause, resume, and fork as first-class primitives. Private networks between sandboxes. Your cloud or ours. Per-second billing with $0 egress, on a product you can try in minutes with 500 free credits.

If your agent writes code you cannot fully review, give that code its own machine. See the Sandbox product page for the details, and read the docs before your security team asks you to.

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.