Sandbox Isolation
Run agent-emitted code in a container, microVM, or WASM runtime with restricted filesystem, network, and process privileges — contain the blast radius.
Intent & Description
🎯 Intent
Prevent agent mistakes or hostile inputs from escaping into the host system.
📋 Context
Your agent executes model-generated code or runs shell commands. The agent sees user inputs, retrieved documents, and tool outputs that may be hostile or just wrong. The host holds developer files, credentials, or shared infrastructure.
💡 Solution
Run code in a container, microVM, WASM runtime, or restricted subprocess with minimal privileges. Filesystem is read-only or scoped to a working directory. Network is allowlisted or blocked. Resource limits cap CPU/memory/time. Persistent state is ephemeral by default.
Real-world Use Case
- The agent executes generated code or operates the filesystem.
- Host damage (deletion, exfiltration, malware) is a credible risk.
- A container, microVM, or WASM runtime can be deployed for execution.
Source
📌 TL;DR
Agent runs code? Put it in a sandbox. Restricted filesystem, allowlisted network, capped resources. Bad actions stay contained.
Advantages
- Blast radius is contained — a bad agent action can’t nuke the host.
- Same sandbox image is reproducible across runs; debugging is repeatable.
Disadvantages
- Some workflows legitimately need network or filesystem access the sandbox forbids.
- Sandbox technology (Docker, gVisor, Firecracker, WASM) is its own engineering surface.