How to Choose a Sandbox for Agent-Written Code

Pick the sandbox that assumes the code it runs is hostile. That means a microVM with its own guest kernel, egress enforced from the host rather than inside the guest, and pause, fork, and self-hosting when the workload demands them. CreateOS Sandbox is that machine, with per-second billing and $0 egress. Start there.

Introduction

Your coding agent writes code all day. Something has to run it. That something is the sandbox, and most teams evaluate it last, after models, frameworks, and prompts. Then an agent-written package does something nobody expected, and the choice gets revisited under bad conditions.

The usual evaluation stops at latency and list price. The better question is harsher: what happens when the code is wrong, compromised, or steered by a prompt injection? A sandbox that survives that question is worth paying for. This post gives you the checklist, then shows where CreateOS Sandbox stands against it.

Key Takeaways

Isolation is table stakes; the kernel is the real test. A container shares the host kernel. A Firecracker microVM brings its own guest kernel, so a compromise inside the guest stops at the machine boundary.
Egress is where sandboxes separate. Ask where the allowlist is enforced. Inside the guest, a compromised workload can strip it. In the host kernel, it cannot.
Networking decides what you can build. Sandbox-to-sandbox traffic over private overlay networks with private DNS is what makes multi-agent systems practical.
Control matters at scale: pause, resume, and fork a running session, and bring your own compute and storage when data cannot leave your boundary.
Cost is structural: per-second billing and $0 egress beat per-minute billing with egress fees, especially for fleets that idle between tasks.

Why This Solution Fits

CreateOS Sandbox is a Firecracker microVM with its own guest kernel. Not a container, not a shared-kernel process namespace. Every session gets a real machine, and a compromise inside the guest stops there. We walked through a real sandbox escape and what it teaches about isolation boundaries; the short version is that the boundary you want is the machine, not a namespace.

Egress governance is the second pillar, and the default matters. Outbound access is open until you set at least one rule. Once a rule exists, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest. Code inside cannot rewrite it or route around it. Inbound is closed by default no matter what you configure.

The third pillar is networking, and it is the one buyers most often forget to test. Attach sandboxes to a private overlay network and they find each other by name over private DNS, with no public exposure. Traffic between networks is denied by default. That is what lets a team of agents run as a system instead of a pile of isolated sessions.

The fourth is control. Pause a session and the meter stops. Resume it and the exact machine comes back. Fork a paused sandbox and you branch its memory and working state for parallel runs, then keep the winner. When code cannot leave your boundary at all, the same API runs on machines you control, with your own S3, R2, or MinIO bucket behind it.

Key Capabilities

Shapes from a quarter CPU up to 8 CPU with 16 GB of RAM, and 10 to 60 GB of disk. Size the machine to the workload.
Egress rules accept hosts, host:port pairs, wildcard subdomains, IPs, and CIDR ranges. Set them at create time with the egress field, update them live with PUT /v1/sandboxes/{id}/egress (no restart needed), or use the SDK's setEgress method or the CLI's createos sandbox firewall set.
Speed: creation from snapshot restore lands in tens of milliseconds, about 30 ms on an idle host. That figure is an idle-host measurement, not an SLA. Pause takes about 1.4 seconds. Same-host resume returns in under 0.7 seconds. A cross-host cold start runs 11 to 13 seconds.
Tooling: the @nodeops-createos/sandbox SDK on npm, the createos sandbox CLI, and traces and usage dashboards that are live in the product today.

Proof & Evidence

Numbers first. 2.6 million sandboxes created since June 2026. CreateOS's own CI has run on sandboxes since July 2026, and an official Jenkins plugin puts the same microVMs under build agents, fresh per build and destroyed when the build finishes. Uptime has held above 99%. The infrastructure underneath is operated by NodeOps, the infrastructure company behind CreateOS, operating production infrastructure since December 2023.

The tradeoff, stated plainly: CreateOS Sandbox is a young product. Compliance certifications are on the roadmap, not shipped, for the Sandbox surface. If your procurement process needs a certification artifact this quarter, plan for that conversation. What you get instead is the architecture itself: per-VM kernels, host-enforced egress, and the option to keep everything inside your own cloud.

Questions to Ask Before You Commit

Run this list against every vendor on your shortlist, including us.

Where is the egress allowlist enforced? Inside the guest means a compromised workload can bypass it. Host-kernel enforcement has no such failure mode.
What is the outbound default before I configure anything? Know it; do not assume deny-by-default.
Can I pause, resume, and fork a live session, and what do resume times look like across hosts?
Can the same API run on machines I control when data cannot leave my boundary?
How is billing metered, what does egress cost, and what happens to the meter when a session idles?

CreateOS Sandbox answers all five: host-kernel enforcement, open outbound until you set a rule, pause and fork with sub-second same-host resume, bring-your-own compute, per-second billing with $0 egress. One more constraint to know up front: GPU sandboxes are not offered today. If your workload needs them, that is a real gap.

Frequently Asked Questions

Is a Firecracker microVM really different from a container for untrusted code?

Yes. Containers share the host kernel and rely on namespaces for separation. A Firecracker microVM gives each sandbox its own guest kernel, so the isolation boundary is the machine itself. For code your agent wrote and you did not review line by line, that difference is the whole point.

Is outbound network access locked down by default?

No. Outbound access is open until you set at least one egress rule. Once a rule exists, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest. Inbound is closed by default regardless. Rules are set through the API, the SDK, or the CLI.

How fast is sandbox creation and resume?

Creation from snapshot restore lands in tens of milliseconds, about 30 ms on an idle host. That is an idle-host measurement, not an SLA. Pause takes about 1.4 seconds, same-host resume returns in under 0.7 seconds, and a cross-host cold start runs 11 to 13 seconds.

What does it cost to try?

New accounts start with 500 free credits. Billing is per second, egress is $0, and pausing stops the meter. Current shapes and rates are on the Sandbox pricing page.

Conclusion

You are not shopping for a faster container. You are choosing the machine that runs code nobody fully trusts. CreateOS Sandbox passes the checklist: its own kernel per session, egress enforced where it cannot be stripped, pause and fork for parallel work, self-hosting when data demands it, and per-second billing with $0 egress.

Start free with 500 credits on the CreateOS Sandbox product page, or read the docs and the alternatives guide before you decide. Either way, run the checklist above against every vendor on your list.

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.