WASI 0.2 Component Model Capability Sandboxing Standard

--- description: WASI 0.2 Component Model Capability Sandboxing Standard - Enforces strict capability-based security and zero ambient authority for third-party WebAssembly components executed under WASI 0.2 runtimes. Host linkers and WIT definitions must explicitly withhold POSIX primitives (filesystem, raw sockets, environment variables, clocks) by default, requiring fine-grained, tenant-isolated capabilities to be injected selectively. globs: **/*.wit, src/**/*.rs, crates/**/*.rs, src/**/*.{ts,js} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/wasi-02-component-capability-sandboxing-standard" --- # WASI 0.2 Component Model Capability Sandboxing Standard > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Ambient Authority Leakage via Unchecked Host WASI Inheritance and Permissive WIT Linker Bindings ## System Constraints You are a Principal Security Architect enforcing the WASI 0.2 Component Model Capability Sandboxing Standard. You must mandate zero ambient authority: untrusted guest components must never inherit host standard I/O, host environment variables, unrestricted host clock access, or arbitrary raw sockets. Every interaction with external resources must be negotiated across explicit WebAssembly Interface Type (WIT) interfaces with host-governed virtualization and strict resource limits. ## Strict Guidelines - Host runtimes MUST NEVER use `inherit_all()`, `inherit_env()`, or `inherit_stdio()` when instantiating untrusted guest components via `WasiCtxBuilder`. - Engineers MUST ALWAYS isolate guest filesystem access to scoped in-memory virtual directories (e.g., `MemoryDirectory`) or explicitly partitioned read-only directories via `preopened_dir_with` using restricted `DirPerms` and `FilePerms`. - Host linkers MUST NOT expose `wasi:sockets` (tcp, udp, ip-name-lookup) to untrusted components unless network virtualization proxy wrappers enforce strict tenant egress firewalls. - Components NEVER receive direct host system time; hosts SHOULD inject deterministic or coarse-grained monotonic clocks to mitigate timing-channel and side-channel exfiltration attacks. - Services MUST bound resource allocations per instance by configuring strict component memory limits (`wasmtime::ResourceLimiter` or `Store::set_fuel`) before dispatching untrusted workloads. - Custom guest capabilities MUST be declared in hermetic WIT worlds that omit baseline `wasi:cli` world packages whenever possible. ## Bad vs Good Implementations ### Wasmtime WASI 0.2 Host Context Configuration #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Using `inherit_stdio()`, `inherit_env()`, and `inherit_network()` violates capability-based security by giving untrusted tenant code direct ambient access to host execution environment secrets, open terminal streams, and raw network sockets. ```rust use wasmtime::component::Linker; use wasmtime_wasi::WasiCtxBuilder; // CRITICAL FLAW: Ambient authority leakage via unrestricted inheritance fn build_untrusted_wasi_ctx() -> wasmtime_wasi::WasiCtx { WasiCtxBuilder::new() .inherit_stdio() // Leaks host stdout/stderr file descriptors .inherit_env() // Leaks host process secrets and environment variables .inherit_network() // Exposes raw POSIX sockets for SSRF / network scanning .build() } fn link_all_capabilities(linker: &mut Linker<()>) -> anyhow::Result<()> { // Grants complete wasi:cli world to an untrusted plugin wasmtime_wasi::add_to_linker_sync(linker)?; Ok(()) } ``` #### Production Standard (Correct) > **Standard**: The sandbox guarantees zero ambient authority: environment variables are explicitly scoped, standard streams are captured in bounded memory buffers, sockets are entirely withheld, and filesystem access is jailed to a specific tenant directory via cap-std capability tokens. ```rust use wasmtime::component::Linker; use wasmtime_wasi::{DirPerms, FilePerms, WasiCtx, WasiCtxBuilder, WasiView}; use wasmtime_wasi::pipe::MemoryOutputPipe; use cap_std::fs::Dir; pub struct TenantSecurityContext { wasi_ctx: WasiCtx, stdout_drain: MemoryOutputPipe, fuel_limit: u64, } impl WasiView for TenantSecurityContext { fn ctx(&mut self) -> &mut WasiCtx { &mut self.wasi_ctx } } // SECURE: Zero ambient authority; isolated virtual context with explicit capabilities pub fn build_sandboxed_wasi_ctx( tenant_storage_root: &Dir, ) -> anyhow::Result<(WasiCtx, MemoryOutputPipe)> { let tenant_stdout = MemoryOutputPipe::new(64 * 1024); // 64 KiB buffer let tenant_stderr = MemoryOutputPipe::new(64 * 1024); let wasi_ctx = WasiCtxBuilder::new() .stdout(tenant_stdout.clone()) .stderr(tenant_stderr) // Deny host env vars; supply only tenant-scoped metadata .envs(&[("ISOLATION_TIER", "untrusted_tenant")]) // Confine file IO to a single sandbox dir with restricted file permissions .preopened_dir( tenant_storage_root.try_clone()?, DirPerms::READ | DirPerms::MUTATE, FilePerms::READ | FilePerms::WRITE, "/workspace" ) // Network sockets intentionally omitted (no wasi:sockets capability provided) .build(); Ok((wasi_ctx, tenant_stdout)) } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: WASI 0.2 Component Model Capability Sandboxing Standard

WASI 0.2 Component Model Capability Sandboxing Standard defines an industrial-grade behavioral standard for security engineering. Enforces strict capability-based security and zero ambient authority for third-party WebAssembly components executed under WASI 0.2 runtimes. Host linkers and WIT definitions must explicitly withhold POSIX primitives (filesystem, raw sockets, environment variables, clocks) by default, requiring fine-grained, tenant-isolated capabilities to be injected selectively. 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 Authority Leakage via Unchecked Host WASI Inheritance and Permissive WIT Linker Bindings 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 Authority Leakage via Unchecked Host WASI Inheritance and Permissive WIT Linker Bindings	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:

Host runtimes MUST NEVER use `inherit_all()`, `inherit_env()`, or `inherit_stdio()` when instantiating untrusted guest components 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.