WebAssembly for Agent Sandboxing

If you're letting an AI agent run code, read files, or touch tools, the question is not "can it be sandboxed?" It's "where is the boundary, really?" That's where containers start to look weaker than most teams assume.

Key Takeaways

• WebAssembly gives you a smaller, more explicit trust boundary than a typical container setup.
• Containers still inherit host-kernel risk, so misconfigurations and runtime flaws matter a lot [1].
• Research on container escape shows that "plain Docker isolation" is not enough by default [1].
• WASM sandboxing works best when you expose only narrow capabilities to the agent.
• Tools like Rephrase can help you rewrite sloppy security prompts into tighter, safer instructions.

---

Why does WebAssembly fit agent sandboxing better?

WebAssembly is a better fit for agent sandboxing because it was designed to run untrusted code in a constrained runtime, not to package a full operating system. For agents, that matters. You want to limit what the model can call, not just wrap it in another process namespace. Capability-based imports and no raw syscalls make that boundary easier to reason about [2].

The core idea is simple: if the agent never gets direct access to the host kernel, the blast radius drops fast. That's a much cleaner model than "a container, plus careful flags, plus correct kernel hardening, plus no daemon exposure."

---

Why do containers leak security boundary?

Containers leak security boundary because they are not true hardware isolation. They share the host kernel, and that kernel becomes part of the attack surface. The latest research on container sandbox escape maps failures across orchestration, runtime, and kernel layers, and shows that many escape paths are practical when misconfigurations or known weaknesses exist [1].

That doesn't mean containers are useless. It means their security boundary is conditional. The boundary is only as strong as the weakest host setting, runtime configuration, and kernel patch level.

The problem in one table

Boundary layer	Containers	WebAssembly
Host kernel exposure	Yes	No direct access
Syscalls	Broadly available through runtime	Not directly exposed
Filesystem reach	Depends on mounts and config	Capability-limited or virtualized
Network reach	Depends on runtime/networking	Explicitly granted only
Escape surface	Runtime, kernel, orchestration	Runtime implementation, host embedding

This is why the security conversation keeps shifting upward. In a container world, you defend many layers. In a WASM world, you can often start with a narrower default boundary and add only the permissions you actually need.

---

What does the research say about container escapes?

The research says container escapes are not theoretical edge cases. SANDBOXESCAPEBENCH evaluates frontier LLMs against Docker and Kubernetes escape paths and concludes that developers should treat "plain Docker isolation" as insufficient by default [1]. The benchmark covers misconfigurations, privileged settings, runtime flaws, and kernel issues, and it shows that capable models can exploit the easy failures reliably.

That's the uncomfortable bit. The risk is not only a zero-day. It's also the boring stuff: overly broad capabilities, exposed Docker sockets, writable host mounts, and sloppy orchestration. If your agent can discover one of those, the container was never much of a boundary.

---

How does WASM change the threat model?

WASM changes the threat model by shrinking the set of things an agent can do unless you deliberately grant them. Instead of "run inside an OS with lots of ambient authority," you move to "run inside a runtime that only sees the capabilities you inject." In practice, that means no ambient filesystem access, no implicit network reach, and no easy path to host commands [2].

That's why WASM is attractive for agents. Agents are dynamic, often prompt-driven, and sometimes adversarially steered through prompt injection. If the model goes off the rails, the sandbox should still be boring.

Before and after

Before:
Run this script and let it inspect the host filesystem if needed.

After:
Run this script in a WASM sandbox with only these imports:
- read_file("workspace/input.csv")
- write_file("workspace/output.json")
- http_get("https://api.example.com", allowlist=["api.example.com"])
- no shell, no host mounts, no raw network

That's the real win: not just isolation, but explicit authority. Rephrase Rephrase can automate this kind of prompt tightening so your agent instructions stop leaking intent or permissions.

---

Where does WebAssembly still fall short?

WebAssembly still falls short when you need full OS compatibility, native drivers, or broad tooling ecosystems. Containers are better for lifting existing software with minimal change. WASM is better for constraining untrusted execution. Those are different jobs, and pretending they're the same is how teams end up with insecure abstractions.

The other catch is that the runtime itself becomes critical. If your WASM host exposes too many host functions, too much filesystem bridging, or a weak embedder API, you can recreate the same mistakes in a different layer. The boundary is smaller, not magical.

---

When should you choose WASM over containers?

You should choose WASM over containers when the primary goal is to run untrusted or semi-trusted agent actions with the smallest possible security boundary. If you're building an LLM agent that edits files, runs snippets, or calls narrow tools, WASM is usually the better first choice [2].

If you need long-lived developer environments, full package managers, or heavy system tooling, containers still make sense. But for the execution core of an agent, I'd rather start with WASM and add containers only when I actually need them.

What do real builders do today?

Real builders tend to use WASM for narrow task execution and containers for surrounding infrastructure. In community examples, people describe WASM shells as a simpler alternative to giving an agent direct host access or setting up heavier Docker workflows, especially when the task is file editing, command execution, or browser-adjacent work [3][4]. That pattern is telling.

The best setups are hybrid: a tight WASM sandbox for the agent's actual actions, plus container or VM isolation for packaging, networking, and ops. That gives you layers without confusing one layer for another.

---

Closing thought

If your agent can be tricked, your boundary should assume failure. That's why I like WebAssembly here: it gives you a cleaner security story than containers alone, especially when the agent's job is narrow and the consequences of escape are high.

If you're designing prompting or runtime policies for agents, keep the instructions as explicit as the sandbox. That's the kind of discipline tools like Rephrase are good at: turning vague prompts into tight, capability-aware instructions.

---

References

Documentation & Research

1. Quantifying Frontier LLM Capabilities for Container Sandbox Escape - arXiv (link)
2. Quantifying Frontier LLM Capabilities for Container Sandbox Escape - arXiv (link)

Community Examples 3. [P] WASM bash shell sandbox for AI agents - r/MachineLearning (link) 4. project: WASM shell for LLM agents, easy, no setup, sandboxed - r/LocalLLaMA (link)