What you are actually defending against
Accidental destruction. The model writes rm -rf on a path that resolves somewhere unexpected, or a loop that fills the disk. No attacker required. This is the common case and the cheapest to defend.
Open-source AI infrastructure
How to Safely Run AI-Generated Code
A practical threat model for executing code an LLM wrote: why containers alone are the wrong boundary, what microVMs and gVisor actually buy you, and the network, f…
Choosing an isolation primitive
Containers share the host kernel. The isolation is namespaces and cgroups, which is a boundary designed to separate cooperating workloads, not to contain hostile ones. Container escapes are a recurring class of vulnerability, and "we run it in Docker" is not the answer to "how do you contain untrusted code".
The controls that matter more than the primitive
Here is the part most guides skip. A microVM with unrestricted network egress is a worse security posture than a container with none, because exfiltration does not require an escape.
Do not build this yourself
Everything above is achievable with Firecracker, iptables and cgroups directly. It is also a lot of surface to get right, and the failure mode is silent: a misconfigured egress rule does not throw an error, it just quietly permits exfiltration until someone notices.
A checklist
Isolation is a microVM or gVisor, not a bare container, for model-generated code. Egress is default-deny with an explicit allowlist. 169.254.169.254 is blocked. Sandboxes cannot reach each other. No provider API keys in the sandbox environment. CPU, memory, disk and wall-clock limits are all set and all fire. Sandboxes are destroyed after one unit of work, never reused across tenants. You have tested the above by tr…