What must a sandbox provide before an agent may run model-written code?

## Why the sandbox is a separate wall Giving an agent the ability to write and run code is enormously useful — it turns a fixed tool list into a general capability. It is also the point where a hijacked agent gets to execute arbitrary instructions rather than pick from a menu. Scoping cannot help you here: the whole point of a code tool is that its argument is unbounded. So the containment must come from the environment the code runs in, and the design assumption must be that the code is hostile. The sandbox is deliberately independent of the other walls. If the tool scope holds, the sandbox is redundant; if the scope is bypassed, the sandbox is what remains. Independence is the property that makes layering worth anything. ## The isolation boundary Running model-written code as a subprocess of your application is not sandboxing — it shares the filesystem, the environment variables, the network position and the process credentials of the service that spawned it. A stock container is better but still shares the host kernel, so a kernel exploit or a misconfigured mount escapes it. The practical bar in 2026 is a microVM (Firecracker-style) or a hardened container runtime that interposes on syscalls (gVisor-style), with a seccomp profile narrowing the syscall surface further, non-root execution, and a read-only root filesystem plus a small ephemeral writable layer. The exact technology matters less than the property: a compromise of the guest should not yield the host. ## Removing ambient authority Most real damage from code execution comes not from the code itself but from what the environment hands it for free: - **Environment secrets.** API keys and database URLs in the process environment are readable by anything running there. The sandbox should carry none. - **Mounted credentials.** A service-account token file mounted into the container is a credential the code can read and reuse. - **The instance metadata endpoint.** On major clouds, code running on an instance can request short-lived credentials for that instance's role from a link-local address (169.254.169.254). Blocking it is one of the highest-value single controls for any sandbox. - **Host mounts.** A bind mount for convenience — source code, a shared cache — is a path in and a path out. Copy data in explicitly instead. After this, the sandbox's power equals the data you deliberately put in it, which is the property you want. ## Default-deny egress Network policy is where most sandboxes are quietly wide open. The default in container platforms is usually unrestricted outbound traffic, which means model-written code can reach your internal services, other tenants' endpoints and any host on the internet. Default-deny with an explicit allowlist inverts that: nothing leaves unless a rule names it, DNS is served by a resolver you control so the allowlist cannot be evaded by name, and requests go through a proxy that logs what was attempted. The allowlist should be as small as the workload permits — a package index if the sandbox installs dependencies, one or two APIs the task genuinely needs. Every entry is a channel, and channels are where data leaves. ## Resource and lifetime limits Caps on CPU shares, memory, wall-clock time, process count and disk turn a runaway or deliberately abusive workload into a killed job rather than an outage for everything sharing the host. Pair them with a strict lifetime: one sandbox per session or per task, destroyed afterwards, so nothing an attacker plants survives to the next run. Persistent sandboxes accumulate state, and accumulated state is a foothold. ## What good failure looks like When the sandbox does its job, a hijacked agent's code run ends as a killed process with a denied network attempt in the proxy log and no credential ever readable. That is also the signal to alert on: denied egress from a sandbox is nearly always either a broken task or an attack, and both deserve a look. ## Common shortcuts and what they cost Teams frequently ship a plain container on the app host with default networking, because it is a two-line change and the demo works. The cost is that arbitrary code now runs inside the trust boundary of the service, with its environment, its network position and its instance role. The second common shortcut is a long-lived shared sandbox reused across users, which turns any successful plant into a cross-user compromise. ## Answering this in an interview Say the assumption out loud — treat the code as hostile — then list the properties in order of leverage: real isolation boundary, no ambient credentials or metadata access, no host mounts, default-deny egress, resource caps, ephemeral lifetime. Naming the metadata endpoint and default-deny egress specifically is what distinguishes an answer that has run this in production.