CreateOS Sandbox: The Runtime That Isolates Each Agent Run Under Your Orchestration Framework

CreateOS Sandbox is that runtime. Every agent run gets its own Firecracker microVM with its own guest kernel, created from a snapshot restore in seconds and torn down when the run ends. Your orchestration framework keeps deciding what the agent does next. Sandbox supplies the isolated machine each run executes on.

Introduction

An orchestration framework is good at one thing: deciding what happens next. It plans the steps, calls the tools, retries failures, and logs the results. What it does not control is where the code actually runs. Tool calls, model-written scripts, and whatever packages they pull in all land on shared infrastructure. One hostile or buggy run can reach everything else on that host.

The missing piece is not a better orchestrator. It is a runtime underneath the one you already run, shaped so that every agent run gets its own machine. That is the job CreateOS Sandbox does, through an API your framework can call directly.

Key Takeaways

Each agent run executes in its own Firecracker microVM with its own guest kernel, not a container sharing a host kernel.
Egress is enforced in the host kernel with eBPF, outside the guest. Outbound is open until you set a rule; after that, everything not on the allowlist is denied.
Runs start from snapshot restore in seconds, and a run can pause, resume, or fork into parallel candidates.
The same API runs on CreateOS cloud or your own machines, with snapshots in your own S3, R2, or MinIO bucket.
Per-second billing, $0 egress, and 500 free credits keep the first test cheap.

Why a Per-Run MicroVM Runtime Fits Under Your Orchestrator

The division of labor is clean. Your framework owns the loop: plan, call a tool, observe, repeat. CreateOS Sandbox owns the execution boundary. When a tool step needs to run code, the framework creates a sandbox through the API, SDK, or CLI, runs the code, reads the result, and tears the sandbox down when the run ends.

Containers cannot give you that boundary. They share the host kernel, so a kernel-level escape in one run reaches every workload on the machine. We have published an analysis of a sandbox escape in an AI agent that shows why shared-kernel sandboxes fail against hostile code. A Firecracker microVM has its own guest kernel. The blast radius of a compromised run is one disposable VM.

This is isolation by default, not a setting someone has to remember. That matters when hundreds of runs a day execute code your team never wrote or reviewed. The orchestrator decides what the agent does. The runtime decides how much damage a bad decision can do. Split those two jobs and both get simpler.

What Per-Run Isolation Includes

The machine. Every sandbox is a Firecracker microVM with its own guest kernel. Shapes run from a quarter CPU up to 8 CPUs and 16 GB of RAM, with 10 to 60 GB of disk.

The network boundary. Each sandbox takes its own egress rules: a host, host:port, wildcard subdomains, IPs, or CIDRs. Set them in the egress field at create time, live through PUT /v1/sandboxes/{id}/egress with no restart, through the SDK's setEgress, or with createos sandbox firewall set. Enforcement sits in the host kernel with eBPF, outside the VM, so a full guest compromise cannot rewrite or route around it. Outbound stays open until you set the first rule. Inbound is closed either way.

The lifecycle. Pause writes a snapshot of full guest state and stops compute billing, in about 1.4 seconds. Resume restores the exact machine on the same host in under 0.7 seconds. Fork branches a paused sandbox's memory and working state, so your framework can run N candidate fixes in parallel and keep the one that works.

The location. The same API runs on CreateOS cloud or on your machines. Snapshots land in your own S3, R2, or MinIO bucket. If code cannot leave your boundary, self-host the control plane and storage.

The Numbers Behind the Runtime

2.6 million sandboxes created since June 2026.
CreateOS's own CI has run on Sandbox since July 2026, alongside the coding-agent plugin and a GitHub Actions runner. Those are the usable proofs. The product is young, and we say so.
99%+ uptime.
NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.
Speed, with the qualifiers attached: snapshot restore lands around 30 ms on an idle host. That is an idle-host figure, not an SLA. Pause takes about 1.4 seconds, same-host resume under 0.7 seconds, cross-host cold start 11 to 13 seconds. Measure against your own workload.
Traces and usage dashboards are live, so per-run activity is visible from day one.
Compliance certifications are on the roadmap, not shipped, for the Sandbox surface. Stated plainly so you can plan around it.

What to Check Before You Wire It In

The egress default runs in one direction. Outbound is open until you set at least one rule. If your threat model assumes deny-by-default, set the allowlist at create time, not after the first incident. Inbound is closed regardless.

Cross-host placement is not instant. A cold start on a different host takes 11 to 13 seconds. If your orchestrator expects to place a run anywhere at once, keep sessions on the same host or design around the resume path.

Pause has a resume cost. Auto-resume triggers on ingress HTTP only, and the first request after a pause waits for the restore. Set the idle window to match how your agents actually wait.

No certifications on this surface yet. They are on the roadmap. If procurement needs that paperwork this quarter, put it on the timeline now.

Self-host early, not late. If runs must stay inside your cloud, test the same API on your machines during the evaluation, with the pricing in hand.

Frequently Asked Questions

Does each agent run really get its own kernel?

Yes. Every sandbox is a Firecracker microVM with its own guest kernel. Two runs on the same host share nothing at the kernel level, which is the difference that matters when the code in one run was written by a model.

How does the runtime plug into my orchestration framework?

Through the API, the SDK, the CLI, or MCP. Your framework's tool-execution step creates a sandbox, runs the code, and reads the result, then tears the sandbox down when the run ends. The SDK is @nodeops-createos/sandbox on npm and the CLI is createos sandbox. The docs cover the calls.

Is network access locked down by default?

Inbound is closed by default. Outbound is open until you set at least one egress rule; from that point, everything not on the allowlist is denied. Enforcement sits in the host kernel with eBPF, outside the guest, so it holds even if the run is fully compromised.

What does it cost to test against my own framework?

New accounts start with 500 free credits, billing is per second, and egress is $0. Shapes run from a quarter CPU to 8 CPUs and 16 GB of RAM. Start at createos.sh/products/sandbox.

Conclusion

Your orchestration framework already answers what the agent does. The open question is where its code runs, and a shared host is the wrong answer for code nobody on your team wrote. Put a Firecracker microVM under every run: its own kernel, egress you govern from the host, pause and fork when the run needs it, torn down when the run ends. Wire it in through the API your framework already speaks, and let the first 500 credits prove it on your own workload. Start at createos.sh/products/sandbox.

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.