Code Execution Sandboxes for Agents

When an agent generates code, something has to run it. Running that code directly on a developer laptop or production server is risky: the code could delete files, read credentials from environment variables, install software, mine cryptocurrency, or open network connections. A sandbox puts a boundary between the code and everything else. There are several layers of isolation, with different trade-offs. Standard containers (for example Docker) use Linux namespaces and cgroups to give code its own view of processes, files and network, and to limit CPU and memory. They start quickly, but every container shares the host's kernel, so a kernel vulnerability can let code escape. gVisor, an open-source project from Google, adds a user-space kernel that intercepts system calls, shrinking what untrusted code can touch on the real kernel. MicroVMs such as Firecracker, originally built by AWS for Lambda and Fargate, give each workload its own lightweight virtual machine and kernel while still booting in a fraction of a second. Hosted sandbox services for agents, such as E2B, build on this microVM approach. At the lightest end, WebAssembly runtimes and tools like Pyodide can run Python in a browser or Wasm sandbox with no direct system access. Isolation technology is only half of the design. Good sandboxes also restrict the network (often deny-by-default with an allowlist), mount the filesystem read-only except for a scratch directory, keep secrets out of the environment entirely, and enforce time, memory, process-count and disk limits. They are usually ephemeral: created per task and destroyed afterward. A common misconception is that a sandbox makes an agent safe. It limits damage from the code itself, but it does not stop an agent from producing wrong answers, and any tool or credential you pass into the sandbox becomes reachable by whatever code runs there, including code written in response to injected instructions.