# How to safely run AI-generated code — a practical sandboxing checklist > Source: > Published: 2026-07-29 03:31:14+00:00 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.** Before controls, be honest about what can go wrong when you run untrusted code: "The model probably won't do that" is not a control. Design for the case where it does. 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. `gVisor` , `Firecracker` ) is stronger against kernel escapes.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](https://www.stellarbytecapital.com/)