How it works
A sandbox is an execution boundary you draw around code you don't trust. Model-generated code, third-party tools, and agent-invoked commands run inside it; nothing they do escapes without passing an explicit interface. The mechanism is a stack of isolations:
- Compute isolation: a container, microVM, or separate process with its own kernel view, so a crash or exploit stays local.
- Filesystem isolation: a scratch volume that is ephemeral or read-only, with no path back to host secrets or shared storage.
- Network isolation: egress denied by default; an allowlist opens only the endpoints a task actually needs.
- Resource limits: CPU, memory, and wall-clock caps, so a runaway loop dies instead of starving the host.
The sandbox is disposable by construction. You spin it up per task, let the agent work, capture the outputs you asked for, and tear it down. State that matters is copied out through a narrow channel; everything else is discarded with the environment. That disposability is the point—an error or an injection inside the box costs you a teardown, not a recovery.
Why it matters in an agent harness
An agent writes code and runs it. That is its power and its exposure. Without a sandbox, tool use executes with the harness's own privileges, so a hallucinated rm, a poisoned dependency, or a prompt-injected instruction inherits your credentials and your network. Sandboxing caps the blast radius: the worst case is scoped to a disposable environment instead of your production host.
It also makes autonomy affordable. If every generated command could touch anything, you need a human on every action. Put the agent inside a bounded environment and you can let it iterate—write, run, fail, retry—without a gate on each step, because the boundary, not your attention, is doing the containment. That converts oversight from per-action review into interface design: you review what crosses the sandbox edge, not what happens inside it.
And it makes failure legible. A sandbox is a natural observation point. Every file write, every egress attempt, every process is visible at the boundary, so you get a trajectory you can audit instead of guessing what the agent did to a shared system.
Sandboxing vs least privilege
Sandboxing draws a boundary and isolates execution. Least privilege minimizes what authority exists inside that boundary. They are different controls that compose, and treating one as a substitute for the other is a common mistake.
| Sandboxing | Least privilege | |
|---|---|---|
| Mechanism | Isolate execution in a disposable environment | Grant only the permissions a task needs |
| Failure it stops | Escape to host data or systems | Over-broad authority within reach |
| Granularity | Environment / process | Credential / capability |
| Alone, it still leaks when | The box holds root and open egress | It runs on a shared, un-isolated host |
Use both: a sandbox with least-privilege credentials inside it. A sandbox that holds admin keys is just a smaller cage around the same danger.
The Rifty take
We treat the sandbox as the default execution surface for anything a model generates, not a hardening step you bolt on later. The judgment we carry is that containment should be structural: the agent runs in a disposable box with deny-by-default egress, and we design the narrow interface where results cross out. We accept the overhead of spinning environments up and down because a boundary you can reason about beats trusting output you can't. Speed inside the box is fine; the edge is where we stay strict.
Common failure modes
- Leaky egress: an "isolated" sandbox with open outbound network can still exfiltrate data or pull malicious payloads. Deny egress by default and allowlist per task.
- Credential smuggling: mounting host secrets, cloud metadata, or broad tokens into the sandbox recreates the risk you isolated against.
- Shared writable mounts: a scratch volume that also maps a shared path lets a mistake escape through the filesystem.
- Persistent reuse: reusing one long-lived sandbox across tasks lets state and compromise accumulate; prefer per-task disposal.
- Unbounded resources: no CPU, memory, or time caps turns a runaway agent loop into a host-level denial of service.
- Trusting sandboxed output blindly: isolation contains execution, not correctness—still diff-review and evaluate whatever crosses the boundary before it reaches production.
Frequently asked questions
What is the difference between sandboxing and a guardrail?
A guardrail is a policy check on actions—it decides whether an action is allowed. A sandbox is an isolation boundary—it limits what an allowed action can reach. Guardrails filter intent; sandboxes contain execution. You want both: a policy check before the action and containment around it.
Do I still need sandboxing if my agent only calls approved tools?
Yes. Approved tools can still be misused through poisoned inputs, prompt injection, or bad arguments, and any code the model generates runs somewhere. A sandbox bounds the blast radius of a tool behaving unexpectedly, so an approved surface does not quietly become an unbounded one.
How is sandboxing different from least privilege?
Sandboxing isolates execution in a disposable environment; least privilege minimizes the permissions available inside it. One stops escape to the host, the other stops over-broad authority within reach. They compose—run a least-privilege credential set inside a sandbox rather than choosing between them.
What is the most common way a sandbox fails?
Open network egress. Teams isolate compute and filesystem but leave outbound network on, so a compromised or injected agent can exfiltrate data or fetch payloads. Deny egress by default and allowlist only the endpoints a task genuinely needs before it runs.
Can an agent run autonomously inside a sandbox without review?
Inside the boundary, yes—iteration is cheap when nothing escapes. But review what crosses the edge: outputs, commits, and egress. Sandboxing converts per-action oversight into interface design, so you gate the narrow channel out, not every step the agent takes within the box.