WASI Sandboxing

How LIOP isolates execution through the WebAssembly System Interface

The biggest paradigm shift from MCP to LIOP is the concept of Logic-on-Origin. However, executing arbitrary binary logic from remote internet agents on your local infrastructure introduces immense security consequences.

To solve this, LIOP relies entirely on mathematical CPU-level isolation provided by WASI (WebAssembly System Interface), utilizing the Bytecode Alliance’s Wasmtime engine.

What is WASI?

When a Node.js or Python tool executes in MCP, it relies on the operating system’s broad sandboxing (usually containerization like Docker). If a Python dependency is compromised, it could theoretically attempt full network escalation or escape.

WASI establishes a capability-oriented security model. WebAssembly is a memory-safe, portable compilation format. By default, a .wasm module does not include instructions to interact with the operating system, disk, clock, or network. WASI is the controlled bridge that re-introduces these system interfaces only when explicitly granted through host capabilities.

The LIOP Sandbox Lifecycle

When an Agent Node injects a WebAssembly module into a Data Node, the following security barriers activate:

1. Capability Verification

The Agent declares the capabilities it requires upfront (e.g., requires_capability: ["logs_read", "sql_readonly"]). The Data Node checks its local manifest to verify whether this specific Agent is authorized to access those capabilities.

2. Scoped Directory Preopens

If approved, the Data Node does not grant the WASM module arbitrary file system access. Instead, it pre-opens designated directory descriptors and maps them into the virtualized file system space of the module. If the agent requests /var/log/nginx/ and the server permits access as /logs, the Agent sees /logs as an isolated root directory. Directory traversal attempts using ../ are blocked at the sandbox boundary.

3. Execution & Memory Bounds

Wasmtime boots the engine with strict resource constraints:

• Maximum Execution Time: If the module enters an infinite loop, the runtime halts execution via Out-Of-Fuel exhaustion.
• Maximum Memory Limit: If the module attempts a buffer overflow or tries to allocate memory beyond its configured ceiling (e.g., 50MB), Wasmtime triggers a non-recoverable OOM Trap.
• Socket Prohibition: Injected logic executes offline within the server boundary. It cannot open listener ports or initiate external TCP/UDP connections. Its only output is returned through the standard invocation channel.
• Node.js Parity (V8 Isolation): In local development or SDK environments where native WebAssembly runtimes are not pre-configured, LIOP enforces equivalent isolation boundaries through node:vm (vm.createContext(Object.create(null))). The execution environment strips 25 restricted globals (process, require, eval, Function, Date, ArrayBuffer, Uint8Array, and related constructors) to prevent host environment escalation.
• Timing Side-Channel Defense: The Date object is disabled within the sandbox to prevent injected logic from measuring fine-grained execution durations to infer dataset volume. Because calling new Date() or Date.now() throws a ReferenceError, chronological sorting and filtering should use lexicographical comparisons on ISO 8601 strings (such as record.date >= '2024-01-01').
• Heap Allocation Defense: All 12 TypedArray constructors (Uint8Array, Float64Array, DataView, etc.) are neutralized to prevent large binary buffer allocations from causing V8 heap exhaustion. Each worker is constrained by a memory limit configured via maxHeapMb (default: 64 MB).
• Prototype Pollution Defense: Eleven core JavaScript prototypes (Object, Array, String, Number, Boolean, RegExp, Map, Set, Promise, Error, and Function) are frozen via Object.freeze() inside the sandbox IIFE before executing user logic. By wrapping execution in "use strict";, prototype modification attempts throw a TypeError, preventing injected code from overriding built-in methods.
• Non-Blocking Worker Pool: To prevent event loop contention in Node.js servers, @nekzus/liop offloads sandbox execution to worker threads (via piscina). The pool executes an asynchronous warm-up cycle upon initialization to eliminate V8 cold-start overhead (~820k fuel units).
• Safe Host Environment Isolation (allowEnv): By default, the WASI sandbox completely isolates the execution from any environment variables. If host variables are strictly required by the business logic, you can enable environment propagation:
  const server = new LiopServer(info, {
    // In WasiSandbox options
    allowEnv: true
  });
  
  To completely block command-injection exploits (such as Shellshock) and prevent leakage of sensitive secrets (like AWS keys or database tokens), the SDK filters environment variables through a strict safe allowlist via getDefaultEnvironment():
  • Windows Host Allowlist: APPDATA, HOMEDRIVE, HOMEPATH, LOCALAPPDATA, PATH, PROCESSOR_ARCHITECTURE, SYSTEMDRIVE, SYSTEMROOT, TEMP, USERNAME, USERPROFILE, PROGRAMFILES.
  • Unix/Linux Host Allowlist: HOME, LOGNAME, PATH, SHELL, TERM, USER. Any environment variable starting with shell function definitions () is immediately rejected to prevent remote code execution.

Moving towards Component Model (Preview 2)

LIOP is eagerly adopting WASI Preview 2 (The Component Model). This will allow Agent modules to share complex, strongly-typed JSON and Protobuf structs across the boundary (Agent Language -> Rust Engine), completely eliminating manual string-parsing overhead between the Sandbox and the Host.