When an agent writes code and your runtime runs it, that code is **untrusted** by default. It was not written by a reviewed developer. It came out of a language model that can make mistakes or be tricked by text it reads along the way.
Two things can go wrong. The model can simply write buggy code that deletes the wrong files or runs forever. Worse, an attacker can hide instructions inside a document or web page the agent reads, a trick called prompt injection, and steer the model into writing malicious code on purpose.
If that code runs directly on your server, it inherits everything that server can touch: your files, your API keys, your database, the open internet. A single bad line could leak secrets or wipe data.
The fix is a **sandbox**. The agent's code runs inside an isolated container or tiny virtual machine that has no access to the host filesystem, no network unless you grant it, and strict limits on memory and time. When the task ends, the sandbox is thrown away, so nothing lingers between runs.
Agent-generated code is **untrusted** by construction. It is produced by a model that can hallucinate destructive commands, and it can be steered by prompt injection hidden in any content the agent reads. So you must assume it is hostile and contain it.
A sandbox isolates execution from the host. Isolation comes in tiers. A plain container shares the host kernel, which is weak against a kernel exploit. Stronger options add a syscall filter like gVisor, or a microVM like Firecracker, which gives each run its own guest kernel and a hardware boundary.
Four controls define a good sandbox. No host filesystem mount, so secrets and source stay out of reach. No network by default, opened only to explicit allowlisted endpoints. Hard resource caps on CPU, memory, disk, and wall-clock time. An ephemeral lifetime, so the environment is destroyed after each task and never carries state forward.
The framing is defensive. You are not trying to make the agent trustworthy. You are shrinking the blast radius so that a bug or a successful injection cannot reach anything that matters.
Quick reference
TL;DR
Agent-generated code is untrusted, so it runs in an isolated sandbox with no host filesystem or network access, capped resources, and an ephemeral lifetime to contain bugs and injected attacks.
Imagine you hire a brilliant but easily-tricked assistant to run errands using your house keys. Most of the time they help, but a con artist could slip them a note that says 'grab the owner's wallet and mail it to me', and they might just do it. You would not hand them the master keys to your home, your bank, and your car. Instead you put them in a small rented room with only the supplies they need for one task, no phone, and a locked door. When the errand is done you clear the room out. A code sandbox is that rented room for an agent. The agent can run whatever code it writes, but inside a sealed box with no real keys, so a mistake or a trick cannot reach your actual house.
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 generates code for a human to read and review before any execution happens. If nothing runs automatically, there is no untrusted execution to contain at run time.
The generated code is restricted to a safe domain-specific language with no system access. A constrained interpreter with no filesystem or network primitives already bounds what code can do.
Latency budgets that cannot absorb microVM cold starts on every single call. MicroVM boot adds startup time, so warm pools or lighter isolation may be needed instead.
Fully offline, air-gapped systems with no secrets and no reachable network. With nothing valuable to exfiltrate and no egress path, the exfiltration threat shrinks sharply.
Quick scan · 2–4 min
Everything important, quickly.
Open by stating agent code is untrusted by construction, then explain prompt injection as the confused-deputy escalation. Rank container vs gVisor vs microVM isolation, then list the four controls: no host filesystem, default-deny network, resource caps, ephemerality. Close on blast-radius reduction under least privilege rather than trusting the code.
Real-world examples
Real products, models, and research that use this idea.
1e2b runs agent-generated code in Firecracker microVMs, giving each session its own guest kernel and a hardware isolation boundary that a shared-kernel container cannot match.
2Modal executes untrusted agent code in serverless gVisor-backed containers with per-run resource caps and no default network egress.
3OpenAI's Code Interpreter (now Advanced Data Analysis) runs Python in a network-disabled sandbox so generated code cannot reach the internet or host services.
4Anthropic's code execution tool for Claude runs model-written code in an isolated container scoped to a single session and torn down afterward.
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 untrusted agent code?
Sign in or go Pro to see the approach for this follow-up.
QThe sandbox blocks the filesystem but the agent still needs to fetch a package from the internet. How do you allow that safely?
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 an injection attack?
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 the threat as only model bugs. The bigger risk is prompt injection turning the agent into a confused deputy that runs an attacker's commands with your credentials.