LangChain: How to Run Untrusted Agent Code Without an External Sandbox

Running code generated by an AI agent has always carried inherent security risk: what if the agent, manipulated through prompt injection, generates malicious code? The conventional solution has been external sandboxes — separate processes, Docker containers, or virtual machines. Hunter Lovell from the LangChain team now proposes a more elegant solution: run untrusted agent code inside the process, but behind a hard memory boundary.

Why Classic Approaches Are Not Enough

External sandboxes solve the isolation problem but bring their own complications: inter-process communication latency, complex lifecycle management, and — particularly painful for agents — the inability to naturally preserve state between steps that require human approval.

Lovell’s technique rests on a key insight: WebAssembly (WASM) provides sufficient boundary isolation within a single process, without an external container. AWS, Shopify, and Figma already use WASM boundaries for similar purposes in production environments.

Three Security Pillars of This Architecture

Lovell defines three conditions that any system for executing untrusted agent code must satisfy:

Execution isolation. Agent code must not be able to compromise the host system. WASM achieves this through its own linear memory space — a sandboxed in-process VM that cannot read or write outside its allocated region. The runtime enforces memory and execution boundaries at the architectural level, without relying on the discipline of the code being executed.

Capability isolation. The agent receives no access to the file system, network, or external dependencies by default. All capabilities must be explicitly bridged through the harness with narrow contracts. This implements the principle of least privilege at the architectural level — the agent can only do what has been programmatically authorized, nothing more.

Stateful pauses. Execution must be able to stop and wait for human approval, then resume without losing context. Lovell solves this by serializing the interpreter’s linear memory space into LangGraph state — a snapshot that is stored and from which the program can continue exactly where it left off.

Choosing QuickJS for Orchestration

Among all available JavaScript engines, LangChain chose QuickJS — a small, fast, ECMA-compliant runtime written in C. The reason is threefold: it compiles cleanly to WASM (meaning the engine itself sits behind the boundary, not alongside it), it is sufficiently expressive for orchestration scripts, and it requires no compilation step for short programs — eliminating startup latency when launching agent scripts.

In this model, agents write short JavaScript orchestration scripts rather than dispatching sub-agents one by one. That shift changes the mode of operation: the agent defines the execution flow declaratively, and the harness carries it out with continuous capability checks and explicit bridges.

Reference to Mete’s Security Principle

Lovell explicitly cites Mete’s security principle, which states that an agent must not simultaneously have access to sensitive data, be exposed to untrusted input, and have the ability to modify external state or communicate outward. The combination of all three factors — regardless of the sophistication of the rest of the system — makes the agent architecture unsafe.

The QuickJS-WASM approach directly addresses the second and third conditions: without default network or system access, even a compromised agent has a dramatically limited blast radius.

Two New Open-Source Libraries

Alongside the post, LangChain released two experimental open-source libraries:

• quickjs-rs — runtime and Python bindings for QuickJS via WASM, available to developer communities as a foundation for their own implementations
• langchain-quickjs — Deep Agents middleware that integrates quickjs-rs with LangGraph, including mechanisms for stateful pauses and state serialization between steps

Both are marked as experimental — the API may change between versions, but the core architecture and security model are stable.

Implications for Production Agent Architecture

Solving reliable execution of generated code is one of the key technical challenges on the path to production-robust autonomous agents. Prompt injection remains an open problem — but if an agent, even when successfully manipulated, cannot access the file system, network, or external services without explicit authorization, the blast radius of possible damage shrinks dramatically.

LangChain’s approach is not a silver bullet: it requires careful design of capability bridges and discipline in defining narrow API contracts. But an architecture that in a single move addresses execution isolation, capability isolation, and stateful resumption — without an external container and without compromising on latency — is a meaningful advance for anyone building production agent systems in 2026.