llm-code-execution-sandboxing
verifiedb6388a80-ce6e-4cad-be0c-16b413369562
Safely execute LLM-generated code — pick the right isolation (Firecracker microVMs, gVisor, Docker, firejail), configure timeouts and resource limits, and avoid the 45% of AI-generated code that fails security tests.
Metadata
Skill file
# LLM Code Execution Sandboxing
Use when your agent or app takes LLM-generated code and runs it — code
interpreters, data-analysis agents, coding assistants, self-modifying scripts. A 2025
Veracode report found 45% of AI-generated code fails security tests; this is not a
corner case, it is the default. The sandbox is your only real safety boundary.
## The isolation spectrum (weakest → strongest)
**No isolation — subprocess with restricted builtins.** `exec()` or `subprocess.run()`
in the same Python process, maybe with `restrictedpython`. Provides zero security
(the model can escape via `__import__` or file descriptors) but zero overhead. Only
acceptable when: the model *and* every user is fully trusted, which is effectively
never in production.
**OS-level sandboxes — firejail, bubblewrap (bwrap).** Linux namespace isolation:
filesystem, network, PID, user namespaces. Blocks most accidental harm
(`rm -rf /` becomes `rm -rf` in a private namespace) but not a determined escape
via kernel vulns. Useful for development and non-adversarial workloads. Bubblewrap is
the container runtime under Flatpak; firejail is battle-tested.
**Container isolation — Docker, containerd, gVisor.** Each execution gets a
container with its own filesystem, no host mounts, no cap-adds, limited CPU/memory.
gVisor (user-space kernel) adds an extra syscall filtering layer that catches many
kernel-level escapes. Modal uses gVisor containers for sandboxed AI code execution.
Good for production with moderate security requirements.
**MicroVM isolation — Firecracker (AWS Lambda/Fargate).** Each execution gets its
own kernel in a lightweight VM (boots ~125ms). Hardware-level isolation via KVM — a
VM escape is vastly harder than a container escape. E2B is the most popular
Firecracker-based sandbox explicitly built for AI agents; roughly 50% of Fortune 500
companies use Firecracker-based isolation for AI agent workloads. This is the
production gold standard. The tradeoff: higher per-execution overhead (~125ms cold
start vs ~5ms for a container), and you usually need a cloud service or KVM-capable
host.
## What every sandbox must enforce (minimum viable)
- **Filesystem**: no host mount. Ephemeral writeable `/tmp` and a workspace dir.
Read-only everywhere else.
- **Network**: default-deny egress. If the task needs PyPI, whitelist only
`pypi.org` and `files.pythonhosted.org` (and pin versions to avoid dependency
confusion).
- **Resource limits**: memory ceiling (OOM kill), CPU quota, and an absolute wall-clock
timeout (30s-300s depending on task). No timeout = unbounded billing.
- **Process scope**: one process tree per execution; no shared PID namespace.
- **Tear down**: the sandbox must be destroyed after execution, never reused across
users or sessions. Ephemeral means ephemeral.
## E2B in practice (Python SDK)
```
from e2b import Sandbox
with Sandbox() as sandbox: # creates Firecracker microVM
execution = sandbox.run_code(code, timeout=30)
print(execution.text) # stdout
print(execution.logs.stdout) # all stdout lines
print(execution.error) # stderr + exit code
```
## Additional layers (defense-in-depth)
The sandbox is your bottom layer. Add, above it:
- **Static analysis** — scan LLM output for `os.system`, `subprocess`, `eval`,
`__import__` patterns before execution. Reject dangerous constructs.
- **Rate limiting** — per-user execution caps to prevent resource exhaustion.
- **Audit logging** — record every code block + execution result for post-hoc review.
## Pitfalls
- `subprocess.run()` in the same process as the agent's orchestrator — one `os.system("rm -rf /")` and your orchestrator is gone.
- Mounting host directories into the sandbox "for convenience" — defeats the entire
isolation model.
- No timeout — a `while True` loop burns resources indefinitely.
- Allowing unrestricted network egress — the model can exfiltrate data or scan
internal services.
- Reusing sandboxes across users — cross-user data leakage becomes trivial.
## Verify
- Execute a test payload that tries to read `/etc/shadow`, write to `/`, open a
network connection to an external IP, and fork-bomb. All must fail in the sandbox
and succeed in an unsandboxed control.
- Measure sandbox boot + execution latency; confirm it fits your SLO.
- Check resource enforcement: a memory-hungry process must be killed, a timeout must
fire.Attached files
No attached files.