Design a Code Execution Sandbox

Where an interviewer pokes next

Getting the boxes right is the easy half. These are the questions that separate a candidate who drew the diagram from one who has run the thing. Answer each one out loud before you open it.

Show all answers

1. 01

   Why is running untrusted code directly in your service a full compromise, not just a bug risk?

   Show the answer

   Because code executed inside your process or on your host inherits that context's privileges, environment, and access, so untrusted code effectively becomes you. It can read environment variables and secrets the service holds, touch the filesystem and thereby other users' data, open network connections to internal systems that trust your service's network position, consume all the CPU and memory on the machine, and generally do anything your service is permitted to do. That is the textbook definition of arbitrary code execution on your own infrastructure, which is the most severe class of security failure — the attacker isn't exploiting a narrow flaw, they're simply running whatever they want with your permissions. And the code genuinely is untrusted: LLM-generated code can be wrong or manipulated via prompt injection into doing something harmful, and user submissions to a judge or notebook can be deliberately adversarial. The consequence is that you cannot make this safe by inspecting or sanitizing the code, because you can't reliably analyze arbitrary programs and malicious ones hide intent; the only viable approach is to contain execution so that even fully malicious code has no ambient access to anything valuable — which is exactly what a sandbox provides.

2. 02

   Isolation vs resource limits — why do you need both?

   Show the answer

   They defend against two different attack surfaces, and either alone leaves you exposed. Isolation controls what the code can reach: it prevents untrusted code from accessing the host, the network, secrets, the filesystem, and other runs, by executing it inside a hardened container or microVM with restricted syscalls, dropped privileges, and no ambient access. But even perfectly isolated code that can't reach anything external can still harm you by consuming resources: an infinite loop pins a CPU forever, a runaway allocation exhausts memory, a fork bomb spawns processes until the scheduler collapses, and unbounded disk writes fill the volume — any of which crashes or starves the worker and every co-located run, a denial-of-service against the fleet. Resource limits control how much the code can consume: per-run quotas on CPU, memory, wall-clock time, process/thread count, and disk, enforced via cgroups and ulimits (or the microVM's allocation), with a hard kill for anything that exceeds its budget. So isolation contains the blast radius of what code can touch, and limits contain the blast radius of what it can consume; a secure sandbox needs both, because untrusted code can attack through reach or through exhaustion.

3. 03

   Containers vs microVMs for isolating untrusted code — what's the tradeoff?

   Show the answer

   Both run the code in an isolated environment, but they differ in the strength of the boundary and their startup cost. A container shares the host's kernel and isolates via namespaces and cgroups, which is lightweight and fast but means a single kernel vulnerability can become a container escape to the host; you harden this substantially with syscall filtering (seccomp), user namespaces, and runtimes like gVisor that interpose a user-space kernel to shrink the attack surface, but the shared-kernel model remains a theoretical weak point. A microVM (such as Firecracker) instead boots a tiny, minimal guest kernel inside a lightweight virtual machine, giving you near-full-VM isolation — the untrusted code runs against its own kernel behind a hardware-virtualization boundary — while still starting in milliseconds and using little memory, unlike traditional heavyweight VMs. The tradeoff is that microVMs add a bit more overhead and operational complexity than bare containers, in exchange for a materially stronger isolation boundary. In practice, high-risk multi-tenant execution of untrusted code (exactly the AI-agent and online-judge case) leans toward microVMs for that stronger boundary, and both approaches are combined with least privilege, no network by default, and defense in depth so no single weakness breaches the host.

4. 04

   Why must sandboxes be ephemeral, and how do you still support stateful sessions?

   Show the answer

   Ephemerality guarantees isolation across time, not just at a single moment. If a sandbox were reused across untrusted runs without being fully reset, one run could leave behind artifacts that compromise the next — malware or a modified interpreter, background processes, poisoned files or installed packages, or subtle state — turning a shared environment into a channel for one tenant to attack another. Manually cleaning a reused environment is error-prone and can't reliably erase everything (kernel state, lingering processes, cached data), so the safe default is to give every run a fresh sandbox and destroy it afterward: a clean environment in, a discarded environment out, which makes cross-run and cross-tenant contamination impossible by construction. For workflows that genuinely need continuity — an agent iterating on code across several steps, or a notebook where later cells depend on earlier ones — you don't abandon this; instead you scope persistence to a single trust boundary by keeping a per-session sandbox that lives only for that one user's session, remains fully isolated and resource-limited throughout, and is torn down and wiped when the session ends. So state is allowed, but only within one user's isolated, disposable session, never reused across different untrusted callers.

5. 05

   Why is controlling network egress so important, and how do you handle code that legitimately needs the network?

   Show the answer

   Network egress is the primary channel for data exfiltration, so leaving it open undermines much of your isolation. Even if code can't escape the sandbox, if it can freely reach the internet it can send out anything it managed to read or compute — and for LLM-generated code that may have been steered by prompt injection, or for adversarial submissions, uncontrolled outbound access also enables attacks on internal systems, participation in DoS, or crypto-mining. So the default must be deny-all egress: the sandbox has no network unless explicitly granted. The challenge is that real workloads sometimes legitimately need external resources — installing a package, fetching a dataset, calling an allowed API — and the wrong fix is to open the internet. Instead you provide controlled paths: route any needed access through an allowlist or an egress proxy that permits only specific, vetted destinations; serve package installs from a vetted internal mirror rather than the open registry; and mount required input data into the sandbox as read-only rather than having the code fetch it over the network. This way the code gets exactly the access it needs through channels you audit and constrain, while arbitrary outbound traffic — the exfiltration and abuse vector — stays blocked. Combined with rate limits, quotas, monitoring, and defense-in-depth against escapes, egress control is a core part of keeping untrusted execution contained.