Sandboxing AI Agents with WebAssembly: Zero Authority by Default

Cosmonic's post, currently trending on HN, makes a strong case that conventional Linux sandboxing mechanisms — seccomp, seatbelt, bubblewrap — are fundamentally unsuited for agentic AI workloads. The core problem: ambient authority.

The Ambient Authority Problem

Every modern runtime gives a process whatever permissions its environment provides: filesystem, network, the user's git credentials, an AWS API key in ENV. The process never asked for them. For deterministic human-written binaries, you can maybe manage this risk with audits. But LLM agents and non-deterministic workflows inherit the developer's full identity and capabilities, creating an 'intolerable attack surface.'

The author calls this the cartographer's dilemma: you're trying to map a shifting coastline of exfiltration paths, and the LLM will find every unmapped cove.

WebAssembly's Capability Model

Cosmonic positions WebAssembly and WASI as the alternative. A Wasm component starts with zero authority: no filesystem, no network, no syscalls, no env vars. Any capability must be a typed import in the component's interface. This is Mark Miller's object-capability model as a runtime: the reference is the permission.

Key implications:

• Virtualized grants: a filesystem capability doesn't hand over /etc. It provides an interface backed by any store (tmpfs, per-session blob, database). The component cannot escape the abstraction.
• Composable capabilities: instead of importing 'the network,' a component imports wasi:http with allowed traffic shapes, or wasi:keyvalue with a specific bucket. Every capability is named, scoped, and reviewable.

This shifts the security model from 'allow by default, restrict by exception' to 'deny by default, grant explicitly.' The author argues this is the only sound foundation for AI agent security.