Why must agent-generated code execute in an isolated sandbox, and what are e2b and Modal's isolation models?

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.