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.
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.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
When an agent writes code and a runtime executes it, the executed code is untrusted input. It was generated by a probabilistic model that can be wrong, and it can be steered by anyone who controls part of the model's context. Treating that code as if you wrote it yourself is the central mistake. The sandbox exists to contain it, the same way a browser sandboxes a web page or an operating system isolates an unprivileged user.
There are two independent reasons the code is dangerous. First, the model makes mistakes, so it can emit an infinite loop, a recursive delete pointed at the wrong path, or a fork bomb with no malice at all. Second, prompt injection lets an attacker plant instructions in a document, a web page, or a tool result that the agent later reads, and the agent obediently writes code that serves the attacker. This second source is the one engineers underweight, because it does not look like a bug. The model behaved exactly as designed; it followed instructions. The instructions just happened to come from an attacker.
Because both threats end in the same place, arbitrary code running on your infrastructure, the defense is the same: run it nowhere near anything you care about. The rest of this answer walks through why the obvious shortcut fails, the defensive defaults a real sandbox enforces, the isolation technologies that back them, and where the two popular services land on that spectrum.
Why a bare subprocess is unsafe
The tempting shortcut is to run the generated code with something like subprocess.run(["python", "-c", code]). This is unsafe because a subprocess is not an isolation boundary at all. It inherits the parent's identity and environment almost completely.
The child process runs as the same operating-system user, so it can read and write every file that user can. It inherits environment variables, which on most servers carry database passwords, cloud credentials, and API keys. It shares the host network namespace, so it can reach internal services, metadata endpoints, and the public internet. It sees the same process table and can signal or inspect its neighbors. On a cloud instance it can even hit the link-local metadata endpoint and mint short-lived credentials for the host's role.
Nothing about a subprocess restricts any of this. A single os.system("rm -rf /") or a quiet loop that POSTs your secrets file to an attacker's server executes with your full privileges. People reach for half-measures here, like running the subprocess as a low-privilege user or chrooting it. Those help a little, but they leave the shared kernel, the shared network, and most of the syscall surface intact, so they are not a real boundary either. The lesson is that process separation is about scheduling and accounting, not security. Containment requires a deliberate isolation layer underneath.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- e2b 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.
- Modal executes serverless functions in ephemeral Docker-based containers with read-only base images and per-function CPU, memory, and timeout limits.
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?
Think about side channels: DNS lookups against allowed resolvers, data smuggled into otherwise-allowed API calls, and the returned result itself. Lock DNS, proxy and inspect allowed egress, and treat the sandbox's output payload as untrusted and size-limited.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
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.
60 second bullets to scan on the way to the call.
Explain the two reasons agent code is untrusted, including prompt injection.
List the host resources a bare subprocess exposes to that code.
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.