Run code you
don't trust.

The moment an AI system executes code it generated — a Python snippet to crunch a spreadsheet, a shell command to inspect a repo, a tool the model wrote itself — you've introduced untrusted code into your process. And it's genuinely untrusted: the model can be wrong, and worse, a prompt injection in some document it read could steer it into writing code that exfiltrates data or deletes files. Running that directly on your host is a loaded gun pointed at your own foot.

Sandboxing lets you run it anyway by isolating it: the code executes in a contained environment where it can only touch what you explicitly permit and only consume the resources you allot. If it misbehaves, the damage is confined to the sandbox — the blast radius stays small. The whole discipline is about defining that containment correctly, and the single most important decision is the default: what happens to an operation you didn't think about?

There are two ways to write a security policy. A block-list tries to enumerate everything dangerous and forbid it — no rm -rf, no network to these hosts, no reading that file. It feels natural and it's almost always wrong, because you cannot list every bad thing. Attackers (and confused models) find the one path you forgot, and there's always one you forgot.

Deny-by-default inverts the logic: everything is forbidden unless it's on an explicit allowlist of permitted operations. Now you only have to enumerate the small, well-understood set of things the code legitimately needs — read this file, call this API — and anything not on that list is denied automatically, including the attacks you never imagined. You can't enumerate all evil, so you enumerate the little good instead. This is the foundational rule of every serious sandbox: the default answer to "may I?" is no.

Deny-by-default asks you to write the allowlist — and how you size it is the principle of least privilege: grant only the minimal permissions the task needs, nothing more. A script that summarizes one file needs to read that one file — not write anywhere, not open the network, not spawn processes. Every permission you add back is a door you've opened.

There's a precise relationship here: the smaller the allowlist, the larger the set of denied operations — the escape surface the sandbox successfully blocks. Every operation you don't allow is one the code can't use to escape or cause harm. So least privilege isn't just tidy; it's directly proportional to safety. Grant read-only when read-only will do, and the code physically cannot delete, exfiltrate, or persist — no matter what it tries.

A sandbox is a decision function over operations. Deny-by-default means an operation is permitted only if it's on the allowlist A; the denied set — the escape surface — is everything else:

Least privilege = keep A small, so Ops ∖ A (what the sandbox blocks) is large. Every op not in A is one the code can't perform.

But policy is only half. Even an allowed operation can run away — an infinite loop, an allocation bomb — so you add resource caps: an operation runs only if it's both permitted and within budget:

Policy says what is allowed; caps say how much. You need both — same bounding idea as an agent harness's step/budget limits. The runnable version below is a deny-by-default policy with a resource cap and the escape surface.

Real sandboxes enforce the policy at several levels — the more independent layers, the harder to escape (the same defense-in-depth logic):

Two defaults do most of the work: no network egress (so code can't exfiltrate or phone home) and no credentials mounted (so even if it reads the filesystem, there's nothing to steal). Give the code an ephemeral, throwaway environment with only the specific inputs it needs, and destroy it after. This pairs directly with the harness: the harness bounds how many steps and how much money; the sandbox bounds what each step can touch. Together they contain an agent that can run code.

The most common mistake is a leaky sandbox that feels safe: running "isolated" code that still has network access, a mounted secret, or a writable host path. Isolation is only as strong as its weakest allowed permission — one forgotten door defeats the whole wall. Audit what's actually reachable from inside, not what you intended. A close cousin is reusing environments: if one task's sandbox persists into the next, malicious state (a planted file, a poisoned cache) carries over — make sandboxes ephemeral and per-task.

Two more. Forgetting resource caps: an allowlist stops forbidden operations but not an infinite loop or an allocation bomb using permitted ones — always cap CPU, memory, and time. And trusting the sandbox's outputs: code may be contained, but whatever it returns flows back into your system (and maybe the model's context), so treat sandbox output as untrusted too and validate it at the boundary. Sandboxing is an exercise in humility: assume the code inside is hostile, grant it the least you can, bound how much it can do, and give it nothing worth stealing. Do that and you can safely let an agent run the code it writes.