Agent sandbox
An isolated execution environment — usually a container, microVM, or browser profile — where an agent can run code, browse, and act without affecting the host system or shared state.
Sandboxing is the answer to "what happens when the agent runs `rm -rf /`?" In a sandbox, the answer is "it deletes the sandbox," not your production system. The agent gets a clean, ephemeral filesystem, scoped network access, and a kill timer.
In 2026 the common implementations are Docker containers (cheap, slower startup), Firecracker microVMs (E2B, Modal, Daytona — fast cold start, strong isolation), and isolated browser profiles (Browserbase, Anchor Browser) for browser agents.
Sandboxing is non-negotiable for any agent that runs untrusted code, browses the open web, or accepts user-uploaded inputs. The performance overhead is small; the safety upside is enormous.
Frequently asked
Do I need a sandbox if the agent only calls trusted APIs?+
You need scoped credentials and timeouts at minimum. Full sandboxing matters most for code execution and browser use, where the agent can wander into untrusted territory.
How fast can a sandbox cold-start?+
Firecracker microVMs (E2B, Modal) cold-start in 100–300 ms. Docker containers 1–5 s. Browser sandboxes 1–3 s. Pre-warm pools shave startup to near-zero for high-volume agents.