How to safely run AI-generated code — a practical sandboxing checklist

Weston Carnes — Wed, 29 Jul 2026 03:31:14 +0000

Cross-post. Original: stellarbytecapital.com/blog/how-to-run-ai-generated-code-safely

If you're building an AI agent, sooner or later it will write code and you'll have to run that code. The moment you do, you're executing something no human reviewed against your infrastructure. This is a practical checklist for doing that safely — the controls we use in production, in the order they matter.

The short version: treat every piece of AI-generated code as hostile, and design so that even a full compromise of the runtime buys the attacker nothing.

First, the threat model

Before controls, be honest about what can go wrong when you run untrusted code:

It reads or exfiltrates data belonging to other users on the same host.
It reaches out to the network to leak data or pull a payload.
It leaves state behind — temp files, mutated env, background threads — that corrupts the next run.
It exhausts CPU, memory, or disk and takes down the shared service.
It escapes the sandbox entirely via a kernel or runtime bug.

"The model probably won't do that" is not a control. Design for the case where it does.

The core pattern: one disposable sandbox per execution

The single highest-leverage decision: run every execution in its own fresh sandbox, and destroy it after the run. Never reuse.

Reuse is where most bugs and attacks live — leaked file descriptors, leftover temp files, mutated globals, a background thread from the last run. If nothing is ever reused, that entire class of problems disappears. To keep it fast, keep a warm pool of ready sandboxes and backfill each one as it's consumed.

The checklist

Isolation boundary — use a real boundary, not a language-level "safe eval." A container is the baseline; a microVM (gVisor, Firecracker) is stronger against kernel escapes.
Network egress: default-deny — no outbound network by default. An escaped agent that can't reach the internet has nowhere to send data.
Filesystem: read-only + ephemeral — mount inputs read-only; give a scratch space that dies with the sandbox.
Resource limits — cap CPU, memory, PIDs, and wall-clock time per execution.
Per-user quotas — cap executions per user per window; stops abuse and runaway loops.
Least privilege — non-root, dropped capabilities, no Docker socket, no host devices.
Secrets stay out — never mount API keys into a sandbox running generated code; proxy authenticated calls through a trusted layer.
Audit everything — emit an event for every lifecycle step and every network call.

Common mistakes

Reusing a long-lived interpreter to save startup time — you trade milliseconds for a permanent state-leak surface.
Allowing full network egress "because the task might need it." Default-deny, then allowlist.
Trusting the model to stay in scope. Sandbox behavior, don't prompt for it.
Running as root inside the container because it was easier during development.

Container or microVM?

For most internal tools, a hardened one-shot container with default-deny egress is a reasonable baseline. If you're multi-tenant or running adversarial code, step up to gVisor or Firecracker — stronger isolation, still cheap with a warm pool.

The point is the combination: disposable sandboxes, no egress, read-only filesystem, capped resources, quotas, least privilege, no secrets, full auditing.

We're Xingyao Byte — building secure AI-execution layers, quant trading systems, and payment platforms. Remote, async-first → stellarbytecapital.com

gVisor vs Firecracker vs Docker for AI code sandboxes

Weston Carnes — Wed, 29 Jul 2026 03:27:56 +0000

This is a cross-post. Original on our site: stellarbytecapital.com/blog/gvisor-firecracker-docker-ai-sandbox

Once you've decided to run AI-generated code in a sandbox, the next question is which sandbox. The three names you'll keep hitting are Docker, gVisor, and Firecracker. They're not competing products so much as three different strengths of boundary — and picking the wrong one either leaves you exposed or costs you performance you didn't need to spend.

Here's how they actually differ, and how to choose.

The one thing that separates them: where the boundary is

All three isolate code, but at different layers — and that layer determines how hard the boundary is to break:

Docker (runc) — standard containers. Isolation comes from Linux namespaces, cgroups, and seccomp. The container shares the host kernel. Fast and universal, but a kernel exploit crosses the boundary.
gVisor (runsc) — a user-space kernel from Google. It intercepts the container's syscalls and services them in a sandboxed process instead of passing them straight to the host kernel. That's a second wall between the code and the real kernel.
Firecracker — a microVM built on KVM hardware virtualization. Each sandbox is a real (tiny) virtual machine with its own guest kernel, booting in ~125ms. This is the strongest boundary of the three — it's what AWS Lambda and Fargate use to isolate tenants.

Comparison at a glance

	Docker (runc)	gVisor (runsc)	Firecracker
Boundary	Shared host kernel	User-space kernel intercepts syscalls	Hardware-virtualized microVM
Escape resistance	Weakest	Strong	Strongest
Startup	Fastest (tens of ms)	Fast	~125ms boot
Runtime overhead	Near-zero	Syscall-heavy workloads pay a cost	Low, plus a small memory floor per VM
Compatibility	Full	Some syscalls unimplemented	Full (real kernel in guest)
Complexity	Lowest	Low (drop-in runtime)	Higher (VM lifecycle, images)
Used by	~Everyone	Google Cloud Run, GKE Sandbox	AWS Lambda, Fargate

Docker: the baseline, not the answer for untrusted code

A hardened one-shot Docker container — non-root, dropped capabilities, seccomp on, read-only filesystem, no network by default — is a perfectly reasonable sandbox for internal tools where the blast radius is contained. It's the fastest and simplest option.

Its weakness is structural: the container shares the host kernel. One kernel vulnerability, and "isolated" code is on the host. If you're running genuinely untrusted or multi-tenant code, Docker alone is a bet on the kernel being flawless.

gVisor: a second kernel wall, at a compatibility cost

gVisor slots in as a container runtime (runsc), so it's close to a drop-in upgrade. Instead of your code's syscalls hitting the host kernel directly, they hit gVisor's user-space kernel first. An attacker now has to break gVisor and the host kernel.

The tradeoffs: gVisor doesn't implement every syscall, so some workloads break, and syscall-heavy programs pay a performance tax. For sandboxed Python doing data analysis or API calls, it's usually fine. For exotic low-level code, test compatibility first.

Firecracker: real isolation, real VM lifecycle

Firecracker gives each execution its own microVM with a separate guest kernel. Because the boundary is hardware virtualization, it's the strongest of the three — an escape has to break out of a VM, not just a namespace. It boots in ~125ms and strips the device model down to almost nothing.

The cost is operational: you're managing VMs, guest images, and a memory floor per instance. If you're multi-tenant, handling other people's data or money, or running adversarial code, that cost buys you isolation you can actually defend.

So which should you use?

Internal tool, your own code/data → hardened one-shot Docker. Fast, simple, good enough.
Untrusted code, moderate risk → gVisor. A big jump in isolation for little operational change; just verify syscall compatibility.
Multi-tenant, real money/data, adversarial input → Firecracker (or Kata Containers). Pay the VM tax; you'll want the hardware boundary.

The isolation tech is one decision. The policies around it — disposable per-run, default-deny egress, read-only mounts, quotas — matter just as much, whichever runtime you pick.

We're Xingyao Byte — building secure AI-execution layers, quant trading systems, and payment platforms. Remote, async-first. More at stellarbytecapital.com

DEV Community: Weston Carnes