WASI 0.2 Component Model Capability Isolation Standard

--- description: WASI 0.2 Component Model Capability Isolation Standard - Enforces strict principle-of-least-privilege capability passing for WASI 0.2 dynamic tenant plugins via Wasmtime/Wasm-tools runtime bindings. Mandates virtualized in-memory root filesystems without host directory passthroughs, explicit outbound HTTP authority delegation, and complete isolation of clocks, environment variables, and pre-opened descriptor handles. globs: src/**/*.rs, crates/**/*.rs, plugins/**/*.wit, wit/**/*.wit alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/wasi-02-component-model-capability-isolation-standard" --- # WASI 0.2 Component Model Capability Isolation Standard > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Ambient Host Capability Leaks via Default WasiCtxBuilder and Inherited Descriptors ## System Constraints You are a Principal Software Architect enforcing the WASI 0.2 Component Model Capability Isolation Standard. Mandate explicit, per-tenant capability descriptors, deny all ambient system privileges, isolate virtual filesystems, and prohibit direct host stdio/env/directory inheritance in WASI 0.2 hosts. ## Strict Guidelines - Engineers MUST ALWAYS construct tenant `WasiCtx` instances with zero ambient authority, explicitly populating only isolated in-memory or strictly scoped tenant subdirectories via `wasi:filesystem/preopens`. - Engineers MUST NOT call `inherit_stdio()`, `inherit_env()`, or `inherit_network()` when provisioning dynamic tenant plugin runtimes. - Code SHOULD enforce resource limits (fuel consumption, memory tables, maximum instances) using Wasmtime `StoreLimitsBuilder` and runtime fuel metering on every instantiated tenant component. - Services MUST provide network connectivity strictly through explicit WIT-defined service interfaces or a constrained `wasi:http/outgoing-handler` interceptor with host-enforced CIDR/domain allowlists. - Components NEVER receive ambient host filesystem roots; preopened directories MUST bind to dedicated, virtualized subtrees per tenant UUID with strict read/write permission flags. ## Bad vs Good Implementations ### Configuring WASI 0.2 Tenant Sandboxes in Wasmtime Host #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Inheriting host stdio, environment variables, ambient network sockets, and preopening current host working directory leaks host secrets, environment keys, and allows untrusted tenant code to escape sandbox boundaries via unconstrained filesystem modifications. ```rust use wasmtime::component::Linker; use wasmtime_wasi::preview2::{WasiCtx, WasiCtxBuilder}; pub fn create_tenant_wasi_ctx() -> WasiCtx { // DANGEROUS: Ambient capability leakage WasiCtxBuilder::new() .inherit_stdio() .inherit_env() .inherit_network() // Exposes entire host workspace directory directly to untrusted tenant .preopened_dir(".", ".", wasmtime_wasi::preview2::DirPerms::all(), wasmtime_wasi::preview2::FilePerms::all()) .expect("Failed to map root dir") .build() } ``` #### Production Standard (Correct) > **Standard**: Creates a deterministic, lease-privilege execution environment where standard streams are closed or virtualized, host environment variables and network handles are omitted, and filesystem access is confined exclusively to an isolated tenant directory. ```rust use wasmtime::component::Linker; use wasmtime_wasi::preview2::{WasiCtx, WasiCtxBuilder, DirPerms, FilePerms}; use std::path::PathBuf; pub fn create_tenant_wasi_ctx(tenant_sandbox_dir: PathBuf) -> Result<WasiCtx, Box<dyn std::error::Error>> { // SAFE: Zero-trust capability grant model let mut builder = WasiCtxBuilder::new(); // Explicitly isolated pipes without leaking host stdin/out/err descriptors builder.stdin(wasmtime_wasi::preview2::pipe::ClosedInputStream); // Strictly scoped tenant directory only; no ambient env or network builder.preopened_dir( &tenant_sandbox_dir, "/sandbox", DirPerms::READ | DirPerms::MUTATE, FilePerms::READ | FilePerms::WRITE, )?; // WASI 0.2 contexts must not expose host network without outbound domain mediation Ok(builder.build()) } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: WASI 0.2 Component Model Capability Isolation Standard

WASI 0.2 Component Model Capability Isolation Standard defines an industrial-grade behavioral standard for security engineering. Enforces strict principle-of-least-privilege capability passing for WASI 0.2 dynamic tenant plugins via Wasmtime/Wasm-tools runtime bindings. Mandates virtualized in-memory root filesystems without host directory passthroughs, explicit outbound HTTP authority delegation, and complete isolation of clocks, environment variables, and pre-opened descriptor handles. 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 Host Capability Leaks via Default WasiCtxBuilder and Inherited Descriptors 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 Host Capability Leaks via Default WasiCtxBuilder and Inherited Descriptors	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 tenant `WasiCtx` instances with zero ambient authority, explicitly populating only isolated in-memory or strictly scoped tenant subdirectories via `wasi

Engineers MUST ALWAYS construct tenant `WasiCtx` instances with zero ambient authority, explicitly populating only isolated in-memory or strictly scoped tenant subdirectories via `wasi:filesystem/preopens`.

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.