Agent sandboxes

Any tool that runs code, drives a browser or touches the filesystem needs isolation. The agent is not a trusted employee. It is a probabilistic process that will eventually rm the wrong path or follow a malicious instruction in a webpage.

The big idea

subprocess on the API box with the agent's shell tool is how you get remote code execution on yourself. If the model can run code, that code runs somewhere else.

Hardening checklist:

• No cloud credentials inside the sandbox by default. Inject short-lived, scoped tokens per action.
• Egress allowlists (package registries, approved APIs). Not the open internet plus your metadata endpoint.
• Resource caps: CPU, memory, disk, wall time.
• Fresh filesystem per run or per session. Snapshot only when you need continuity.
• Separate sandboxes per tenant in multi-tenant products.

For browser and code tools, permissions include network: which hosts the sandbox may call. Default-deny egress with an allowlist (package mirrors, your API, the model provider) stops the classic "agent reads the cloud metadata endpoint" failure. Pair with secret scanning on tool args if users paste keys into chat.

Walking through a coding run

A user asks: "Fix the flaky test in checkout.spec.ts."

The runtime creates a sandbox from a snapshot of the repo at a commit SHA. It injects a read-only GitHub token scoped to that repo. Tools read_file, edit_file and run_tests all execute inside the sandbox. Edits never touch the API host. The token cannot see other repos.

Without a sandbox, edit_file is editing your laptop. Without scoped credentials, the GitHub token might be org-wide admin "because it was easier."

Common mistakes

• Running the shell tool on the API process. One prompt injection becomes host compromise.
• Open egress plus a metadata endpoint. The agent fetches cloud credentials.
• One shared sandbox for every tenant. Files and env leak across customers.

Check yourself

1. Where should run_python execute? In a sandbox with no production secrets, not on the API box.
2. Why default-deny network? A hostile page or issue can tell the agent to exfiltrate secrets or hit internal URLs.

Key takeaways

• Untrusted code and browsers run in sandboxes with egress and credential isolation.
• Inject short-lived, scoped tokens per action. Never leave long-lived cloud keys in the environment.
• Cap CPU, memory, disk and wall time. Fresh filesystem per run.
• Separate sandboxes per tenant.

Further learning

Long waits and crashes need more than a container. That is durable execution.