Governed micro-VMs for untrusted code: isolation, egress control, and fork

Shubham Sharma | CreateOS — Tue, 07 Jul 2026 13:30:00 +0000

AI agents are writing and running more code than anyone planned for. Most of it falls into the same category: code the system did not write, has not reviewed, and cannot fully trust.

Most sandbox stacks were built for a different job. They run snippets, not systems. And they run them with weaker defaults than most teams realize until something goes wrong.

Three things actually matter once you are running code you do not trust. How contained a failure is. How much the workload can talk to on its way out. How cheaply you can branch and discard experiments instead of rebuilding environments from scratch.

Isolation: a real kernel, not a shared one

Most sandbox providers run workloads as containers. Fast, cheap, and fine for a lot of things. But every container on a host shares that host's kernel. A container escape does not just compromise the one workload. It is a path to everything else running there.

CreateOS Sandbox runs every workload as a Firecracker micro-VM with its own guest kernel. If a sandbox gets exploited, the blast radius is that micro-VM. No shared-kernel escape path to the host or to any other sandbox. This is the default, not a config option you remember to turn on.

Egress control: allowlist, enforced at the kernel

Isolation answers whether code can break out. It does not answer what it can talk to while running. For agent workloads, that is the harder question.

An agent usually needs to call a handful of external APIs. It should never have a path to your internal database or anything else on your network. Most providers give two settings: full internet access or none. Neither fits.

Sandbox enforces egress at the kernel via eBPF:

Allowlist-only by host, IP, or CIDR. The first rule locks down everything else by default.
No ingress by default. One-way outbound unless you explicitly open a tunnel or ingress URL.
Bandwidth quotas per sandbox with recharge and an unmetered override when needed.
Enforcing this in the data plane at the same layer that would catch a kernel-level attempt to route around it is a different guarantee than a proxy inspecting traffic after the fact.

Fork: treating lifecycle as a primitive

Agent workloads are usually not long-lived servers. You run an experiment to a decision point, branch it into a few variations, evaluate, and throw most of the results away. If lifecycle management is bolted on, every branch means rebuilding from scratch.

Sandbox treats pause, resume, fork, and kill as first-class primitives. Fork a running sandbox server-side to branch its exact state across N parallel rollouts. Keep the winner. Discard the rest. Pause releases compute while preserving RAM, disk, and process state. Resume brings it back warm or cold. Billing per second, so a paused sandbox costs nothing while it waits.

Where this stands today

Sandbox is alpha. No GPU passthrough yet. No live vertical resize once a sandbox is running. Formal compliance certifications are roadmap, not shipped. These are the actual current edges.

Quickstart here: createos.sh/app/sandbox

Curious how others are handling the isolation, egress, and lifecycle problem for agent-generated code. What has actually held up in production for you?

DEV Community: Shubham Sharma | CreateOS

Governed micro-VMs for untrusted code: isolation, egress control, and fork