Why sandboxes exist
An agent given raw access to your machine can do anything you can: sign transactions, delete folders, drop tables. A sandbox is an isolated computing environment — typically a container or micro-VM — where the agent runs with an explicit allowlist. Everything else is denied by default.
Capability tokens
Instead of your real keys, the agent holds scoped tokens: "spend up to $5", "read /projects only", "SELECT but never DROP". Revoking a token instantly removes the power.
Isolation layers
Containers (fast, shared kernel) vs. micro-VMs like Firecracker (~125 ms boot, hardware isolation). Most agent platforms pick micro-VMs when money or secrets are in scope.
Human-in-the-loop gates
High-risk calls pause for approval. A common policy: auto-approve reads, require sign-off on any write over a dollar threshold or any irreversible action.
Worked example: a $50 spending cap
Suppose an agent buys API credits autonomously. A sane policy stack:
1. Wallet capability: max_per_tx = $5, daily_cap = $50
2. Merchant allowlist: 3 approved endpoints only
3. Worst-case loss = daily cap × days-to-detection. With daily review: $50. Without caps and weekly review: potentially unbounded × 7 days.
That difference — bounded vs. unbounded loss — is the entire argument for sandboxed agent environments, whatever project implements them.
Reading the visualization
The amber core is the agent's runtime. The translucent shell is the sandbox boundary. Nodes outside are real resources; a bridge only forms when you grant that capability. Raising autonomy speeds the pulse of actions — and lowers how often a human checks in. Drag to orbit the scene.