agent-readings

Isolation and Sandboxing

WebAssembly

WebAssembly defines a compact, typed, sandboxed low-level code format whose validated modules can run near native speed while receiving authority only through host-provided imports.

7Claims
7Evidence

Why It Matters

For agents, WASM is a useful substrate for tool execution because untrusted code starts with no ambient OS access and every external effect must be mediated by the embedder's import/API layer.

Problem

  • JavaScript had become the only universal built-in Web language despite inconsistent performance and awkwardness as a low-level compilation target.
  • asm.js demonstrated that typed low-level subsets could run fast, but still inherited JavaScript parsing and representation costs.
  • Mobile code on the Web needed efficient validation, compact transfer, safe execution, and broad browser/vendor support.
  • Sandboxing untrusted code required a narrow, well-specified boundary between computation and host environment effects.

Key gap: The paper asks how to define a low-level, portable, safe, efficient, and formally specified compilation target that can run inside the Web and beyond it.

Method

Encode low-level code as typed modules, validate before execution, restrict memory to bounds-checked linear memories, keep control flow structured, and require all environmental authority to be imported from an embedder.

  • Compile source languages such as C/C++/Rust into WebAssembly modules.
  • Transmit or load the compact binary format.
  • Decode and validate the module before execution.
  • Instantiate the module with explicitly supplied host imports.
  • Run code through JIT, AOT, or interpreter backends with stack and type invariants already checked.
  • Use linear memory bounds checks and traps to prevent memory corruption outside the module's memory model.
  • Expose only selected host functions and resources through imports.
  • Rely on embedding-specific APIs and policies for I/O, OS access, browser integration, or server-side capabilities.

Claims

C1 · paper-supported

WebAssembly was designed as a portable low-level bytecode/virtual ISA for efficient validation, compilation, safe execution, and Web-platform interoperability.

Scope: PLDI abstract and spec introduction.

  • E-design-goals: The publication abstract and spec describe WebAssembly as a low-level bytecode/virtual ISA with compact representation, efficient validation and compilation, safe low-overhead execution, and language/platform independence.

C2 · source-supported

A module goes through decoding, validation, instantiation, and invocation, with validation checking type and stack discipline before execution.

Scope: WebAssembly core spec overview.

  • E-semantic-phases: The spec divides semantics into decoding, validation, and execution; execution further includes instantiation and invocation.

C3 · source-supported

WebAssembly's memory safety comes from validated code and bounds-checked linear memory; out-of-bounds access traps instead of corrupting host memory.

Scope: WebAssembly core spec introduction and overview.

  • E-memory-safety: The spec states that code executes in a memory-safe sandbox and that linear-memory loads/stores trap when accesses are outside current memory bounds.

C4 · source-supported

WASM modules have no ambient access to I/O, OS calls, or resources; environmental interaction happens only through host-provided imports.

Scope: WebAssembly security considerations.

  • E-no-ambient-authority: The spec says WebAssembly provides no ambient access to I/O, resources, operating-system calls, or the computing environment; interaction happens only by invoking embedder-provided imports.

C5 · paper-supported

The WebAssembly design prioritizes compact binary representation and fast single-pass decoding, validation, and compilation.

Scope: PLDI abstract and spec design goals.

  • E-compact-fast: The paper and spec emphasize compact binary representation, fast decoding/validation/compilation, streamability, parallelizability, and near-native execution on common hardware.

C6 · source-supported

The core WebAssembly specification deliberately does not define host-specific APIs; embeddings such as browsers or server runtimes define imports, invocation, and environmental access.

Scope: WebAssembly core spec scope.

  • E-embedding-boundary: The core spec defines instruction set, binary encoding, validation, execution semantics, and text format, but leaves environment interaction, module loading, imports, and exports to embedding-specific API definitions.

C7 · source-supported

WASM execution can still be vulnerable to hardware side channels and host-import misuse, so additional embedder mitigations are required where those risks matter.

Scope: WebAssembly security considerations.

  • E-side-channels: The spec notes that because WebAssembly may be translated into machine code running directly on host hardware, it can be vulnerable to hardware-level side channels and embedders may need mitigations.

Agent Infrastructure Takeaways

  • WASM is a useful agent-tool ABI because code starts with computation but no ambient authority.
  • The import list is the permission model. If an agent tool should not access the network, filesystem, clock, or secrets, do not import those capabilities.
  • Host imports need the same design care as syscalls: stable names, typed inputs, policy checks, audit logs, timeouts, resource limits, and idempotency keys.
  • WASM is strongest for deterministic, CPU-bound, narrow-API tools. It is weaker when the task needs broad POSIX compatibility or arbitrary native packages.
  • WASM validation gives a cheap admission check before execution, which is useful for contributed tools and generated code.
  • WASM does not solve prompt injection or misuse of allowed imports. The sandbox only controls what the code can do, not whether the agent should have asked it to do that.

Caveats

  • The review combines the 2017 PLDI paper framing with the current WebAssembly core spec for precise semantics.
  • WASM is not a full operating-system sandbox by itself; host embeddings decide what resources are available.
  • Unsafe source languages can corrupt their own data structures inside linear memory even if host memory is protected.
  • Hardware side channels and host-import vulnerabilities remain outside the core validation guarantee.
  • Practical WASM tool execution often depends on WASI or another embedding layer, which has its own security and compatibility semantics.
  • Native package compatibility is narrower than gVisor or Firecracker unless the toolchain and imports are designed for WASM.