Sandboxing
Running an agent where it can't do damage — the only agent safety measure that doesn't depend on the model behaving.
Reviewed July 12, 2026Stable
When not to use it
- (There isn't a case for skipping it. The question is how much capability fits inside.)*
- A read-only sandbox, when the agent must act. Safe and useless is also a failure.
- A container, when running genuinely hostile code. Containers are isolation, not a security boundary against escape.
- Sandboxing alone, with a hostile tool. Containing the agent doesn't help if the MCP server is the problem.
Reach for something else instead
- (Complements, not substitutes.)*
- Capability restriction — don't grant it. The sandbox's cheapest layer.
- Human confirmation at the boundary — where actions leave the sandbox.
- microVMs (Firecracker, gVisor) — when a container isn't a strong enough boundary.
- Tool emulation — test what the agent would do without letting it.
Read more on the blog
- How to secure an LLM application: risks and defensesTraditional security rests on a boundary between instructions and data. A language model has no such boundary, because both arrive as one stream of text it cannot tell apart. That single fact determines every defense that works, and every one that does not.
- Why AI agents fail: the seven failure modesGartner predicts over 40% of agentic AI projects will be canceled by 2027. The failures follow patterns, seven of them. The taxonomy: what breaks, why, which real incident proved it, and which control would have prevented it.
- What is prompt injection, and why is it unsolved?Prompt injection is the number one security risk for AI applications, and researchers treat it as unsolved: not a bug waiting for a patch, but an architectural flaw in how language models work. Here is why a model cannot reliably tell instructions from data, why that makes AI agents dangerous, and what actually reduces the risk.
Further reading
- Greshake et al. (2023), Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection — why the threat model has to assume compromise.
- Ruan et al. (2023), Identifying the Risks of LM Agents with an LM-Emulated Sandbox — ToolEmu; finding agent failures by emulating the tools.
- Agarwal et al. (2020), Firecracker: Lightweight Virtualization for Serverless Applications — microVMs; what a real isolation boundary costs.
Primary sources, listed so you can check the claims on this page rather than take them on trust.
Where people go wrong
- Relying on a system prompt to prevent an action the agent is capable of. That's a request, not a boundary.
- Skipping egress filtering. An agent that can reach any URL can send your data to any URL.
- Treating a container as a security boundary against determined escape. It isn't; microVMs are.
- Persisting state between tasks, so a compromise persists too.
- Designing capability first and containment afterwards. It's the wrong order and it doesn't get revisited.
At a glance
FieldAI Agents
Why it's differentit changes what's possible, not what's likely
Threat modelassume prompt injection succeeded
Cheapest layerread-only, scoped, short-lived credentials
Most skippedegress filtering
In tension withthe entire product direction
DifficultyIntermediate
Often compared with
Sandboxing vs. guardrails — guardrails ask the model not to; sandboxing removes the option. Only one of them survives a compromised model.
Where this sits
A destination. 26 concepts lead here, and nothing in the corpus depends on it.
13Levelsteps in
26Needs firstconcepts
0Opens upnothing further
1Areastays here
Learn these firstTool Use
Computed from the prerequisite graph, not assigned. How this works