Sandboxing agents

Everything so far has been about reducing the chance that an agent does something bad. A sandbox starts from the opposite assumption: it might, so what can it reach? If the answer is "almost nothing important", then a hijacked, confused or compromised agent has little to do. You met the general idea in level 4 (sandboxes and containers). This lesson applies it to agents.

Four things to constrain

An agent harms you through four channels. A useful sandbox narrows each.

Notice that these are the four channels from the earlier lessons: credentials are what gets stolen (lesson 6), the filesystem is what gets deleted (lesson 7), and the network is how data leaves.

The layers

Beam's post on agent harnesses lays out the recurring mechanisms. From lightest to heaviest:

• OS-level sandboxing in the harness. Codex CLI's default workspace-write mode limits writes to the active workspace and disables network by default, and Claude Code's documentation describes sandbox boundaries built on Seatbelt on macOS and bubblewrap on Linux. These are cheap and run in-process.
• Containers. A container hides the host filesystem and can be thrown away. It shares the host kernel, so it is a good boundary against mistakes and a weaker one against a determined escape.
• MicroVMs. A lightweight virtual machine with its own kernel. Strong isolation at near-container speed, which is why agent platforms use them.
• A separate harness and sandbox. Google's published Agent Compute Engine design, summarised in Beam's post, keeps the model-calling loop (the "brain") outside the microVM and runs only the code and shell (the "hands") inside, so a compromised sandbox cannot rewrite the agent's decision logic or reach its model credentials. It also keeps credentials outside, as in lesson 6. That is a vendor description, not an audit, and Beam notes it is internal to Google today.

An open-source example of the VM approach is Capsem, which Beam's analysis describes as booting each agent session in a short-lived Linux VM with a read-only root and a proxy that terminates and logs all HTTPS. Beam also reports that Capsem's public pages disagreed about how finished it was and that it had not installed it; the architecture is worth studying, the maturity is unverified.

One practical rule falls out of Beam's guide to stopping dangerous Claude Code commands: the flag that turns off the permission system entirely, --dangerously-skip-permissions, belongs only inside a container or VM, never on your host.

A real test: the wall held, the allowlist did not

In September 2026 Perplexity's Secure Intelligence Institute published a test of its own sandbox, called SPACE (Firecracker microVMs plus a per-sandbox egress gateway). Beam's summary reports the design: nine models were given root inside the guest and told to either steal a host-side AWS honeytoken or fetch a flag from a URL the egress policy blocked, in 216 runs.

• VM escape: 0 of 108 runs obtained the host token.
• Network, no egress allowed: 0 of 54 succeeded.
• Network, with the PyPI and Ubuntu package mirrors allowed: 11 of 54 succeeded, across four models.

The two reported methods were a forged DNS mapping that pointed an allowed name at the attacker's address, and a shared content-delivery IP that also served another tenant. After the fix, forged DNS was dropped and the connection's host name had to match the allowlist, and reruns held. Beam also reports that in the wider comparison, 8 of 10 sandboxes tested had a network-policy bypass.

The lesson is the split. A VM wall and a network policy are different boundaries, and the second failed the moment a useful allowlist existed, because to install packages the sandbox had to be allowed to talk to somewhere. Every exception you make for convenience is a place to test. These are Perplexity's own results from its own test design, so treat them as a careful vendor study rather than an independent audit.

What Beam is, and is not

Beam's own documentation is direct: its workspace policies "are not an operating-system sandbox". It records and can deny matching tool calls through hooks, and policy that is missing or expired allows the action. Beam's post on monitor-versus-block calls kernel sandboxes a different layer, one you still need for long-running or untrusted agents. The benchmark's acting outside the workspace family measures the agent's side of it: does it stay in its folder when a symlink, a parent .env, a sibling project or a shell profile makes leaving easy? Sandboxing and monitoring answer different questions, and neither replaces the other.

How AI changes this

Sandboxing is an old idea made urgent. Untrusted code used to arrive occasionally; now a tool decides to execute code dozens of times an hour, driven by text from anywhere. The new factor is an adversary that adapts: Perplexity's test used models told to escape, and the successful routes were found through ordinary-looking network behavior. Attackers can use agents to probe sandbox boundaries at scale; defenders can use the same technique to red-team their own sandboxes before anyone else does, which is exactly what that test was. The agent is both the thing you contain and, increasingly, the tool you test containment with.

Try it

A real sandbox needs a container or VM runtime, which you may not have. This lab shows the smallest useful idea, shrinking one resource (the environment) on your own machine, and is honest about what it leaves open. It uses a fake key, runs only Python, and touches nothing. Save as envlab.py.

import os, subprocess, sys, tempfile

os.environ["DEMO_API_KEY"] = "FAKEKEY-1234-0000"
probe = "import os; print(sorted(k for k in os.environ if 'KEY' in k or 'TOKEN' in k))"

def run(env=None, cwd=None):
    return subprocess.run([sys.executable, "-c", probe], env=env, cwd=cwd,
                          capture_output=True, text=True).stdout.strip()

print("inherited:", run())
print("scrubbed :", run(env={"PATH": "/usr/bin:/bin"}, cwd=tempfile.mkdtemp()))

The inherited list shows every variable your shell passed down, probably including more than your fake one (editor and tool tokens often appear). The scrubbed run shows none. Now extend the script to also print os.access(os.path.expanduser("~"), os.R_OK) from the child: it is still True. The child process can read your home folder. You removed one channel (credentials in the environment) and left three open (filesystem, network, privileges). That gap is why sandboxes are layered, and why a container or OS sandbox is the next step if you run agents regularly.

Check yourself

Next

Walls limit what an agent can do. Next: watching and judging what it does, and why that is harder than it sounds.