Choosing a Runtime for AI-Generated Code: A Practical Decision Guide

Your coding agent writes code in seconds. The hard part is deciding what machine that code runs on when it reaches production, because a wrong pick shows up later as a security incident, a surprise egress bill, or an agent that cannot resume after a pause. This guide lays out the decision criteria, then maps common scenarios to a concrete choice.

Introduction

Teams shipping AI products face a question that did not exist five years ago: what executes the code your model wrote? You did not review it line by line. You may not fully trust the tool that generated it. Yet it has to run somewhere, touch real APIs, and do real work.

The default answers most teams reach for are containers on shared infrastructure, serverless functions, or "just run it on the CI box." Each works until the first prompt injection, dependency confusion, or runaway loop. Then the question changes from "where does it run" to "what did it touch, what could it reach, and how do we prove it."

This piece is a decision guide, not a feature tour. It gives you the criteria that matter, then walks through scenarios: if your situation looks like X, choose Y. The examples lean on CreateOS Sandbox, because it is the runtime we operate and the one we can describe in verified detail, but the criteria apply to any option you evaluate.

Key Takeaways

Isolation level is the first decision. A shared-kernel container is not the same as a microVM with its own guest kernel, and the difference matters most for code you did not write.
Egress control is the second. Isolation without outbound governance still lets compromised code phone home. Check how the allowlist is enforced and where.
Lifecycle features decide operating cost. Pause, resume, and fork turn long-running agents and parallel rollouts from expensive into routine.
Where the code runs is the third axis. Some workloads cannot leave your cloud or data centre, so self-hosting and bring-your-own options are requirements, not nice-to-haves.
Price the whole session, not the CPU second. Egress fees, idle compute, and cold starts are where sandboxes usually lose money.

Decision criteria

Evaluate any runtime for AI-generated code against five criteria.

1. Isolation boundary. Code you cannot trust needs a boundary it cannot rewrite. Containers share the host kernel; a determined guest can attack the kernel itself. A Firecracker microVM gives each session its own guest kernel, so the isolation boundary is the machine, not a namespace. Ask every vendor this question first: if the guest is fully compromised, what does it reach?

2. Egress governance. Isolation answers what gets in. Egress answers what gets out. A sandbox with no egress rules set has open outbound access; restriction only begins once you set at least one rule. When you do, enforcement location matters: an allowlist enforced inside the guest can be disabled by the guest. CreateOS enforces its per-sandbox allowlist in the host kernel with eBPF, outside the VM, so a compromised guest cannot route around it. Rules take hosts, ports, wildcard subdomains, IPs and CIDRs, and apply live without a restart. Details are in the Sandbox docs.

3. Lifecycle: pause, resume, fork. Agents that wait on a human, an approval, or a slow API burn money while idle. Pause writes a snapshot of full guest state and stops compute billing; resume restores the exact machine. Fork branches a paused sandbox's memory and working state, which is how you run N candidate fixes in parallel and keep the winner. If your agents run for hours, this criterion outweighs raw creation speed.

4. Where it runs. Regulated data, customer contracts, and sovereignty requirements decide this for you. Look for three deployment modes: vendor cloud, your VPC, and full self-host of control plane and storage. Bring-your-own storage (S3, R2, MinIO) keeps session artifacts in your boundary.

5. Total session cost. Per-second billing with $0 egress and pause-stops-the-meter is a different cost curve from per-invocation serverless or always-on containers. Price a realistic session: creation, active compute, idle time, egress, and the cold starts between them.

How to choose

Match your scenario to the guidance below.

If your product lets users' agents run arbitrary code, choose a microVM-per-session runtime with host-enforced egress. One customer's code must never see another's machine, and a compromised session must not reach your internal network. This is the core case for CreateOS Sandbox: a Firecracker microVM per session, egress allowlist enforced on the host, inbound closed by default.

If your agents run for hours and wait on people, prioritise pause and resume. An agent that pauses while waiting for approval and resumes exactly where it stopped costs a fraction of one that holds a machine open. Auto-pause on idle handles the sessions nobody remembers to stop.

If you evaluate multiple model outputs or candidate fixes, prioritise fork. Branch a paused sandbox into N parallel rollouts, score the results, keep one. Doing this with fresh environments means re-provisioning and losing working state; forking keeps it.

If your agents need to talk to each other, check networking between sandboxes. Most sandboxes are built for single isolated snippets. Private overlay networks with per-network DNS let a team of agents find each other by name with no public exposure, and traffic between networks is denied by default.

If compliance or data residency blocks vendor cloud, require bring-your-own compute and self-host. The same API should run on your machines, with storage you control. Where formal compliance comes up: we are SOC 2 Type II and ISO 27001 certified, with reports available under NDA.

If the code runs in your CI pipeline, look for a CI integration rather than a generic SDK. The CreateOS Sandbox plugin for Jenkins gives each build a fresh microVM agent that is destroyed when the build finishes, with declarative pipeline support. Note that the egress allowlist for those build sandboxes is set through the CreateOS API or CLI, not inside Jenkins.

If you only ever run code your own team wrote and reviewed, you may not need a sandbox at all. Ordinary containers and your existing pipeline are fine. The decision hinges on trust in the code's origin, not on the code itself.

Frequently Asked Questions

Why not just run AI-generated code in a container? Containers share the host kernel with their neighbours. For code you wrote and reviewed, that risk is acceptable. For code a model generated from a prompt that may include untrusted input, the isolation boundary should be the machine. A Firecracker microVM has its own guest kernel per session, so a full guest compromise stops at the VM edge.

Is outbound network access locked down by default? No, and beware any vendor implying otherwise. In CreateOS Sandbox, inbound is closed by default, but 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, so code inside cannot rewrite or route around it.

What does this cost compared with serverless? CreateOS Sandbox bills per second with $0 egress, and pausing a sandbox stops compute billing. Serverless looks cheap per invocation but charges for every cold start and every byte out. For long-running agents, the pause-and-resume model usually wins; for short stateless bursts, either works. Current shapes and rates are on the Sandbox pricing page.

How do we start? New accounts get 500 free credits, and the SDK installs with npm install @nodeops-createos/sandbox. The product page links the quickstart, CLI, and MCP server. Most teams run their first untrusted script within minutes.

Conclusion

The question "what runs AI-generated code safely" has a short answer and a long one. The short answer: a runtime built for code you cannot trust, with machine-level isolation, egress you control, and a lifecycle that does not bill you for waiting. The long answer is the five criteria above, applied to your own threat model and deployment constraints.

If those criteria match your problem, CreateOS Sandbox was built for exactly this: Firecracker microVMs for untrusted or agent-written code, with pause and fork, host-enforced egress allowlists, and bring-your-own when sessions need to stay on your infrastructure. Start free with 500 credits and run your first untrusted script today.

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.