Why run agent-generated code inside an isolated sandbox?

Attempt it

A sandbox is an isolated runtime (container, gVisor, or Firecracker MicroVM) that executes agent-generated code without access to the host filesystem or network. It is required because the LLM can produce malicious or accidentally destructive code (rm -rf, exfiltration, infinite loops), often via prompt injection. Production options include e2b Cloud Sandbox, Modal, Daytona, and Pyodide-in-browser; each run gets a fresh ephemeral environment.

Your answer

When an agent writes Python or shell code and your runtime executes it, that code is **untrusted**. The model wrote it, not a reviewed developer. The model can make mistakes and it can be tricked by hidden instructions in any document or page it reads, a problem known as prompt injection. If you run that code directly on your server, it can read your secret keys, delete your files, or call out to the open internet. A single bad line could leak everything your service knows. A sandbox is an isolated place where the code runs with almost nothing around it. There is no access to the host filesystem, no network by default, and a strict cap on CPU, memory, and wall-clock time. When the task is finished the sandbox is destroyed, so nothing left behind can affect the next run. The simplest sandbox is a container, but containers share the host kernel and a kernel exploit escapes them. Stronger options are gVisor (which puts a user-space kernel in front of the host) and Firecracker MicroVMs (which give each run a separate guest kernel). Production services like **e2b Cloud Sandbox**, Modal, and Daytona are built on those stronger layers. Pyodide runs Python inside a browser WASM sandbox for client-side cases.

A **sandbox** is an isolated runtime that executes agent-generated code without giving it access to the host system. It is required because every line of code an agent produces is untrusted by construction: the model can hallucinate destructive commands, and a prompt-injection payload in any document the agent reads can deliberately steer the code into exfiltrating secrets or attacking internal services. Isolation comes in tiers. A plain container is the weakest sandbox because it shares the host kernel, and a single kernel-level exploit reaches the host. gVisor adds a userspace kernel that intercepts most syscalls. Firecracker MicroVMs give each execution a separate guest kernel behind a hardware boundary, which is the standard production choice. The cost of stronger isolation is slower cold start, partially hidden by warm pools. Four controls define a good sandbox beyond the isolation tier. No host filesystem mount, so secrets and source stay out of reach. Default-deny network egress with a per-task allowlist, so exfiltration has no path out. Hard caps on CPU, memory, disk, and time, to stop runaway loops. Ephemerality, so the environment is destroyed after the task and never carries state forward. Production services include **e2b Cloud Sandbox**, Modal, and Daytona for server-side execution, and Pyodide for in-browser Python.

Quick reference

TL;DR

A sandbox is an isolated runtime (container, gVisor, or Firecracker MicroVM) that runs agent-generated code with no host filesystem or network access, used because the LLM can produce buggy or attacker-steered code.

Memory aid

Sign in for the mnemonic that makes this stick. See Pro pricing.

Easy to grasp

Imagine an apprentice cook who is allowed to invent new recipes on the fly. Most of the time the recipes are fine. Once in a while the apprentice writes a recipe that says 'pour gasoline into the broth'. You would not let the apprentice cook in your main kitchen with access to every shelf, the gas line, and the customer's fridge. You give them a small isolated kitchen with only the ingredients for one dish, sealed off from the rest of the building, and you throw the kitchen away after the dish is done. A code sandbox is that small isolated kitchen for an agent. The code runs, but inside walls so thick that a bad recipe cannot reach anything real.

Key concepts

Code Execution Sandbox Isolation Prompt Injection

Detailed answer & concept explanation

~7 min read

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.

Sign in for 5 free unlocks/day or go Pro for unlimited. See Pro pricing.

Quick scan · 2–4 min

Everything important, quickly.

Open by saying agent-generated code is untrusted by construction, because of bugs and prompt injection. Rank container vs gVisor vs MicroVM isolation. Name the four controls: no host filesystem, default-deny network, resource caps, ephemerality. Close on blast-radius reduction under least privilege, not on trusting the code.

Real-world examples

Real products, models, and research that use this idea.

e2b Cloud Sandbox runs agent-generated Python in Firecracker MicroVMs, with a per-session ephemeral filesystem and configurable egress allowlists.
Modal executes untrusted agent code in serverless gVisor-backed containers with per-run resource caps and default-deny network egress.
Daytona offers dev-environment sandboxes that agents can use as isolated workspaces for code generation and test runs.
OpenAI's Code Interpreter and Advanced Data Analysis tools run Python in a network-disabled sandbox so generated code cannot reach the internet or host services.
Pyodide runs Python entirely inside a browser WASM sandbox for client-side agent code without ever sending the code to a backend.

Interviewer follow-ups

What an interviewer would ask next. Try answering before peeking at the approach.

QA container and a Firecracker MicroVM both isolate processes. Why prefer the MicroVM for arbitrary agent code?

Sign in or go Pro to see the approach for this follow-up.

QThe agent's task genuinely needs to fetch a Python package from PyPI. How do you allow that without opening the internet?

Sign in or go Pro to see the approach for this follow-up.

QHow would you detect that a sandboxed run was actually compromised by injection?

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

Thinking a plain Docker container is a sandbox. A container shares the host kernel, so a kernel exploit escapes. Real agent sandboxes use gVisor or microVMs, default-deny networking, and ephemeral teardown.

Sign in or go Pro to see all red flags and common mistakes. See Pro pricing.

60-second cheat sheet

The night-before-the-interview bullets. Scan these on the way to the call.

Sign in for 5 unlocks/day or go Pro for unlimited revision sheets. See Pro pricing.

References

Primary sources. Skim if you want the original framing.