Definitions

Definitions

Layers

Results

1. Resolve first, then compare. String checks on unresolved paths and URLs are bypassed by prefixes, symlinks and @ tricks.
2. Parse, do not search. Use a URL parser and compare the host exactly; refuse IP literals, odd ports, userinfo and trailing dots.
3. Never pass model text to a shell. The command check rejects metacharacters and runs a program with an argument list, not shell=True.
4. Wall-clock and CPU limits are both needed; a sleeping process uses no CPU.

Design rules

• Run model-written code in a boundary that does not trust it: separate container or microVM, non-root user, read-only root, a writable scratch directory, no host mounts.
• Deny network by default; if needed, route through a proxy with a host allowlist, and log requests.
• Scrub the environment: pass only the variables the task needs; never inherit secrets.
• Set limits on CPU, memory, file size, process count and wall clock, and kill the whole process group on timeout.
• Confine file tools with realpath plus commonpath against a resolved root, reject null bytes, and prefer opening relative to a directory descriptor with O_NOFOLLOW.
• Validate URLs by parsing, and re-validate after each redirect and DNS resolution (rebinding), or block internal ranges at the network layer.
• Allowlist commands and arguments; prefer purpose-built tools to a general shell.
• Make the sandbox disposable: one per task or session, destroyed afterwards, so persistence is limited.
• Log and alert on denials (module 9).

Interview questions, with the follow-ups

Common mistakes

• startswith path checks without resolving.
• shell=True with model-generated text.
• Inheriting the parent environment, including secrets.
• Only a timeout (no memory or file limits) or only CPU limits.
• Open network from the sandbox.
• Shared long-lived sandboxes that keep state between users.
• Mounting the host home or Docker socket into the container.
• Validating a URL once and following redirects blindly.
• Treating rlimits as isolation.

What the example does not do

• No container, VM, seccomp or network namespace; only argument checks and process limits.
• Linux only, and RLIMIT_AS behaves differently across systems and runtimes.
• No limit on process count (a fork bomb is a real risk; I deliberately did not run one) and no CPU-time accounting for child processes of the child.
• No TOCTOU defence, no redirect or DNS-rebinding handling, no Unicode or case-folding attacks on paths and hosts beyond what the tests show.
• Hand-written, small attack lists; passing them is not proof of safety.
• Optional real experiment (I did not run this): run the same probes inside a container with --network none, --read-only, --pids-limit and --memory, and compare.

For the curious Limits are not isolation

CPU, memory, file and time limits stop denial of service; the infinite loop was killed after 1.02 s by a 1 s CPU limit. But a limited process can still read any file its user can and open network connections. Only a boundary (container, microVM, separate user, no network) stops data access. I tested layers 1 and 2 on Linux; container and network isolation were not built, and the check-then-use race is not handled.

What you must be able to say (one page)

• A sandbox limits what code can touch even when you cannot trust it. Agents run model-written code, read files chosen by the model and fetch URLs chosen by the model, so you assume those inputs are hostile and enforce limits outside the model. Sandboxing agents in isolated environments limits the blast radius if an agent is compromised or misbehaves, and production deployments need timeouts, per-session memory monitoring and containerisation for resource limits.
• Four layers, each assuming the previous failed: (1) validate tool arguments (paths, URLs, commands); (2) limit the process (CPU, memory, file size, time, environment); (3) isolate it (container or microVM, read-only root, no host mounts); (4) control the network (deny by default, allowlisted egress). I built and tested layers 1 and 2; layers 3 and 4 are described, not built.
• Naive checks fail in specific, testable ways. Against 10 path-escape attempts: startswith(root) wrongly allowed 80 percent (it misses ../work-evil prefix collisions and symlinks), normalising without resolving symlinks allowed 30 percent (the symlink), and realpath plus commonpath allowed 0 while allowing all 6 legitimate paths. Against 10 URL tricks: "contains good.test" allowed 80 percent, a string-prefix check 30 percent (and wrongly blocked 2 of 3 legitimate URLs), a parsed-host allowlist 0 percent with all legitimate URLs allowed. Against 9 command tricks: startswith("ls") allowed 100 percent, a program-plus-argument allowlist 0.
• Process limits really work, and I ran them. An infinite loop was killed after 1.02 s by a 1 s CPU limit; a 2 GB allocation raised MemoryError under a 256 MB address-space limit; a 50 MB write failed with File too large under a 1 MB limit; a 60 s sleep was stopped by a 5 s wall-clock timeout; and a secret in the parent environment was not visible to a child started with a scrubbed environment but was visible when the environment was inherited.
• Limits are not isolation. A process with CPU and memory limits can still read any file the user can read and open network connections. Resource limits stop denial of service; only a boundary (container, VM, separate user, no network) stops data access. From general knowledge, stronger options are gVisor-style user-space kernels and microVMs such as Firecracker; I did not check these for this module.
• Check-then-use races exist. realpath followed by open can be raced by swapping a symlink in between (TOCTOU). Mitigations: open with O_NOFOLLOW or relative to a directory file descriptor, or run in a sandbox where escaping does nothing. I did not implement this.
• Honest limits: Linux only; small hand-written attack lists; no container, no network isolation, no DNS-rebinding test.