# Most teams sandbox agent code in containers. LangChain argues you do not need to

Most teams run agent-generated code inside a container and call it sandboxed.

LangChain made a different argument on June 30, 2026. You can run untrusted agent code safely without a container at all.

The container model hands an agent a broad world and then tries to wall it off.

That is backwards. You are subtracting danger from a powerful default, and you only find the hole you forgot about after something falls through it.

The piece names three requirements instead: • Execution isolation: the code runs in a WebAssembly VM with its own memory, using QuickJS compiled to WASM, so the trusted surface stays tiny • Capability isolation: the interpreter starts with nothing, no filesystem, no network, no dependencies, and the harness bridges in only the narrow functions the task needs • Durable pauses: execution serializes to LangGraph state and can stop for human approval, then resume seconds or days later without losing its place

The middle one is the real shift.

A container is deny-list security. You grant a broad world, then chase down everything to forbid.

Capability isolation is allow-list security. You grant nothing, then hand over exactly what the job requires.

Every serious sandbox escape lives in the gap between what you meant to forbid and what you remembered to.

Allow-lists do not have that gap. There is nothing in the box you did not put there.

The full argument is here: https://www.langchain.com/blog/running-untrusted-agent-code-without-a-sandbox

A sandbox asks what an agent must not touch.

Capability isolation asks what it may.