WASI 0.2 Component Model Capability-Based Sandbox Boundary Standard

Enforces strict capability-based security boundaries for multi-tenant microservices compiled into WASI 0.2 (Preview 2) WebAssembly components. Precludes ambient authority by restricting host bindings exclusively to explicit WebAssembly Interface Type (WIT) interfaces (e.g., `wasi:http/outgoing-handler`, `wasi:filesystem/preopens`) without granting broad POSIX or unchecked host-level capabilities. Prevents untrusted guest code execution from compromising host infrastructure via unconstrained directory traversal, socket creation, or unmediated environment variable access.

--- description: WASI 0.2 Component Model Capability-Based Sandbox Boundary Standard - Enforces strict capability-based security boundaries for multi-tenant microservices compiled into WASI 0.2 (Preview 2) WebAssembly components. Precludes ambient authority by restricting host bindings exclusively to explicit WebAssembly Interface Type (WIT) interfaces (e.g., `wasi:http/outgoing-handler`, `wasi:filesystem/preopens`) without granting broad POSIX or unchecked host-level capabilities. Prevents untrusted guest code execution from compromising host infrastructure via unconstrained directory traversal, socket creation, or unmediated environment variable access. globs: **/*.wit, **/wit/*.wit, src/**/host.rs, src/**/runtime.rs, src/**/guest.rs, src/**/sandbox.rs, src/**/wasi_ctx.rs alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/wasi-p2-capability-boundary-standard" --- # WASI 0.2 Component Model Capability-Based Sandbox Boundary Standard > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Ambient POSIX Emulation and Unchecked Host Capability Ingestion in Multi-Tenant WASM Runtimes ## System Constraints You are a Principal Security Architect and WebAssembly Systems Engineer enforcing the WASI 0.2 Component Model Capability-Based Sandbox Boundary Standard. Untrusted multi-tenant microservices must operate under absolute zero ambient authority. All host access—such as network endpoints, file systems, clocks, and environment variables—must be mediated exclusively through explicit WebAssembly Interface Type (WIT) imports and pre-scoped capability handles. You must reject configurations that instantiate WASI runtimes with default POSIX host inheritance, unrestricted preopens, or un-virtualized outbound HTTP handlers. ## Strict Guidelines - Engineers MUST ALWAYS construct guest runtime contexts (`WasiCtx`) using capability-isolated builders, denying ambient access to the host's actual root filesystem, real network sockets, and environment variables. - Engineers MUST NOT map host directories with unrestricted write permissions or assign the host root directory (`/`) as a preopen in multi-tenant contexts. - Code MUST restrict outbound network capabilities to an explicit domain allowlist by intercepting `wasi:http/outgoing-handler` rather than binding unrestricted socket primitives (`wasi:sockets`). - Services MUST compile guest workloads into canonical WASI 0.2 Components via the WebAssembly Component Model rather than legacy WASI Preview 1 (wasi_snapshot_preview1) binaries that rely on POSIX emulation. - Components NEVER receive ambient environment variables containing secrets; configuration and credentials MUST be provisioned dynamically through WIT resource methods or sealed transient capability tokens. ## Bad vs Good Implementations ### Configuring WASI 0.2 Wasmtime Host Sandbox for Untrusted Multi-Tenant Guest #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Inheriting the host environment, host network, and mapping the root directory directly grants full ambient authority to untrusted guest code, completely bypassing WASI 0.2 sandboxing guarantees and exposing host infrastructure to compromise. ```rust // BAD: Grants ambient filesystem and network access to the guest component use wasmtime::component::Linker; use wasmtime_wasi::{WasiCtx, WasiCtxBuilder, WasiView}; pub struct TenantHostState { pub wasi_ctx: WasiCtx, } impl WasiView for TenantHostState { fn ctx(&mut self) -> &mut WasiCtx { &mut self.wasi_ctx } } pub fn build_insecure_host_context() -> TenantHostState { let wasi_ctx = WasiCtxBuilder::new() .inherit_stdio() .inherit_env() // Leak: Ambient host environment variables leaked to guest .inherit_network() // Leak: Unrestricted raw TCP/UDP socket creation .preopened_dir("/", ".", wasmtime_wasi::DirPerms::all(), wasmtime_wasi::FilePerms::all()) .unwrap() // Critical: Exposes host root filesystem directly to tenant .build(); TenantHostState { wasi_ctx } } ``` #### Production Standard (Correct) > **Standard**: The runtime isolates the guest by strictly scoping directory access to a localized scratch directory via cap-std, omitting environment inheritance, denying raw socket operations, and enforcing explicit WIT interfaces via ResourceTable and WasiHttpCtx. ```rust // GOOD: Strict capability-based WASI 0.2 sandbox with virtualized boundaries use wasmtime::component::Linker; use wasmtime_wasi::{WasiCtx, WasiCtxBuilder, WasiView, ResourceTable}; use wasmtime_wasi_http::{WasiHttpCtx, WasiHttpView}; use cap_std::fs::Dir; use std::path::Path; pub struct SecureTenantState { pub wasi: WasiCtx, pub http: WasiHttpCtx, pub table: ResourceTable, } impl WasiView for SecureTenantState { fn ctx(&mut self) -> &mut WasiCtx { &mut self.wasi } fn table(&mut self) -> &mut ResourceTable { &mut self.table } } impl WasiHttpView for SecureTenantState { fn ctx(&mut self) -> &mut WasiHttpCtx { &mut self.http } fn table(&mut self) -> &mut ResourceTable { &mut self.table } } pub fn build_secure_host_context(tenant_isolated_dir: &Path) -> SecureTenantState { // Open strictly scoped, unprivileged tenant scratch directory let safe_dir = Dir::open_ambient_dir(tenant_isolated_dir, cap_primitives::ambient_authority()) .expect("Tenant directory must exist"); let wasi = WasiCtxBuilder::new() // No inherit_env(), no inherit_network() .preopened_dir(safe_dir, wasmtime_wasi::DirPerms::READ | wasmtime_wasi::DirPerms::MUTATE, wasmtime_wasi::FilePerms::READ | wasmtime_wasi::FilePerms::WRITE, "/scratch") .build(); SecureTenantState { wasi, http: WasiHttpCtx::new(), // Controlled HTTP interface via WIT, no raw sockets table: ResourceTable::new(), } } ```

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 security engineering. Enforces strict capability-based security boundaries for multi-tenant microservices compiled into WASI 0.2 (Preview 2) WebAssembly components. Precludes ambient authority by restricting host bindings exclusively to explicit WebAssembly Interface Type (WIT) interfaces (e.g., `wasi:http/outgoing-handler`, `wasi:filesystem/preopens`) without granting broad POSIX or unchecked host-level capabilities. Prevents untrusted guest code execution from compromising host infrastructure via unconstrained directory traversal, socket creation, or unmediated environment variable access. 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 POSIX Emulation and Unchecked Host Capability Ingestion in Multi-Tenant WASM 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 POSIX Emulation and Unchecked Host Capability Ingestion in Multi-Tenant WASM 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 guest runtime contexts (`WasiCtx`) using capability-isolated builders, denying ambient access to the host's actual root filesystem, real network sockets, and environment variables.

Engineers MUST ALWAYS construct guest runtime contexts (`WasiCtx`) using capability-isolated builders, denying ambient access to the host's actual root filesystem, real network sockets, and environment variables.

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.