Tool Execution Sandbox — Stack

Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.

Selection criteria

The whole evaluation is a trade between how strong the boundary is, how long it takes to get one, and how much of a normal runtime survives inside it.

• Threat model fit. Whether the isolation is intended to contain mistakes or to contain an adversary who is deliberately trying to escape. These justify very different costs, and conflating them is how containers end up protecting nothing.
• Startup latency. Time to a usable environment, since it lands inside a turn the user is waiting through. Measure a cold start, not a warm one.
• Kernel sharing. Whether the confined code sits on the same kernel as the host, which determines whether a kernel vulnerability is an escape or an inconvenience.
• Resource enforcement granularity. Whether processes, memory, disk, file descriptors, and wall-clock can all be capped, and whether a breach kills cleanly with a diagnosable signal.
• Network control. Whether egress is default-deny with an explicit allowlist that covers internal destinations and the host metadata endpoint, not only public addresses.
• Runtime compatibility. Which language runtimes, native extensions, and filesystem behaviours work inside. The stricter options break a large fraction of ordinary libraries.
• State and artefact handling. How files and results leave, and whether a persistent workspace is available for iterative work without weakening per-tenant isolation.
• Operability. Whether a confined failure can be diagnosed afterwards, since the properties that make a boundary strong also make it opaque.

Options