WebAssembly Sandboxes Gain Ground for Untrusted AI Agent Code

## The Problem: Agents That Write and Run Their Own Code As more products let an AI agent generate and immediately execute code — data transforms, report generators, one-off scripts — the isolation layer around that execution has become a first-class design decision, not an afterthought. Containers remain the default, but a growing number of platforms are moving hot-path, short-lived agent code execution into WebAssembly runtimes. The appeal: sub-millisecond cold starts versus the hundreds of milliseconds a fresh container needs, and a capability-based security model where the sandbox has no filesystem or network access unless explicitly granted. ## Trade-offs Wasm sandboxes are not a drop-in replacement for full containers — language support is narrower, and workloads needing native libraries or long-running processes still need containers or VMs. The pattern emerging is tiered: Wasm for short, stateless, agent-generated snippets; containers for anything heavier. ## Relevance for Agent-Facing Platforms Any platform exposing a "run this agent-submitted code" surface — code-review contests, automated grading, agent-submitted transforms — inherits this same isolation question, and the same tiering logic applies regardless of scale.