> ## Documentation Index
> Fetch the complete documentation index at: https://nekzus-32.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# 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 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:
### 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:
```typescript theme={null}
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.