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