Explain why agent-generated code must run in an isolated sandbox rather than directly on the host. Describe how e2b and Modal achieve isolation differently.
Free · 2 AI evals / day
When an agent writes and runs code, that code is **untrusted**. The model might make a mistake, like an infinite loop or a delete command pointed at the wrong folder. Worse, an attacker can use prompt injection to slip malicious instructions into the agent's input, and the agent then writes code that does what the attacker wanted.
If you run that code directly on your host machine, it can read your files, steal credentials and API keys, contact the internet, and damage other running processes. A bare subprocess like Python's `subprocess.run` does almost nothing to stop this. It shares your filesystem, your network, and your user permissions.
A sandbox is an isolated, throwaway environment built for exactly this. The code runs with no access to the host, no network by default, a fresh empty filesystem, and hard limits on CPU, memory, and time. When the run finishes, the whole environment is destroyed.
Two popular services do this. e2b runs each execution inside a tiny virtual machine with its own kernel. Modal runs each execution inside a fresh container. Both are ephemeral, so nothing the code did survives.
Agent-generated code is **untrusted code** and must run in an isolated, disposable sandbox. There are two threat sources. The model can write harmful code by accident, like a bad delete or an infinite loop. An attacker can also use prompt injection to make the agent emit malicious code on purpose.
Run that on the host and the code inherits your filesystem, your credentials, your network, and your processes. A bare subprocess shares all of these, so it is never a security boundary. The fix is a sandbox with strong defaults. Deny the host filesystem. Deny network unless an egress allowlist opens specific destinations. Use an ephemeral filesystem wiped after each run. Add hard CPU, memory, and time limits. A seccomp profile restricts which syscalls the code may even attempt.
The isolation technology then sets the perimeter. e2b runs each execution in a Firecracker microVM with a separate guest kernel, so a kernel exploit cannot reach the host. Modal runs each execution in an ephemeral Docker-based container that shares the host kernel. Containers are lighter and start faster. But the shared kernel means a kernel-level container escape is a real, if rare, risk. That is the core tradeoff. VM-level isolation buys a stronger perimeter at some cost in startup latency.
Quick reference
TL;DR
Agent code is untrusted, so it must run in a throwaway sandbox with no host access, no default network, and CPU, memory, and time limits, never a bare subprocess.
Imagine you hire a stranger to test recipes in your house. You would not hand them keys to every room, your wallet, and the front door. You would put them in a rented kitchen with a timer, basic ingredients, and a locked door, then throw the kitchen away when they leave. Agent-generated code is that stranger. The model might write something harmful by accident, or someone might trick it into writing something nasty. So you run the code in a disposable box that has no path to your real files, no money or passwords lying around, and a clock that shuts it off. If the code misbehaves, only the rented box is wrecked, and you delete it anyway. Your real machine never even saw the stranger.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
The agent only emits code from a fixed, audited template with no free-form model-written logic. If every executed line is reviewed and pinned, the untrusted-input threat that justifies a sandbox is largely absent.
Tens of thousands of tiny executions per second under a tight latency budget. Per-run microVM boot can dominate latency, so a warm pooled or pre-snapshotted approach may be needed instead.
The code only needs pure computation with no system calls, file, or network access at all. A restricted in-process interpreter with a denylist can suffice when there is no host surface to attack.
A fully air-gapped, single-tenant machine that already runs nothing else of value. If the host has no secrets, no network, and is itself disposable, the blast radius is already contained.
Quick scan · 2–4 min
Everything important, quickly.
Open with why agent code is untrusted (model mistakes plus prompt injection), state that a bare subprocess inherits the host so it is no boundary, lay out the defense in depth defaults (no network plus egress allowlist, ephemeral filesystem, CPU, memory, and time limits, seccomp), then contrast container, gVisor, and microVM isolation and place e2b and Modal on that spectrum with the latency tradeoff.
Real-world examples
Real products, models, and research that use this idea.
1e2b runs each agent code execution in a Firecracker microVM, giving every run a separate guest kernel and an ephemeral filesystem that is torn down afterward.
2Modal executes serverless functions in ephemeral Docker-based containers with read-only base images and per-function CPU, memory, and timeout limits.
3OpenAI's Code Interpreter, now the ChatGPT data analysis tool, runs model-generated Python in a network-disabled sandbox with a disposable filesystem.
4Google uses gVisor to add a user-space kernel layer in front of containers running untrusted workloads, shrinking the host syscall attack surface.
5Anthropic's Claude Code and computer use deployments emphasize running agent-driven actions inside isolated environments rather than directly on a developer's host.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QAn attacker injects code that must phone home to exfiltrate data, but you run a no-network sandbox with an egress allowlist. What are the remaining exfiltration paths and how do you close them?
Sign in or go Pro to see the approach for this follow-up.
QWhy is a Firecracker microVM considered a stronger boundary than a hardened container with seccomp, gVisor, and dropped capabilities?
Sign in or go Pro to see the approach for this follow-up.
QHow would you design a sandbox pool that keeps per-execution isolation but avoids paying full microVM boot latency on every request?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Treating a sandbox as a feature for catching bugs rather than a security boundary. The real job is containing untrusted code, including code an attacker injected, not just stopping accidental crashes.