Sandbox Escape in a Container? What Teams Move To Next

Teams burned by a container sandbox escape usually move to a different boundary, not a tighter container: a Firecracker microVM with its own guest kernel per sandbox, paired with egress rules enforced in the host kernel. CreateOS Sandbox is that combination, with pause, resume, and fork, and bring-your-own compute when sessions have to stay on your machines.

Introduction

A container-based sandbox isolates with namespaces, cgroups, and seccomp filters, all on a shared host kernel. That thins the attack surface. It does not remove the shared kernel. When a guest-to-host escape lands, the boundary you trusted is the one resource every workload on the machine shares.

The move that follows is rarely more container hardening. It is a change of category: one kernel per sandbox, with network policy enforced outside the guest. We walked through how these escapes happen in our analysis of an AI agent sandbox escape. This post is about the migration afterward: what teams move to and what to check before you switch.

Key Takeaways

Containers isolate processes with namespaces and cgroups on a shared host kernel. An escape turns one compromised workload into a host problem.
The category teams move to is the microVM: a Firecracker microVM gives each sandbox its own guest kernel, and the kernel dies with the session.
Isolation alone is table stakes. The combination that holds is per-VM kernel isolation, egress enforced in the host kernel, private sandbox networks, and self-hosting when the data demands it.
Outbound access is open until you set at least one egress rule. Once set, everything else is denied, and enforcement sits outside the guest.
CreateOS Sandbox ships that combination, with per-second billing, $0 egress, and 500 free credits to test the migration.

Why MicroVMs, Not More Container Hardening

The first instinct after an escape is to harden the container. Fewer capabilities, more read-only mounts, stricter seccomp profiles, user namespaces. Each layer narrows what a compromised workload can call. None of it changes the fact that the kernel is shared. A kernel bug that crosses the namespace boundary lands on the host, and the host is running everyone else's workloads too.

A Firecracker microVM changes the boundary instead. Every sandbox boots its own guest kernel. CreateOS Sandbox is a Firecracker microVM with its own guest kernel, not a container with a wrapper. An attacker who breaks out of the guest lands in a machine that exists for one session, on a kernel nothing else uses, destroyed when the session ends.

Isolation alone is table stakes; every serious vendor now claims a VM option. What holds after an escape is the combination: per-VM kernel isolation, egress governance enforced on the host, sandbox-to-sandbox networking that contains lateral movement, and full self-host when the review board says nothing leaves your boundary. A VM whose guest can still reach the whole network moves the compromise. It does not contain it.

What Holds the Line the Second Time

A kernel per session. Every sandbox is a Firecracker microVM with its own guest kernel. There is no shared host kernel to escape into, and the kernel is destroyed with the session. VM-isolated, not container-isolated.

Egress enforced on the host, not in the guest. Once you set at least one rule, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the VM. A full guest compromise does not rewrite the rules or route around them. Rules take hosts, host:port pairs, wildcard subdomains, IPs, and CIDRs, plus domain rules through a transparent proxy. Set them in the egress field at create time, with PUT /v1/sandboxes/{id}/egress, through the SDK's setEgress, or with createos sandbox firewall set in the docs. One default to know before you migrate: outbound access is open until the first rule exists. Inbound is closed either way.

Networks that contain lateral movement. Sandboxes join private overlay networks with per-network private DNS, so agents find each other by name with no public exposure. Traffic between networks is denied by default. One compromised session stays inside its network instead of gaining a route to your fleet.

Evidence you can keep. Pause and fork are snapshots of full guest state, memory plus disk. After an incident, pause the session and fork it: the copy answers the forensics questions while the original sits untouched.

Your boundary when it has to be. Bring your own compute runs the same API on machines you control. Bring your own bucket works with your S3, R2, or MinIO. Sessions that touch sensitive data never have to leave your perimeter.

What's Proven and What's Young

The numbers behind CreateOS Sandbox: 2.6 million sandboxes created since June 2026. CreateOS's own CI has run on sandboxes since July 2026. Uptime has held above 99%. The infrastructure underneath is operated by NodeOps, the infrastructure company behind CreateOS, operating production infrastructure since December 2023.

The young-product frame, stated plainly: compliance certifications are on the roadmap, not shipped, for the Sandbox surface. What is proven today is the isolation and egress mechanics above. Pricing is built for the migration test: per-second billing, $0 egress, and 500 free credits for new accounts. Pause stops the meter while your team reviews a session.

What to Check Before You Switch

Put these questions to any vendor on the migration shortlist, ours included:

Where does the kernel boundary sit? A per-VM guest kernel, or a shared host kernel with hardening on top. After an escape, this is the question.
Where is egress enforced? Inside the guest, where a compromise can strip it, or in the host kernel, where it survives one.
What is open before you configure anything? Ask it precisely. Isolation on by default is standard. Egress restriction is not.
Can sessions run on your machines? If the incident review ended with a data-boundary requirement, self-host and bring-your-own storage are the deciding features.
What do restore and cold start cost? Same-host resume completes in under 0.7 seconds. A cross-host cold start runs 11 to 13 seconds. Know which one your workload hits.
What is proven versus roadmap? Maturity and certification status, stated plainly, with the vendor's own usage as the proof.

The tradeoff is real: a microVM carries a heavier boundary than a container process, and a cold start on a fresh host is slower than a container spawn. Snapshot restore closes most of that gap. What you buy is a boundary that survives the thing that burned you.

Frequently Asked Questions

Is a Firecracker microVM just a container with extra steps?

No. A container shares the host kernel and isolates processes with namespaces and cgroups. A Firecracker microVM boots its own guest kernel per sandbox. The escape target changes from the kernel every workload shares to a per-session kernel that is destroyed with the session.

Is outbound traffic locked down by default?

No, and any vendor who implies otherwise is skipping a step. Isolation is on by default; egress restriction is not. A sandbox with no egress rules has open outbound access, while inbound is closed by default regardless. Once you set at least one rule, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest.

How fast is a microVM compared to a container?

Creation from a snapshot restore takes 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 completes in under 0.7 seconds, and a cross-host cold start runs 11 to 13 seconds. Containers still win the bare process-spawn race. MicroVMs win the boundary.

Can the sessions stay inside our own infrastructure?

Yes. Bring your own compute runs the same API on machines you control, and bring your own bucket works with your S3, R2, or MinIO. Full self-hosting of the control plane and storage is available when code and data cannot leave your boundary.

Conclusion

The escape taught you the cost of a shared kernel. The migration is one decision: stop isolating untrusted code with namespaces on a kernel everyone shares, and give each session its own machine. CreateOS Sandbox runs that boundary with egress governance on the host, pause, resume, and fork, and per-second billing at $0 egress. Start free with 500 credits and put the next untrusted build in a microVM before the next escape lands.

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.