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
Top comments (3)
This is a great breakdown of the security trade-offs when dealing with AI agents. I’m curious—how do you handle the overhead of spinning up a micro-VM for very short-lived tasks? Do you have a pre-warmed pool of sandboxes to keep the execution latency low?
The shared-kernel point deserves more airtime than it gets - most people treat 'it's in a container' as the end of the security conversation, when agents executing their own generated code is exactly the workload that finds kernel bugs. Two questions: what does cold-start look like in practice once you add rootfs + network setup on top of Firecracker's boot time (do you keep a warm pool?), and how granular is the egress control - domain allowlists, or CIDR-level only? I work on the output-validation layer of the same problem (schema-checking LLM output before it touches anything), and execution isolation always felt like the layer everyone skips.
This is exactly the kind of infrastructure thinking more AI tool builders need to do. The distinction between container isolation and micro-VM isolation is critical when you are dealing with agent-generated code that nobody reviews before execution. We have been exploring similar security concerns when building AI-powered tools - the moment you let an agent write and run code in a shared environment, the threat model changes completely. The eBPF firewall approach for egress control is particularly clever. Default-deny with explicit allowlists is how you sleep at night. Curious about the cold-start latency for Firecracker micro-VMs compared to containers - is the security tradeoff worth the added boot time for interactive use cases?