Skip to main content
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 flips the security model. WebAssembly is a memory-safe, purely mathematical compute format. By default, a .wasm module literally lacks the CPU instructions to talk to the operating system, disk, clock, or network. WASI is the strictly controlled bridge that re-introduces these features exactly, and only, when explicitly granted.

​
The LIOP Sandbox Lifecycle

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

​
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 see if it allows this specific Agent to access those capabilities.

​
2. Microscopic Preopens

If approved, the Data Node does not grant the WASM module access to the file system. Instead, it “pre-opens” very specific file descriptors and maps them into the WASM module’s virtualized space. If the agent asks to read /var/log/nginx/ and the server allows it as /logs, the Agent only sees /logs as the absolute root of its entire universe. Attempting to traverse directories with ../ stops dead at the Sandbox limit.

​
3. Execution & Memory Bounds

Wasmtime boots the engine with strict limiters:
  • Maximum Execution Time: If the module enters an infinite loop, the runtime kills it via Out-Of-Fuel exhaustion.
  • Maximum Memory Limit: If the module attempts a buffer overflow or tries to allocate memory beyond its cap (e.g., 50MB), it triggers an uncatchable OOM Trap.
  • Zero Sockets: The Agent logic runs completely offline inside the Server. It cannot open a port, connect to the internet, or exfiltrate data directly over a TCP socket. Its only output is what it returns to the LIOP invocation orchestrator.
  • Node.js Parity (V8 Isolation): In local development or SDK Demos (where WebAssembly isn’t pre-installed), LIOP utilizes identical strict boundaries via the node:vm module (vm.createContext(Object.create(null))). This establishes absolute hardware-level containment, explicitly stripping the Sandbox of 25 poisoned globals (process, require, eval, Function, Date, ArrayBuffer, Uint8Array, and more), thereby eliminating any possibility of Host-System escalation.
  • Timing Side-Channel Defense: The Date object is poisoned within the sandbox to prevent injected logic from measuring execution time differences, which could be used to infer dataset size or internal execution patterns. Because the global Date class is set to undefined (calling new Date() or Date.now() will throw a ReferenceError), chronological sorting and filtering must be performed using lexicographical string comparisons on ISO 8601 strings (e.g., record.date >= '2024-01-01').
  • Heap Bomb Defense: All 12 TypedArray constructors (Uint8Array, Float64Array, DataView, etc.) are neutralized to prevent allocation of massive binary buffers that could crash the worker process through V8 heap exhaustion. Each worker is additionally constrained to a configurable memory ceiling via maxHeapMb (default: 64 MB).
  • Prototype Pollution Defense: Eleven core JavaScript prototypes (Object, Array, String, Number, Boolean, RegExp, Map, Set, Promise, Error, and Function resolved dynamically) are frozen via Object.freeze() inside the sandbox IIFE before user code executes. By wrapping execution in "use strict";, any unauthorized attempts to pollute prototypes trigger immediate TypeError halts instead of silent failures, preventing injected logic from overriding built-in methods.
  • Non-Blocking Pool: The Sandbox execution is inherently computationally heavy. To prevent Node.js servers from freezing, the @nekzus/liop isolates this entire lifecycle inside native worker_threads (via piscina), achieving parallel throughput identical to the native Mesh-Node. The pool implements an asynchronous background warmup (No-Op Warmup) on 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.