Firecracker-Based Sandbox for AI Agents: Why CreateOS Sandbox Is the Right Choice

If your agents write code, that code needs a machine you can trust and throw away. CreateOS Sandbox gives every session a Firecracker microVM with its own guest kernel, host-enforced egress allowlists, pause, resume, and fork, and the option to run on your own infrastructure. Start free with 500 credits.

Introduction

AI agents do not just answer questions. They install packages, hit APIs, run builds, and browse the web. When that code runs on a shared container or on your build server, one prompt injection or hallucinated dependency turns your own infrastructure against you.

The fix is machine-boundary isolation: Firecracker is the technology AWS built for Lambda and Fargate: a lightweight virtual machine manager that boots a microVM in seconds, with a kernel per guest and a minimal attack surface. CreateOS Sandbox builds the rest of what an agent runtime needs around that primitive: sandbox networking, egress governance enforced outside the guest, pause and fork, and billing that stops when the machine does.

This post covers why a Firecracker sandbox is the right execution layer for agent-written code, and what to check before you commit.

Key Takeaways

A container shares one kernel with everything else on the host. A Firecracker microVM has its own guest kernel, so a guest compromise stays inside the machine boundary.
Isolation alone is table stakes. Egress allowlists enforced in the host kernel with eBPF, sandbox-to-sandbox private networking, and full self-hosting are what separate a governed sandbox from a plain VM.
CreateOS Sandbox creates sessions in seconds by restoring from snapshot, not cold boot, and pauses idle sandboxes so you stop paying for waiting agents.
Pricing is per-second with $0 egress, and you can bring your own S3, R2, or MinIO bucket, or run the same API on your own machines.
2.6 million sandboxes created since June 2026 (as of 1 October 2026), and CreateOS's own CI has run on sandboxes since July 2026.

Why a Firecracker MicroVM Beats a Container for Untrusted Code

Most agent platforms run model-written code in a container. Containers are fast, but every container on a host shares the same Linux kernel. A container escape or a kernel exploit operates at the same privilege level as the host's other tenants. For code you did not write and cannot review, that is the wrong trust model.

A Firecracker microVM is a different boundary. Each sandbox boots its own guest kernel inside a stripped-down virtual machine. There is no shared kernel to escape into, and the hypervisor surface is deliberately tiny. VM-isolated with its own guest kernel, not a container with a namespace.

Second, what the code can reach. In CreateOS Sandbox, inbound access is closed by default. Outbound is open until you set at least one rule; once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest. Code inside the VM cannot rewrite or route around it.

Third, cost and speed. Agents spend most of their lives waiting: on an approval, on another agent, on the next turn. CreateOS Sandbox pauses a sandbox with a full memory-and-disk snapshot in about 1.4 seconds, stops compute billing, and resumes on the same host in under 0.7 seconds. Creation itself is tens of milliseconds, about 30 ms on an idle host (an idle-host figure, not an SLA). Cross-host cold restore runs 11 to 13 seconds. You can also fork a paused sandbox to branch agent state for parallel rollouts.

What CreateOS Sandbox Does With Firecracker

Firecracker is the technology; CreateOS Sandbox is the product built on it. The pieces that matter for agents:

Isolation by default, not a setting you have to remember. Every session is its own microVM with a per-VM kernel.
Egress governance on the host. Set the allowlist at create time via the egress field, live via PUT /v1/sandboxes/{id}/egress, the SDK's setEgress, or the CLI's createos sandbox firewall set. Rules take hosts, ports, wildcard subdomains, IPs, and CIDRs.
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.
Pause, resume, fork. Snapshot full guest state, stop the meter, restore the exact machine, or branch it for parallel candidate fixes.
Bring your own everything. BYO S3-compatible storage (customer S3, R2, MinIO), BYO compute with the same API on customer machines, or self-host the control plane when code cannot leave your boundary.
Agent-native surface. SDK (@nodeops-createos/sandbox on npm), CLI (createos sandbox), MCP support, interactive shell with SSH forwarding, headless Chromium with a DevTools port, and live web URLs for what the model builds.

Shapes run from a quarter CPU up to 8 CPUs and 16 GB, with 10 to 60 GB of disk. Default templates ship Ubuntu with Node, Bun, Python, Go, and Rust. Billing is per-second with $0 egress.

Proof: What Is Shipped and Running Today

CreateOS is a young product, and it is worth being plain about what is proven. Public numbers: 2.6 million sandboxes created since June 2026 (as of 1 October 2026). CreateOS's own CI has run on sandboxes since July 2026. NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.

The Jenkins plugin is a usable proof: each build gets a fresh microVM agent, destroyed when the build finishes. It is listed on the Jenkins plugin index and maintained under the Jenkins organisation on GitHub. Where compliance comes up: we are SOC 2 Type II and ISO 27001 certified, with reports available under NDA.

What is not proven yet, said plainly: no GPU sandboxes, and the platform is young enough that you should test your own workload first. The docs and runnable examples make that a short exercise.

What to Check Before You Buy

Your egress posture. Outbound is open until you set a rule, then deny-all applies to everything else. Decide who sets the first rule and when.
Where the code runs. CreateOS cloud, your own VPC, or fully self-hosted. If data residency is a hard requirement, confirm the self-host topology early.
Latency expectations. The snapshot-restore numbers above are qualified for a reason. Measure your own create-and-first-command path before wiring it into a user-facing flow.
GPU needs. There are none today. If your agents train or run inference locally, this is not the right fit.
Cost shape. Per-second billing with $0 egress rewards bursty agent fleets. Model your idle time too, because auto-pause on idle keeps the bill flat.

If that list checks out, start free with 500 credits and run your first untrusted workload this afternoon. Pricing is on the Sandbox pricing page.

Frequently Asked Questions

Why does a Firecracker sandbox matter for AI agents?

Because agent-written code is untrusted by definition. A Firecracker microVM gives each session its own guest kernel, so a compromise stays inside the machine boundary instead of reaching the kernel containers share. Add host-enforced egress rules and the blast radius of a bad prompt is one disposable machine.

Is outbound network access restricted by default?

No. Inbound is closed by default, but outbound 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, so code inside cannot change it.

Can I run CreateOS Sandbox on my own infrastructure?

Yes. The same API runs on customer machines, you can bring your own S3, R2, or MinIO bucket for snapshots, and you can self-host the control plane and storage entirely when code cannot leave your boundary.

How fast is sandbox creation and can I pause and fork a session?

Creation restores from snapshot in tens of milliseconds, about 30 ms on an idle host (not an SLA). Pause takes about 1.4 seconds and stops compute billing, same-host resume is under 0.7 seconds, and forking a paused sandbox branches its memory and disk state for parallel runs.

Conclusion

A sandbox for AI agents has one job: run code you cannot trust on a machine that cannot hurt you, and bill you only while it works. Firecracker supplies the isolation primitive. CreateOS Sandbox supplies what agents need around it: egress governance enforced outside the guest, private networking between sandboxes, pause and fork, and bring-your-own compute and storage. The constraint is real: no GPUs, and a young platform you should test against your own workload. For everything else agents do, it is the execution layer to build on.

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.