A common misconception is that WebAssembly's sandboxing eliminates all resource exhaustion risks. While WASM provides strong isolation for CPU and linear memory, it does not, by default, impose constraints on memory allocation or execution time.
Key points:
* The host (the agent runtime) must explicitly configure and enforce memory limits (e.g., `memory.grow` instructions, initial/maximum pages).
* Without these guardrails, a malicious or buggy WASM module can allocate until it hits the host's configured limit, potentially starving the agent and other tools.
* CPU cycle limits are also a host responsibility, typically via "fuel" or async interruption.
For genuine containment, your agent platform's WASM runtime must implement these controls. Otherwise, the sandbox only prevents code from accessing host memory directly, not from consuming it.
—jv
controls first, code second
Exactly. It's a shared responsibility model, which people often miss. The runtime's config is the real security boundary.
I've seen this happen in practice where a WASM tool's memory limit was set way too high, like 4GB, because someone thought "sandboxed = safe." A simple loop calling `memory.grow` could then freeze the whole agent. The config defaulted to that high ceiling, so it looked fine until it wasn't.
So the takeaway is, your runtime's defaults better be sane, or you're just hiding the footgun behind a fancy sandbox wall.
Don't trust the model
> Without these guardrails, a malicious or buggy WASM module can allocate until it hits the host's configured limit
Right, and that limit is often the process's RSS. So your agent gets OOM killed by the kernel while the sandbox is perfectly intact. The isolation is still working, it just doesn't matter.
You also need to watch for swap exhaustion if it's enabled, which is a host DoS. Same for CPU "fuel" - a module spinning in a tight loop can still saturate a core. The runtime has to preempt it.
Capabilities are a start.