WebAssembly Sandbox (Wasm)

Wasm modules execute in a deny-by-default sandbox. Unlike containers that inherit the host kernel's vast system call interface, a Wasm module has zero ambient authority. It cannot access files, network sockets, or the system clock unless a host function is explicitly passed into its import table at instantiation time. This inverts the traditional security paradigm: instead of filtering dangerous operations, the runtime simply never provides the capability to perform them. This principle, rooted in object-capability theory, makes Wasm an ideal execution environment for untrusted agent code where least privilege must be enforced architecturally rather than through brittle, regex-based seccomp profiles.

Wasm memory is a single contiguous linear address space with no executable permissions. All memory access is bounds-checked at runtime against the current memory size, preventing buffer overflows from corrupting the host or escaping the sandbox. The runtime places guard pages—unmapped virtual memory regions—at the boundaries of the Wasm heap. Any out-of-bounds access triggers a trap, immediately halting execution. Crucially, Wasm memory is byte-addressable but not instruction-addressable; code lives in a separate, immutable module space. This strict Harvard architecture eliminates code injection attacks entirely, as an attacker cannot write shellcode into memory and redirect execution flow to it.

Control flow in Wasm is protected by typed function tables. Unlike native code where function pointers are raw memory addresses, Wasm uses table indices that are validated against a static type signature at every indirect call site. The runtime performs a dynamic type check comparing the expected function signature declared at the call site with the actual signature of the target function in the table. A mismatch triggers a trap. This mechanism, combined with the separation of code and data spaces, provides a form of coarse-grained Control Flow Integrity (CFI) that prevents an attacker from hijacking an indirect call to jump to an arbitrary location or a function with an incompatible signature.

Wasm runtimes can enforce deterministic resource limits using instruction-level fuel metering. Before executing each instruction, the runtime decrements a fuel counter; when it reaches zero, execution traps. This provides a hard guarantee on CPU consumption regardless of input complexity, preventing algorithmic complexity denial-of-service attacks. Combined with configurable memory limits enforced at allocation time, Wasm offers predictable, billable resource isolation. This is critical for multi-tenant agent platforms where one tenant's runaway agent must not degrade service for others. The metering is deterministic because Wasm's instruction set is designed to have predictable execution costs, unlike native x86 or ARM instructions.

The Wasm ecosystem is moving toward formally verified runtimes that provide mathematical guarantees against sandbox escape. Projects use mechanized proof assistants to verify that the runtime's memory isolation, type checking, and control flow enforcement are correct for all possible inputs. Beyond single-module isolation, Wasm enables nanoprocess compartmentalization: a single application can be decomposed into dozens of mutually distrusting Wasm modules that communicate only through typed, copy-based message passing. Each library or agent sub-component runs in its own isolated linear memory, so a compromise in one compartment cannot read or corrupt another's state. This is the principle of least privilege applied at the software architecture level.

A security facility in the Linux kernel that allows a process to make a one-way transition into a restricted state where it can only make a predefined set of system calls. While WebAssembly denies dangerous operations at the bytecode level, seccomp profiles enforce restrictions at the kernel boundary. A strict profile might allow only read, write, exit, and sigreturn, drastically reducing the kernel attack surface for agent processes.

The practice of writing security and compliance rules in a high-level, machine-readable language that can be automatically enforced by a policy engine. When an agent attempts an action, the policy engine evaluates it against rules written in languages like Rego (Open Policy Agent). This decouples authorization logic from application code, enabling unified, context-aware enforcement across the entire agentic stack.

A short-lived, disposable execution context created from a known-good image and completely destroyed after a single task. This pattern prevents state contamination and persistent threats. Combined with WebAssembly's memory safety, ephemeral environments ensure that even if an agent is compromised, the attacker gains no persistent foothold. Common in CI/CD pipelines and serverless functions.

A programming language, such as Rust, that manages memory automatically at compile time through an ownership model. This eliminates entire classes of memory-safety bugs like use-after-free and buffer overflows. WebAssembly's linear memory model and capability-based security pair naturally with Rust's compile-time guarantees, making the combination a gold standard for building secure agent runtimes.