Isolated Execution for Agent-Generated Code: Options for Regulated Companies That Cannot Use a Shared Cloud

You have three options: containers inside your existing cluster, a self-built microVM fleet, or a sandbox platform that runs the same API on your own machines. For code nobody on your team has reviewed, the third is the one that holds: a microVM per run, on your hardware, with egress enforced outside the guest.

Introduction

Agent-generated code is code nobody on your team wrote or reviewed. Running it on a shared, multi-tenant cloud runtime puts work your regulators audit on hardware you do not control, a few milliseconds from someone else's workload. Most regulated teams already know this. The open questions are which boundary the code actually gets, who enforces what leaves, and where the state lands.

This post walks the three options, names what each one costs, and recommends the one that fits a regulated boundary.

Key Takeaways

Containers share the host kernel. For untrusted, agent-written code, that is a convenience boundary, not a security one.
A microVM per run gives each session its own guest kernel. Firecracker is the proven way to get one.
Building your own fleet means owning orchestration, snapshotting, egress enforcement, and the API your agents call. That is a platform team, not a sprint.
A sandbox platform with bring-your-own compute runs the same API on your machines, so code and snapshots stay inside your boundary.
Outbound access is open until you set at least one egress rule. Plan the allowlist at create time, wherever the code runs.

Why a Sandbox Platform on Your Own Hardware Fits the Regulated Case

A security review asks three things of any runtime that touches untrusted code: what boundary does the code get, where does it run, and what stops it from calling out. Score the options against those questions.

Containers in your existing cluster are familiar and already paid for. They are also the wrong boundary. Every container shares the host kernel with your other workloads, so agent-written code sits one kernel bug away from the estate you are obliged to protect.

Building your own microVM fleet gets the boundary right and the budget wrong. Firecracker gives you a per-VM kernel. It does not give you snapshot and restore, egress enforcement that survives a compromised guest, session networking, or the API your agents call. That is months of platform work before the first agent ships, and it is work you will maintain for as long as the agents run.

A sandbox platform on your machines is the option that fits. CreateOS Sandbox runs the same API on customer machines, and you can self-host the control plane and storage entirely when code cannot leave your boundary. Isolation is per-sandbox by default, not a setting someone has to remember. Egress is enforced in the host kernel with eBPF, outside the guest, so code inside cannot rewrite it or route around it. Snapshots can land in your own S3, R2, or MinIO bucket.

You get the microVM boundary of the build-it-yourself route without building the fleet, and you keep the perimeter of the cluster route without the shared kernel.

What Isolated Execution on Your Own Infrastructure Requires

Five capabilities carry the answer. Anything less and the boundary leaks.

A kernel boundary per run. Every CreateOS Sandbox is a Firecracker microVM with its own guest kernel. Not a container, not a shared-kernel process namespace. Isolation at the machine boundary.

Bring your own compute. The same sandbox API runs on your machines. Self-host the control plane and storage entirely for code that cannot leave your boundary.

Egress enforced on the host. The allowlist is enforced in the host kernel with eBPF, outside the VM. Rules take host, host:port, wildcard subdomains, IPs, and CIDRs. Set the egress field at create time, apply changes live with PUT /v1/sandboxes/{id}/egress, call setEgress in the SDK, or run createos sandbox firewall set from the CLI.

Storage you control. Bring your own S3-compatible bucket: customer S3, R2, or MinIO. State that must stay in your boundary lands in storage you already govern.

Private session networking. Sandboxes attach to a private overlay network with per-network private DNS, and traffic between networks is denied by default. Multi-agent systems talk directly with no public exposure.

What Is Proven Today, and What Is Not

The claims above trace to shipped product. 2.6 million sandboxes have been created since June 2026. CreateOS's own CI has run on sandboxes since July 2026, and its GitHub Actions runner and coding-agent plugin are usable proofs. Uptime runs 99%+. NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.

Speed, with the qualifiers attached: restore from snapshot takes tens of milliseconds, about 30 ms on an idle host, and that is an idle-host figure, not an SLA. Pause takes about 1.4 seconds. Same-host resume lands under 0.7 seconds. A cross-host cold start runs 11 to 13 seconds.

The tradeoff, stated plainly: compliance certifications for the Sandbox surface are on the roadmap, not shipped. If your review requires a certified vendor today, that is a real gate. The trust layer here is the isolation architecture, host-enforced egress, and bring-your-own deployment, not a certificate.

What to Weigh Before You Commit

The egress default. Outbound access 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. Inbound is closed by default regardless of egress rule state. If your policy assumes deny-by-default, set the allowlist at create time, not after the first run.

Your team still operates the hosts. Bring-your-own compute puts the machines in your boundary and the operations in your hands. That is the point of the model, and it is real work.

GPU workloads. CreateOS Sandbox does not offer GPU sandboxes today. If your agents need them, know that before procurement, not after.

Cost that follows usage. Per-second billing, $0 egress, and pause stops the meter. Check the published rates before you model a fleet.

Questions for any vendor, including us. Where does the code run, what kernel does it get, who enforces egress and from where, where do snapshots land, and what can your team remove. The full tool-selection checklist is in our guide to sandboxing tools for AI coding agents.

Frequently Asked Questions

Can agent-generated code run entirely inside our own cloud?

Yes. Bring your own compute runs the same sandbox API on your machines, and you can self-host the control plane and storage entirely. Bring your own bucket keeps snapshots in S3, R2, or MinIO you control. Code and state stay inside your boundary.

Is a container enough isolation for code an agent wrote?

A container shares the host kernel with everything else on the machine. A CreateOS Sandbox is a Firecracker microVM with its own guest kernel per sandbox, so the boundary is the machine, not a namespace.

Is outbound network access locked down by default?

No. Outbound access is open until you set at least one egress rule. Once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest. Inbound is closed by default regardless of egress rule state.

Does CreateOS Sandbox hold compliance certifications?

Not on the Sandbox surface today. Certifications are on the roadmap, not shipped. The trust layer is per-VM kernel isolation, host-enforced egress, and bring-your-own deployment on your infrastructure.

Conclusion

Three options, one that fits. Containers are the wrong boundary for code nobody reviewed. Building your own microVM fleet is the right boundary at the wrong cost. A sandbox platform that runs on your own machines gives you the microVM boundary, host-enforced egress, and storage you control, without the platform project.

If agent-generated code is heading for production in a regulated estate, stage the conversation with your security review in the room. Start with the CreateOS Sandbox product overview and the egress and self-host details in the docs. Bring your architecture and your security questions. We will map the boundary with you.

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.