Running untrusted, AI-generated code: why we built CreateOS Sandbox on Firecracker

The agent doesn't just write the code anymore. It runs it.

That one change broke an assumption a lot of infrastructure was built on. For years, code that ran in production was code a human wrote and another human reviewed. Now an agent generates a script, executes it, reads the result, and generates the next one. Code execution at this scale is already counted in the billions by the platforms leading the category. Most of it lands on shared-kernel containers, on a managed cloud, with no boundary between one workload and the next.

That is the gap CreateOS Sandbox fills. It runs untrusted, AI-generated code in isolated micro-VMs, with real networking, kernel-level egress control, and your own storage. This post is the technical walk-through.

Why a container isn't enough

A container shares the host kernel. Namespaces and cgroups isolate the process, but the kernel underneath is the same one every other container on that host is using. A kernel bug or a container escape is a host compromise.

For code you wrote and reviewed, that risk is usually acceptable. For code an agent generated from a prompt you didn't fully read, it isn't. You want a hard boundary, not a process-level one.

So every sandbox runs as a Firecracker micro-VM with its own guest kernel. The blast radius of a bad run stops at the VM boundary. This is the same primitive that backs serverless at large clouds, pointed at a different problem: running code you don't trust.

The four pillars

1. Security: own kernel, controlled egress

Each sandbox is a Firecracker micro-VM with a dedicated kernel. On top of that, egress is enforced at the kernel with an eBPF firewall. By default the code talks to nothing. You allowlist destinations explicitly:

createos sandbox firewall allow sb-<id> --egress api.example.com:443

Nothing comes in unless you expose it. So an agent that tries to exfiltrate data or call a destination you didn't approve hits a wall, not a log line after the fact.

2. Networking: private overlay + private DNS

Most sandbox products give you one isolated box and stop there. CreateOS Sandbox puts sandboxes on a private overlay network with private DNS, so they can reach each other directly. That means you can stand up a multi-node setup, a k3s or Nomad cluster, a worker pool talking to a coordinator, without exposing anything to the public internet.

Isolation from the outside, connectivity on the inside. That combination is the part that's hard to get elsewhere.

3. Speed: boot in seconds, pause to stop paying

Sandboxes boot in seconds, not minutes. You pause one when it's idle so you stop paying, and resume in low single-digit seconds. You can fork a running sandbox when you need a copy of its exact state. For agent loops that spin sandboxes up and down constantly, the boot and pause economics matter as much as the isolation.

4. Storage: bring your own volumes

Attach your own S3, R2, or Tigris volumes. Data persists in your bucket, under your account, not locked inside ours. Sync in, run, sync out.

How it fits together

Two planes. A control plane (API server, scheduler, gateway, Postgres) takes requests from the API, the SDK, the createos sandbox CLI, or drop-in agent skills. A data plane of hosts runs the Firecracker micro-VMs, wired together by the private overlay network, fenced by the eBPF egress firewall, backed by your storage volumes. The whole thing can run inside a self-host boundary.

(Architecture diagram from CRE-163 goes here.)

Quickstart

The developer surface is an HTTP API under /v1/, an SDK at github.com/NodeOps-app/fc-sdk, the createos sandbox CLI, and agent skills. The CLI path, end to end:

# create a sandbox from a template at a chosen shape
createos sandbox create --template base --shape s-1vcpu-1gb --region eu

# run code inside it
createos sandbox exec sb-<id> -- python3 -c "print('hello from an isolated micro-VM')"

# allowlist one egress destination, everything else stays blocked
createos sandbox firewall allow sb-<id> --egress api.example.com:443

# pause to stop paying for idle, resume in seconds
createos sandbox pause

Pricing

Pay per compute. The model is straightforward: compute-based rates, $0 egress, and an undercut of 20–40% in comparison to our competitors.

If your data can't sit on a managed cloud at all, you self-host the whole stack and the residency question answers itself.

Try it

If you are running agent workloads, CI for untrusted PRs, code interpreters, or anything that executes code you didn't write, we are taking design partners.

Start at https://createos.sh/app/sandbox?utm_source=dev.to&utm_medium=social&utm_campaign=launch

CLI: https://github.com/NodeOps-app/createos-cli

CLI Docs: https://nodeops.network/createos/docs/Sandbox/CLI/Overview

Docs: https://nodeops.network/createos/docs/Sandbox/Overview

SDK: https://github.com/NodeOps-app/createos-sandbox-sdk

42 SDK Examples: https://github.com/NodeOps-app/createos-sandbox-sdk/tree/main/examples

SDK docs: https://nodeops.network/createos/docs/Sandbox/SDK/Overview

Run sandbox in your infra: https://nodeops.network/createos/docs/Sandbox/Self-Hosting