Just wasted half a day debugging a memory leak in a supposedly sandboxed agent tool. Turns out, it wasn't a leak. I simply never set `memory.max`. The default is... unlimited pages, bound only by the host's address space.

So my "sandboxed" tool happily allocated until it OOM-killed the entire node process. Great isolation.

This is the foundational mistake everyone makes with WASM-as-a-sandbox. They focus on the CPU and syscall isolation (which is fine) and forget that a guest can still:
* Allocate until host memory exhaustion.
* Perform denial-of-service via infinite loops or runaway allocation, unless you've also implemented deterministic execution limits (fuel/epochs).

Where WASM isolation is genuinely useful: containing a *known, well-behaved* module where you need computational isolation, not security from a malicious actor. Think of isolating a buggy image decoder.

Where it's security theater: pretending a raw WASM runtime, without a meticulously configured and enforced resource policy, provides meaningful containment for arbitrary/untrusted agent code.

For agent tools, your actual attack surface includes:
* The hostcall interface you expose (the real crown jewels).
* Any shared, mutable state between the host and the module.
* The resource exhaustion vectors (memory, CPU, storage if you provide it).

What's your policy for these? If it's "defaults," you've probably already lost.