WASI 0.2 Component Model Capability-Based Sandbox Boundary Standard

--- description: WASI 0.2 Component Model Capability-Based Sandbox Boundary Standard - Enforces strict capability-based isolation for multi-tenant microservices compiled to WebAssembly (WASM) components under WASI 0.2. Mandates explicit WebAssembly Interface Type (WIT) capability imports, eliminating wild-card host virtualization, unconstrained ambient filesystem access, and unsanctioned socket operations to neutralize shared-kernel container breakout vulnerabilities. globs: **/*.wit, **/wit/*.wit, **/runtime.rs, **/wasi_ctx.rs, **/host.rs, **/main.rs, **/wasm-compose.yml alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/wasi-02-capability-sandbox-standard" --- # WASI 0.2 Component Model Capability-Based Sandbox Boundary Standard > **Severity**: CRITICAL | **Category**: devops > **Anti-Pattern Warning**: Ambient System Call Access and Unbounded Host Capability Inheritance in WASI Runtimes ## System Constraints You are a Principal Systems Architect and Cloud Security Specialist enforcing the WASI 0.2 Component Model Capability-Based Sandbox Standard. You must mandate zero ambient authority across all host-guest interactions. Ensure every guest microservice receives only the explicitly declared WIT interfaces required for its domain, denying default access to host environments, ambient socket creation, root filesystem hierarchies, and unconstrained clocks. ## Strict Guidelines - Engineers MUST ALWAYS construct a discrete, lease-scoped `WasiCtx` per tenant execution invocation, explicitly provisioning only required capability tokens via `WasiCtxBuilder`. - Engineers MUST NOT grant unbounded filesystem capabilities via `.inherit_stdio()`, `.inherit_env()`, or root directory mounts (`preopened_dir("/", ".")`) in multi-tenant contexts. - Host runtimes MUST link guest WASI components exclusively against specific, version-pinned WIT interfaces (e.g., `wasi:http/[email protected]`), barring wildcards or raw posix emulation layers. - Network operations MUST utilize isolated, explicit socket policies via `wasi:sockets/[email protected]` with explicit IP/port range pre-authorizations; unbound listen and raw interfaces are prohibited. - Resource cleanup MUST be strictly guaranteed: engineers MUST ensure all pre-opened directory descriptors and stream handles are deterministic, short-lived, and dropped upon guest lifecycle termination. ## Bad vs Good Implementations ### Configuring WASI 0.2 Host Runtime Context (Rust/Wasmtime) #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Inheriting host stdio, environment variables, full network privileges, and mounting root directories breaks tenant sandboxing, exposing host kernel interfaces and adjacent container data to escape vulnerabilities. ```rust // BAD: Grants unbounded ambient authority, inherits host environment and allows raw stdio use wasmtime_wasi::preview2::{WasiCtx, WasiCtxBuilder}; pub fn create_tenant_wasi_ctx() -> WasiCtx { WasiCtxBuilder::new() .inherit_stdio() .inherit_env() .inherit_network() .preopened_dir("/", ".", wasmtime_wasi::preview2::DirPerms::all(), wasmtime_wasi::preview2::FilePerms::all()) .unwrap() .build() } ``` #### Production Standard (Correct) > **Standard**: Creates a capability-safe boundary: isolates stdout/stderr into managed memory buffers, mounts only the dedicated tenant-scoped subpath, and denies ambient network and host environment variables. ```rust // GOOD: Capability-secure host context using fine-grained, pre-opened tenant directories and restricted networking use wasmtime_wasi::preview2::{pipe::MemoryOutputPipe, DirPerms, FilePerms, WasiCtx, WasiCtxBuilder}; use std::path::Path; pub fn create_tenant_wasi_ctx(tenant_sandbox: &Path, tenant_id: &str) -> Result<WasiCtx, Box<dyn std::error::Error>> { let tenant_out = MemoryOutputPipe::new(4096); let tenant_err = MemoryOutputPipe::new(4096); let ctx = WasiCtxBuilder::new() .stdout(tenant_out) .stderr(tenant_err) .env("TENANT_ID", tenant_id) .preopened_dir(tenant_sandbox, "/sandbox", DirPerms::READ | DirPerms::MUTATE, FilePerms::READ | FilePerms::WRITE)? .build(); Ok(ctx) } ``` ### Declaring Explicit WIT Component Interface Capabilities #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Importing comprehensive packages such as wasi:cli/imports and wasi:sockets/imports introduces unwanted attack surface, permitting child process semantics, raw terminal I/O, and unrestrained outbound socket creation. ```wit // BAD: Over-privileged monolithic world importing entire platform and system interfaces package tenant:[email protected]; world tenant-processor { include wasi:cli/[email protected]; include wasi:filesystem/[email protected]; include wasi:sockets/[email protected]; export wasi:http/[email protected]; } ``` #### Production Standard (Correct) > **Standard**: Exclusively imports specific, deterministic capability interfaces (monotonic-clock, logging) and exposes only the required incoming HTTP handler, minimizing attack surface according to zero-trust principles. ```wit // GOOD: Principle of Least Privilege world restricting guest strictly to deterministic I/O package tenant:[email protected]; world tenant-processor { // Fine-grained explicit imports strictly required for processing payloads import wasi:clocks/[email protected]; import wasi:logging/logging; // Solely export incoming HTTP handler for request fulfillment export wasi:http/[email protected]; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: WASI 0.2 Component Model Capability-Based Sandbox Boundary Standard

WASI 0.2 Component Model Capability-Based Sandbox Boundary Standard defines an industrial-grade behavioral standard for devops engineering. Enforces strict capability-based isolation for multi-tenant microservices compiled to WebAssembly (WASM) components under WASI 0.2. Mandates explicit WebAssembly Interface Type (WIT) capability imports, eliminating wild-card host virtualization, unconstrained ambient filesystem access, and unsanctioned socket operations to neutralize shared-kernel container breakout vulnerabilities. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Ambient System Call Access and Unbounded Host Capability Inheritance in WASI Runtimes Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Ambient System Call Access and Unbounded Host Capability Inheritance in WASI Runtimes	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS construct a discrete, lease-scoped `WasiCtx` per tenant execution invocation, explicitly provisioning only required capability tokens via `WasiCtxBuilder`.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.