The most powerful tool you can give an agent is the ability to write and run code. It is also the most dangerous. Model-generated code is untrusted by construction — it may be wrong, it may be adversarially injected, and it will sometimes try to do exactly what you fear. Running it anywhere near your infrastructure is unacceptable. This chapter is about the isolation layer that lets agents execute arbitrary code without putting the platform at risk.

9.1 Why a sandbox is non-negotiable

Reason from the threat model. Code an agent emits can read secrets from the environment, exfiltrate data over the network, consume unbounded CPU or memory, escape into the host, or pivot to other tenants. A coding agent will routinely pip install packages, write files, and spawn processes. The only safe assumption is that execution is hostile, so it must occur in an environment that is isolated (no access to host or other tenants), ephemeral (destroyed after use, no persistence of compromise), resource-bounded (hard CPU/memory/time limits), and network-controlled (egress denied or allow-listed).

9.2 The isolation spectrum

Isolation techniques trade security strength against startup latency and overhead. Heavier boundaries are harder to escape but slower to spin up — and an agent may create many short-lived sandboxes, so cold-start time is a first-class concern.

9.3 Build on a managed sandbox or run your own

You can assemble isolation yourself from Firecracker or gVisor, or adopt a managed sandbox that exposes a simple "run this code, get the result" API while handling microVM provisioning, snapshotting, and teardown. For most teams the managed route is right; reserve self-hosting for when data-residency or cost at very high volume demands it.