When to reach for it
- Agents execute code, shell commands, or browser actions.
- Untrusted inputs are processed.
- Side effects must be contained.
Sandbox Execution.
Run code where it can't escape.
Model-generated or agent-selected code runs in an isolated environment — a container, a microVM (e.g. Firecracker), or a hosted code sandbox — with no access to the host filesystem, network, or credentials beyond what the task explicitly needs.
In practiceA data-analysis agent executes user-supplied Python snippets inside a gVisor container, so a malicious script cannot read the host filesystem.
Without itWithout a sandbox, model-generated code runs with the agent's full host permissions, turning a prompt-injection into an arbitrary code execution path. See the anti-pattern →
When it backfires
- No dynamic execution occurs.
- Sandbox escapes cannot be controlled.
- External actions are better handled via verified tools.
The tradeoff
Secure execution is achieved against infrastructure and performance overhead.
What it actually does.
Untrusted code runs inside an isolating sandbox.
Two ways this pattern will hurt you.
Sandbox escapes via side-channel tool calls
The sandbox blocks file access, but the generated code uses a web-request tool to exfiltrate data.
Fix · Audit the tool set available inside the sandbox. Remove network-facing tools unless explicitly required and monitored.
Resource exhaustion
A runaway loop inside the sandbox consumes all CPU or memory. The host process degrades or crashes.
Fix · Enforce cgroup limits on CPU, memory, and wall-clock time. Kill the sandbox when any limit is exceeded.
Where Sandbox Execution is native.
Microsoft Agent Frameworkhosted code interpreterNative
Next pattern