Everyone’s rushing to cram their entire AI agent into a WASM sandbox for “security,” but they’re missing the forest for the trees. We had a simple, file-based tool system for our agents—mostly reading logs, summarizing reports, the usual. It ran natively, with the agent process having direct file access. Predictable chorus: “But what if it gets compromised? It could read everything!”
So, in a fit of compliance theater, we switched the file I/O tools to run in a WASM sandbox. The immediate, glaring result? It’s slower, more complex, and did precisely nothing to improve our actual security posture. Why? Because the agent still needs to read the files. The “sandbox” just means the WASM module returns file contents to the controlling host process, which then passes it to the agent. If the agent is compromised, it’s still getting the data. We’ve added a pointless indirection.
The genuine benefit, ironically, wasn’t security. It was dependency isolation. No more worrying about the tool’s Python version or some random library conflict. The WASM module is a static binary with its own libc. That’s it. That’s the win. But you could achieve 90% of that with a properly containerized subprocess and a simple shell script. Instead, we now have a build pipeline for WASM and a bunch of host-side glue code that’s more fragile than the original.
WASM as a sandbox is useful when you’re running truly untrusted code *and* you can define a minimal, capability-based interface. For file I/O? It’s usually security theater. The real threat model—malicious prompts extracting data—isn’t addressed by this. The agent still gets the data. All we’ve done is move the deck chairs on the Titanic and called it a “security innovation.”
KISS
Yeah, you're spot on about the dependency isolation being the real win. I ran into that exact Python library conflict nightmare with some custom log parsers. Forced a full rebuild of my homelab's agent host.
The security theater angle is frustrating. If the host process is marshaling all the data back and forth, you've just moved the trust boundary. The agent is still the thing with the access. A true sandbox would need to enforce policy *inside* the sandbox, like "this module can only read from /var/log/ and only return a summary, not the raw bytes." That's a much harder problem.
Have you looked at using a gVisor container instead? It gives you the dependency isolation but with a more complete syscall surface. For my stuff, I ended up just using statically compiled Go binaries in a minimal chroot. Simpler than WASM, and the overhead is similar.
Kenji
Exactly, the trust boundary point is critical. You've still got the host process, the runtime, and now the agent all in the same trust domain if the data flows back out. I've been instrumenting some of these flows with eBPF, and you can watch the data copy from the WASM linear memory back into the agent's heap. If your threat model includes a compromised agent, you've gained nothing.
The dependency isolation is real, but have you measured the syscall overhead? I was seeing a 40-60x slowdown on repeated stat calls in a hot path compared to a native module. That cost comes from the host-side syscall proxying, not the compute. For batch jobs it's fine, but for any interactive agent tool it introduces unacceptable latency.