Why run agent generated code inside an isolated sandbox?

Flashcard·Easy·4.0 · 0·~30s·Asked atMidjourney Persistent Phonepe·Relevant atCursor

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.

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

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

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.

A code sandbox in the agent setting is an isolated execution environment where agent-generated code runs without access to the host system. It is one of the most consequential design choices in a code-executing agent stack, because the moment you let a language model write code that your runtime executes, you are running untrusted code on your infrastructure.

The word 'untrusted' is doing a lot of work in that sentence. It does not mean the model is malicious. It means you cannot rely on the code being safe without verifying it, and verifying generated code in real time is not feasible. Some of the unsafe code comes from honest model mistakes: a wrong path in an rm, an infinite loop, a buggy file write. Most of the dangerous code comes from prompt injection, where an attacker hides instructions inside any content the agent reads (a document, a web page, a database row, even a filename) and steers the model into producing malicious code with your credentials attached.

The rest of this explanation walks through why generated code must be treated as untrusted, the tiers of isolation that defend against it, the four controls every real sandbox layers on top of isolation, and the production services that bundle the whole thing together.

Why generated code is untrusted by construction

Two threats need to be named separately, because conflating them leads to weak defences.

The first is accidental. Language models hallucinate destructive commands at a non-zero rate. Even a well-aligned model occasionally writes rm -rf /tmp/data/* against the wrong path, opens a file in write mode instead of append, or produces a loop with no exit condition. These bugs are routine, not exotic. The cure for them, if you are running the code in production, is to make the blast radius small enough that a bug damages nothing important.

The second threat is deliberate. Prompt injection embeds instructions in any text the agent reads: a help-desk ticket, a web page, a row in a database, a code comment, a filename, an OCR'd PDF. The model treats those instructions as part of its working brief and can be steered into writing code that exfiltrates secrets, calls internal services with the agent's credentials, or installs a backdoor. The OWASP Top 10 for LLM Applications ranks prompt injection as the number-one risk to LLM systems for exactly this reason.

What makes the agent setting dangerous is the combination of injection plus tool authority. A chat model that only emits text can be tricked but cannot do much damage. An agent that executes code with credentials can do almost anything the credentials allow. Detection-based defences (scanning the generated code for suspicious strings) are trivially bypassed with obfuscation, so the load-bearing control has to be isolation.

Tiers of isolation from weakest to strongest

The four controls layered on top of isolation

Production sandbox services and how to pick one

Situations where this technique stops working.

2–4 min · Everything important, quickly.

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.

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?

Compare the boundary. A container shares the host kernel, so one kernel exploit escapes to the host. A MicroVM gives each run a separate guest kernel behind a hardware-virtualisation boundary, raising the cost of escape sharply at the price of slower startup, which warm pools largely hide.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases 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.

60 second bullets to scan on the way to the call.

Define a sandbox as an isolated runtime for agent-generated code.
State why generated code is untrusted by construction (bugs and prompt injection).

Primary sources. Browse if you want the original framing.