concept

Agent sandbox

An agent sandbox is the isolated execution environment where an LLM-driven agent runs code, browses, or controls a desktop — the safety boundary that contains prompt-injection blast radius.

Production agents need isolation: a code-running agent shouldn't `rm -rf /`, a computer-use agent shouldn't make purchases, a browser agent shouldn't post to private channels. Sandboxes provide that boundary. Common forms: ephemeral Docker containers (E2B, Daytona, Modal), microVMs (Firecracker via Fly Machines), browser sandboxes (Browserbase, Browserless), WebContainers (StackBlitz). The sandbox should be ephemeral (new instance per session), network-restricted (allowlist outbound, no inbound), credential-free (agent shouldn't have prod tokens), time-limited (kill after N minutes), and resource-limited (CPU/memory caps). Without a sandbox, prompt injection from any retrieved content can execute arbitrary actions in your environment.

When to use agent sandbox

Common mistakes

FAQ

What is agent sandbox?

An agent sandbox is the isolated execution environment where an LLM-driven agent runs code, browses, or controls a desktop — the safety boundary that contains prompt-injection blast radius.

When should I use agent sandbox?

Any production agent that runs code or controls a desktop. Browser agents touching authenticated sessions.

What are the most common mistakes with agent sandbox?

Sharing a single sandbox across users — one session's state leaks to the next. Giving sandbox access to prod credentials — defeats the point.

Last updated: 2026-06-01. Raw markdown: https://promtable.com/glossary/agent-sandbox.md.