Running AI-Generated Code in Production: The Safety Stack, Explained

Teams running AI-generated code in production rely on a sandbox execution layer: an isolated microVM per session, an egress allowlist enforced on the host, private networking between sandboxes, and the option to self-host the whole thing. CreateOS Sandbox is that layer, built on Firecracker, so code your agents write never runs next to your production systems or your users' data.

Introduction

Coding agents now write a meaningful share of the code that ships. That code is untrusted by definition: no engineer reviewed every line, and it runs with real network access and real data. That answer no longer holds. A container shares the host kernel. A prompt-injected agent, or a dependency the model pulled in, can escape a shared kernel in ways security teams have documented for years. The fix is not more review. It is a different runtime: one machine per session, with the network path governed from outside that machine.

This post explains the stack teams actually use and where the tradeoffs sit.

Key Takeaways

AI-generated code is untrusted code. It needs its own machine, not a shared container.
Isolation alone is table stakes. Egress control, private networking, and self-hosting are what make it production-grade.
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.
Pause, resume, and fork turn one sandbox into many parallel rollouts without paying for idle compute.
Bring-your-own storage and compute keep code and data inside your own boundary.
2.6 million sandboxes created since June 2026 (as of 1 October 2026), with per-second billing and $0 egress.

Why a Container Is Not Enough

Most teams start by running agent code in a container. It feels isolated. It is not.

A container is a process namespace on a shared kernel. Code inside the container talks to the same kernel your other workloads use. A kernel exploit or a mounted socket turns "isolated" into "adjacent." For code a model wrote five seconds ago, that risk is not acceptable.

A Firecracker microVM takes a different path. Each sandbox is a full virtual machine with its own guest kernel, booted in seconds from a snapshot. CreateOS Sandbox is built this way: every session gets its own microVM, its own kernel, and its own filesystem. Nothing is shared with the next session or with your infrastructure.

The tradeoff is real: a microVM uses more memory than a container. Snapshot restore closes most of the gap. On an idle host, sandbox creation takes tens of milliseconds, about 30 ms, though that is an idle-host figure, not an SLA.

Governing What the Code Can Reach

Isolation answers "what can the code touch on its own machine?" Egress answers "where can it phone home?" The second question matters more in practice, because a compromised session is only as dangerous as its network path.

Here is the part teams get wrong. Outbound access in a sandbox 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. Code inside the VM cannot rewrite the rules or route around them, because the rules are not inside the VM.

You set the allowlist through the egress field at sandbox create time, a live update via PUT /v1/sandboxes/{id}/egress with no restart, the SDK's setEgress method, or the CLI's createos sandbox firewall set command. Rules take hosts, host:port pairs, wildcard subdomains, IPs, and CIDRs. Inbound is closed by default regardless of what you configure.

The practical pattern: allow the package registry, the model API, and your own endpoints. Nothing else. An agent that gets prompt-injected mid-session can only talk to the three places you named.

Networking Between Agents, Privately

Multi-agent systems need agents to find each other. The default answer, public network calls between sessions, exposes every hop. The better answer is a private overlay network.

CreateOS Sandbox lets you attach sandboxes to private overlay networks with per-network private DNS. Agents on the same network reach each other by name. Traffic between networks is denied by default. No public exposure, no service discovery hacks, no firewall rules you have to remember to apply. Isolation is the default, not a setting.

This is also where fork earns its place. Pausing a sandbox writes a snapshot of full guest state, memory and disk, and stops compute billing. Resume restores that exact machine, same-host in under 0.7 seconds. Fork branches a paused sandbox's state, so you can run N candidate fixes in parallel and keep the winner. For CI pipelines generating candidate patches, that is the difference between one attempt per run and a real search.

Keeping Code and Data Inside Your Boundary

Some code cannot leave your infrastructure at all. Regulated data, customer commitments, residency rules: the constraint is the boundary, not the trust level.

CreateOS Sandbox handles this two ways. Bring your own storage: snapshots land in your own S3, R2, or MinIO bucket, not ours. Bring your own compute: the same API runs on your machines, so the workload never touches our cloud. You can self-host the control plane and storage entirely.

Shapes scale from a quarter CPU up to 8 CPUs and 16 GB, with 10 to 60 GB of disk, so you match the machine to the job instead of paying for a fixed size. Billing is per second, egress is $0, and pausing stops the meter. New accounts start with 500 free credits, and the Sandbox product page carries current limits and pricing.

Where Teams Run It: CI, Agents, and Customer Code

Three workloads show up again and again.

CI builds with untrusted code. An official Jenkins plugin gives each build 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. Declarative Pipeline is supported. The egress allowlist is set on the sandbox itself through the CreateOS API or CLI, not inside Jenkins.

Long-running agents. An agent that waits on a human approval does not need to burn compute while it waits. Pause it, resume exactly where it stopped, and pay only for the seconds it ran.

Code your customers wrote. If your product executes user-submitted or model-written code, one customer's session must never see another's machine. Per-session microVMs with no shared kernel make that a structural property, not a policy.

The docs cover the SDK, CLI, and MCP entry points, and the SDK installs with npm install @nodeops-createos/sandbox.

Frequently Asked Questions

Is a microVM sandbox slower than a container? Cold, slightly. Warm, no. Sandboxes restore from snapshot rather than booting from scratch, and creation on an idle host takes tens of milliseconds, about 30 ms, though that is an idle-host figure, not an SLA. Same-host resume after a pause is under 0.7 seconds. You trade a small cold-start cost for a machine boundary instead of a process boundary.

Do I need to lock down network access manually? You need to set at least one egress rule, and then the default flips to deny-everything-else. Outbound is open until that first rule exists. Inbound is closed by default either way. Rules are enforced in the host kernel with eBPF, outside the guest, so code inside cannot change them.

Can this run inside our own cloud? Yes. The same API runs on customer machines, snapshots can land in your own S3, R2, or MinIO bucket, and you can self-host the control plane and storage. Code and data stay inside your boundary.

What does it cost to run this at scale? Per-second billing, $0 egress, and pausing stops the meter. You scale on concurrency, not unit price. New accounts start with 500 free credits, and current shapes and pricing are on the Sandbox pricing page.

Conclusion

The teams shipping AI-generated code safely are not reviewing harder. They changed the runtime. A Firecracker microVM per session, an egress allowlist enforced outside the guest, private networks between agents, and bring-your-own compute when the boundary has to be yours. That combination is what CreateOS Sandbox ships, and 2.6 million sandboxes created since June 2026 (as of 1 October 2026) say it is not theoretical.

If your agents write code that runs in production, start with the CreateOS Sandbox product page and spin up your first sandbox with the free credits.

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.