Agent sandbox¶
When an agent writes code and runs it, you are executing something nobody reviewed. The sandbox is where that happens safely: an isolated environment with its own filesystem, no implicit network access, no mounted credentials, and a lifetime measured in minutes.
The isolation model¶
| Boundary | What it means |
|---|---|
| Namespace | Each sandbox gets its own project, with quotas and limits |
| Network | Default-deny egress; the sandbox reaches only what you allow |
| Credentials | No service account token, no mounted secrets by default |
| Filesystem | Ephemeral volume, discarded when the sandbox ends |
| Resources | CPU, memory and runtime capped; runaway loops die on their own |
| Hardware | Bare-metal or dedicated workers available where you need physical isolation |
Where it sits¶
flowchart TB
AGENT["Agent"] -->|submit code| SB
subgraph SB["Sandbox namespace"]
POD["Ephemeral pod<br/>no token · no secrets"]
VOL["Ephemeral volume"]
POD --- VOL
end
SB -->|results only| AGENT
SB -.->|default deny| NET(["Network"])
SB -.->|explicitly allowed| PKG["Package registry"]
Results come back to the agent. Nothing else crosses the boundary unless you open it deliberately.
Allow egress narrowly, not generally
Most sandboxes need one thing from the network: a package registry. Allow that host and DNS, and leave the rest denied. A sandbox with open egress can exfiltrate anything it is given.
Related¶
- Run a sandboxed agent
- MCP servers — the tools an agent calls, as opposed to the code it writes
- Networking — the
NetworkPolicypatterns behind the boundary
Scaffold status
This is a placeholder. Sandbox lifecycle API, image catalogue and resource profile defaults are written here once confirmed against the platform.