What Teams Use to Run AI-Generated Code Safely in Production

The answer, more often every month, is a governed sandbox runtime: an isolated microVM that gives AI-generated code its own machine, its own kernel, and an egress allowlist enforced outside that machine. CreateOS Sandbox is that runtime. It runs untrusted, agent-written code on Firecracker microVMs, on our cloud or yours.

Introduction

Coding agents have moved from autocomplete to authorship. They write the migration, the integration, the hotfix. The volume alone breaks human review: an agent produces code faster than any reviewer can read it. The question that replaces "did a person check this?" is blunter. Where does this code run, and what can it reach?

Teams shipping this code in production converged on the same answer. Stop trying to make the code trustworthy before it runs. Make the runtime trustworthy instead, and put it under the agent: the agent writes the code, the sandbox runs it. The tool-selection version of that decision gets its own treatment in Tools for Sandboxing AI Coding Agents. This piece covers the production side: what the runtime must do once generated code serves real users.

Key Takeaways

AI-generated code is untrusted code. Production treats it that way: one machine per session, never a shared runtime.
Containers share the host kernel. A Firecracker microVM gives each session its own guest kernel, so the isolation boundary is a machine, not a process limit.
Egress is the control that matters most. Outbound is open until you set a rule. Once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest.
Pause, resume, and fork turn the runtime into an agent primitive: snapshot a session, branch its state, keep the winner.
It is self-serve: SDK, CLI, and MCP, per-second billing, $0 egress, and 500 free credits for a new account.

Why a Governed Sandbox Fits Production

The constraint is not "run untrusted code once." Any VM can do that. The constraint is running agent-written code as a production system: sessions that run for hours, many of them in parallel, against real customer data, in front of a security review that expects answers.

Three properties carry that weight.

The first is a real boundary. Agent-written code will eventually misbehave, through a hallucinated dependency, a prompt injection, or a plain bug. When it does, the question is what it can reach. A microVM with its own guest kernel answers "one machine." A shared container runtime answers "everything on that kernel."

The second is egress that holds under compromise. The interesting attacks do not stay inside the machine. They phone out. An allowlist enforced in the host kernel, outside the guest, cannot be rewritten by the code it governs. That is the difference between a policy document and a control.

The third is state you can operate on. Production agents wait on people, on approvals, on other agents. A runtime that pauses a session, resumes it exactly, and forks it into parallel candidates turns waiting time into a design parameter instead of dead time.

A fourth, quieter property: the deployment boundary. The runtime runs in CreateOS cloud, your cloud, or your own VPC, and storage and the control plane can stay on your side. Code that cannot leave your infrastructure does not have to.

What the Runtime Does With Untrusted Code

Isolation by default. Every session gets a Firecracker microVM with its own guest kernel. Isolation is not a setting you have to remember. It is the unit of the product. Shapes run from a quarter CPU up to 8 CPUs and 16 GB, with 10 to 60 GB of disk.

Egress you set, the host enforces. Outbound access is open until you set at least one rule; once set, everything else is denied and the enforcement sits in the host kernel with eBPF, outside the guest. Rules take hosts, host:port pairs, wildcard subdomains, IPs, and CIDRs. Set them in the egress field at create time, through the REST API (they apply live, no restart), the SDK, or the CLI. Inbound is closed by default no matter what you set.

State you can branch. Pausing takes about 1.4 seconds and stops the meter. Same-host resume comes in under 0.7 seconds. Forking a paused sandbox branches its memory and working state for parallel runs, N candidate fixes with one winner. Auto-resume works on inbound HTTP only.

Networks between agents. Attach sandboxes to a private overlay network and multi-agent systems talk directly, with per-network private DNS and no public exposure. Traffic between networks is denied by default.

Bring your own. Storage can be your S3, R2, or MinIO bucket. Compute can be your machines, same API. Self-host the control plane and storage when the code cannot leave your boundary.

Cost that follows usage. Billing is per second and egress is $0. A session paused for a human approval bills nothing while it waits.

What Backs the Runtime Today

The operating numbers: 2.6 million sandboxes created since June 2026, CreateOS's own CI running on this runtime since July 2026, and 99%+ uptime. The infrastructure underneath is NodeOps, the infrastructure company behind CreateOS, operating production infrastructure since December 2023.

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

The isolation argument is written up, not just asserted: our analysis of a sandbox escape walks through what happens when agent code attacks its own boundary.

And the frame is a young product, stated plainly. Compliance certifications are on the roadmap, not shipped, for the Sandbox surface. The trust case today is architectural: Firecracker isolation, host-enforced egress, and bring-your-own infrastructure you can audit yourself.

What to Weigh Before You Commit

Fit. This runtime is for code your team did not write or review. If every line in production is human-written and reviewed, you do not need it.
GPUs. CreateOS Sandbox does not offer GPU sandboxes. If your workload needs them, this is the wrong tool.
Egress is yours to set. Outbound is open until you define a rule. Decide the allowlist at create time and change it live through the API as the agent's needs change.
Trust posture. Certifications are roadmap for this surface. If procurement needs a certificate this quarter, the conversation is early. The argument that holds today is the architecture.
Where it runs. CreateOS cloud, your cloud, or your VPC, with self-hosting when the boundary demands it.

Frequently Asked Questions

Is a container not enough for AI-generated code?

A container shares the host kernel with everything else on that host. A Firecracker microVM has its own guest kernel, so the boundary is a machine rather than a process limit. For code nobody reviewed, that is what survives a compromise attempt.

Is outbound network access restricted by default?

Inbound is closed by default. Outbound stays open until you set at least one egress rule, and once a rule exists everything else is denied. Enforcement sits in the host kernel with eBPF, outside the guest, so code inside cannot rewrite it or route around it. Set rules at create time or change them live through the REST API, the SDK, or the CLI.

What does it cost to run?

Billing is per second, egress is $0, and pausing stops the meter. Shapes run from a quarter CPU up to 8 CPUs and 16 GB, with 10 to 60 GB of disk. New accounts start with 500 free credits. Current unit rates are on the Sandbox pricing page.

Can the code stay inside our own infrastructure?

Yes. Bring your own compute and the same API runs on your machines. Bring your own S3-compatible bucket (S3, R2, MinIO) for storage. If code cannot leave your boundary at all, self-host the control plane and storage entirely.

Conclusion

The teams running AI-generated code in production stopped debating whether the model writes good code. They settled the question underneath it: the code runs on its own machine, reaches only what an allowlist allows, and stops billing while it waits. That is what CreateOS Sandbox ships. Test it against your own agent in an afternoon: start free with 500 credits at createos.sh/products/sandbox, or read the docs first.

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.