How should an agent execute code safely? Talk about sandboxing.
- 2 min — threat model: malicious, buggy, injected
- 3 min — isolation tiers with numbers
- 2 min — analysis-agent configuration
- 3 min — credentials via proxy, tenancy, Replit lesson
- 2 min — shared service ownership and build vs buy
Model-written code is untrusted code. Run it in a sandbox with no host credentials, a scratch filesystem, CPU/memory/time limits, and network egress denied or allow-listed; destroy it after the task. Isolation strength comes in three tiers. Containers share the host kernel — fast (~1 s cold start with a cached image), weakest boundary. gVisor puts a user-space kernel between code and host, intercepting syscalls — stronger, with overhead on syscall-heavy work. MicroVMs (Firecracker, built for AWS Lambda; Agache et al., NSDI 2020) give each sandbox its own kernel with ~125 ms boot and under 5 MiB memory overhead per VM — the default for multi-tenant code execution.
The threat isn't only malicious code: it's buggy code (infinite loops, disk fills), and injected code steered by a poisoned input. The July 2025 Replit incident — a coding agent deleted a production database during a declared code freeze — is the canonical example of an agent whose environment let it reach production; Replit's response included automatic separation of development and production databases.
Data-analysis agent for financial-filings uploads: writes Python to parse and chart a user's CSV. Each session gets a Firecracker microVM from a warm pool: 2 vCPU, 2 GB RAM, 60 s per execution, 10 GB scratch disk, the file mounted read-only, no network except an internal PyPI mirror. Outputs return as files and stdout capped at 20k characters. A cell that tries os.environ finds nothing; one that loops forever is killed at 60 s and the model sees “execution timed out after 60 s”.
Match isolation to blast radius: a per-developer local agent on their own repo can use containers; multi-tenant code execution needs microVMs or gVisor and never reuses a sandbox across tenants. Credentials the agent needs are short-lived, scoped, and injected by a proxy outside the sandbox so code never sees the secret. Production systems are unreachable from agent sandboxes by network design, not by instruction. Measure resource-limit hits, egress denials (a spike is an injection signal), and cold-start p95 (target < 500 ms with warm pools).
Org scope. Security sets the isolation standard per risk tier; the platform team runs the sandbox service (warm pools, images, egress proxy) so product teams never build their own. Build vs buy: managed sandbox services (e.g. E2B, Modal) for the first year; self-host Firecracker when volume or data-residency requirements justify a team of 2–3 to run it. Failure mode: “temporary” internet access added for pip install that becomes a permanent exfiltration path — mirror packages instead.
Assumptions: 400 concurrent sessions at peak, 2 GB RAM + 2 vCPU each, CPU oversubscribed 4×. Memory: 800 GB; hosts with 384 GB usable → 3 hosts + 1 spare. CPU: 800 vCPU / 4 = 200 physical vCPU, fits in 4 × 96. Warm pool: 2 new sessions/s × 0.3 s create ≈ 1 in flight; keep 40 warm for bursts. Firecracker overhead (<5 MiB/VM) is negligible at this scale.
What the answer sounds like at each level
Run generated code in an isolated container with no secrets, limited resources and no network.
Chooses between containers, gVisor and microVMs by blast radius, uses warm pools, egress allow-lists, scoped short-lived credentials via a proxy, and per-tenant sandboxes.
Sets an isolation standard per risk tier with security, runs a shared sandbox service, keeps production unreachable by network design, and makes the managed-vs-self-host call.
Follow-ups the interviewer will push
1The agent needs to call an internal API from the sandbox. How?
Through an egress proxy outside the sandbox that holds a short-lived, task-scoped credential and allow-lists that endpoint and method. The code sees a URL, never the token.
2Now 10× concurrent sessions. What do you size?
Memory dominates: VMs × RAM per VM across hosts, warm-pool size from arrival rate × create time, and egress-proxy throughput. Oversubscribe CPU (most sessions are idle between cells), not memory.
3What would have prevented the Replit-style incident?
No production credentials or network path from the agent's environment, dev/prod separation by default, and destructive operations behind human approval regardless of what the agent decides.
Red flags interviewers listen for
- Runs generated code on the application host or a shared long-lived container.
- Gives the sandbox open internet “for package installs”.
- Puts API keys in sandbox environment variables.
How it's scored
| Dimension | What strong looks like |
|---|---|
| Isolation choice | Containers vs gVisor vs microVMs tied to blast radius. |
| Controls | Resource limits, egress allow-list, proxy-held credentials, per-tenant sandboxes. |
| Incident literacy | Uses a real incident to justify network-level separation. |
| Org scope | Security standard, platform-run service, sizing and build vs buy. |
Sources
- Firecracker: Lightweight Virtualization for Serverless Applications — Agache et al. (NSDI '20), 2020paper