Agent Sandboxing

How it works

Sandboxing puts a boundary between what the agent decides and what the world actually executes. The agent proposes an action; the boundary decides whether that action ever reaches a real resource. There are two common layers, and mature harnesses use both.

1. Environment-level containment. The agent runs inside an OS sandbox — a container, a VM, or a filesystem and network jail. The process simply has no path to the host: no unlisted directories, no outbound sockets, no ambient credentials. This is coarse but hard to argue with, because it is enforced below the model.
2. Tool-call interception. Inside the harness, a block hook sits on every tool invocation. Before a shell command, write, or HTTP call runs, the hook inspects the concrete arguments and allows, rewrites, or denies it. This catches things the environment can't reason about — a rm outside the work tree, a write to a production path, an exfiltration attempt hidden in a benign-looking call.

The key property is that enforcement is external to the model. You are not asking the agent to behave; you are removing its ability to misbehave. A sandbox you can trust holds even when the prompt is poisoned, the plan is wrong, or the model hallucinates a destructive step.

Why it matters in an agent harness

An unattended agent is a program whose next instruction you did not write. That is the whole risk. Sandboxing is how you make that acceptable.

It caps blast radius: the worst outcome of a bad run is bounded to what lives inside the boundary, so a mistake costs you a disposable work tree, not a database. It makes least privilege real instead of aspirational — the agent gets exactly the paths, tokens, and network egress the task needs, and nothing carries over from your shell. It is also your primary defense against prompt injection, because a boundary that denies unlisted actions doesn't care whether a malicious instruction came from the operator or from a scraped web page; untrusted text can't grant privilege it doesn't have.

Sandboxing is what buys autonomy. The reason you can let a run go for an hour without watching it is not that the model is trustworthy — it's that the boundary is. Containment and reversibility together are what let you say yes to unattended work: the sandbox limits what can happen, and checkpoints let you undo what did.

Agent sandboxing vs guardrails

Both constrain the agent, but they enforce at different layers and fail differently. The distinction decides where you spend your engineering effort.

A guardrail says don't touch production. A sandbox makes production unreachable. You want both — the guardrail for nuanced, semantic decisions and the sandbox as the floor that holds when the guardrail is wrong.

The Rifty take

We optimize for boundaries the model cannot argue with. A rule that lives only in the prompt is a suggestion; enforcement belongs below the agent, in the environment and the tool-call hook, where no amount of clever text changes the outcome. We accept the friction of explicitly granting every path, token, and egress route, because the alternative — ambient access — is the thing that turns a small mistake into an incident. The boundary is not a feature you add for nervous users; it is the precondition for delegating unattended work at all.

Common failure modes

• Ambient credentials leak in. The sandbox blocks the filesystem but inherits your environment variables or a mounted ~/.aws. Scrub the environment; grant tokens explicitly and scoped.
• Network egress left open. File writes are contained but the agent can still POST anywhere, so exfiltration and injection payloads still work. Default-deny outbound and allowlist specific hosts.
• The block hook only checks the happy path. It matches rm -rf / but misses a shell one-liner, a symlink escape, or an equivalent call through a different tool. Validate the resolved effect, not the surface string.
• Escape hatches become the norm. A blanket "allow anything in this session" toggle exists for emergencies and quietly becomes the default. Make broad grants loud, temporary, and logged.
• Confusing a sandbox with a rollback. Containment limits reach; it does not undo committed changes inside the boundary. Pair the sandbox with checkpoints so a bad-but-permitted run is still reversible.
• Untested boundary. A sandbox you never probe is a boundary you're guessing at. Periodically run adversarial tasks that try to escape and confirm they're denied.

Frequently asked questions

Is agent sandboxing the same as a guardrail?

No. A guardrail is a policy or prompt-level check that decides whether an action should be allowed; a sandbox is a structural boundary that decides whether an action can physically reach a resource. Guardrails fail to persuasion, sandboxes fail to denial. Production harnesses layer both.

Does sandboxing protect against prompt injection?

Substantially, yes. A boundary that denies unlisted actions doesn't care whether a malicious instruction came from the operator or from scraped web text — injected content can't grant privilege the sandbox never issued. It won't stop the model from being fooled, but it stops the fooled action from doing damage.

Where should I enforce the boundary — the OS or the harness?

Both. Use OS-level containment (container, VM, filesystem and network jail) as the coarse floor that holds unconditionally, and an in-harness tool-call block hook for fine-grained decisions the environment can't reason about, like a write to a specific path. Neither layer alone is sufficient.

Doesn't sandboxing limit what the agent can accomplish?

It limits reach, not capability. You grant exactly the paths, tokens, and egress the task needs. If a task legitimately requires more, you widen the grant deliberately and log it. The friction is the point: broad, ambient access is what turns a small mistake into an incident.

Is a sandbox enough to run agents unattended?

It's necessary but not sufficient. Sandboxing caps blast radius, but it doesn't undo permitted-but-wrong changes made inside the boundary. Pair it with checkpoints or rollback so a contained mistake is also reversible, and with observability so you can see what the run actually did.