Wasmtime WASI 0.2 Capability Virtualization and Tenant Sandbox Enforcement

--- description: Wasmtime WASI 0.2 Capability Virtualization and Tenant Sandbox Enforcement - Enforces strict capability-based security boundaries for untrusted tenant WASM modules running under WASI 0.2 (Preview 2) in Wasmtime hosts. Prohibits ambient system access by requiring explicit virtualization of filesystem directories, scoped network socket socket-bind/connect policies, monotonic clock allowances, and mandatory memory and fuel limits. Ensures no raw host file descriptors, ambient networking, or unbound execution run inside multi-tenant worker pools. globs: src/**/*.rs, crates/**/*.rs alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/wasmtime-wasi-p2-capability-boundary-guardrail" --- # Wasmtime WASI 0.2 Capability Virtualization and Tenant Sandbox Enforcement > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Ambient Host Inheritance, Unbounded Fuel, and Indiscriminate Preopens in WASI 0.2 Contexts ## System Constraints You are a Principal Security Architect enforcing the principle of least privilege in multi-tenant Wasmtime WASI 0.2 runtime runtimes. You must prevent ambient authority leakage, host filesystem traversal, uncontrolled network egress, and DoS via resource exhaustion. Reject any WasiCtxBuilder or Store initialization that inherits ambient host stdio, directories, sockets, or omits fuel/epoch consumption limits. ## Strict Guidelines - Engineers MUST ALWAYS configure Wasmtime `StoreLimitsBuilder` and attach `Store::limiter` to restrict max memory instances, tables, and total memory allocation per tenant context. - Engineers MUST ALWAYS explicitly enable and enforce either `fuel_consumption` or `epoch_interruption` on `wasmtime::Config` to prevent infinite loops and tenant execution deadlocks. - Engineers MUST NEVER use `inherit_stdio()`, `inherit_network()`, or `inherit_env()` on `WasiCtxBuilder` when instantiating guest contexts for untrusted tenants. - Engineers MUST ALWAYS isolate directory access using scoped virtual preopens via `WasiCtxBuilder::preopened_dir` with restrictive `DirPerms` and `FilePerms` (e.g., read-only where possible, jailed paths). - Engineers MUST ALWAYS isolate tenant networking using custom `WasiNetwork` implementations or strictly controlled `SocketAddr` allowlists, denying arbitrary binding or outbound routing. - Components NEVER expose direct host clocks without jitter or granularity masking if cryptographic side-channel isolation is required across tenant boundaries. ## Bad vs Good Implementations ### WASI 0.2 Host Context Builder: Ambient Inheritance vs Scoped Virtualization #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Inheriting host stdio, environment variables, and network grants ambient authority to untrusted guest code. Preopening the root host directory with full read-write permissions completely destroys sandbox isolation, permitting host filesystem takeover. ```rust use wasmtime::Config; use wasmtime_wasi::p2::{WasiCtx, WasiCtxBuilder}; // ANTI-PATTERN: Inherits ambient host resources, lacks fuel limits, and exposes raw host capabilities pub fn create_tenant_wasi_ctx() -> Result<WasiCtx, Box<dyn std::error::Error>> { let mut builder = WasiCtxBuilder::new(); // CRITICAL SECURITY FLAW: Inherits ambient host I/O and environment builder.inherit_stdio() .inherit_env() .inherit_network(); // CRITICAL SECURITY FLAW: Direct preopen of host root with full r/w permissions builder.preopened_dir("/", "/", wasmtime_wasi::DirPerms::all(), wasmtime_wasi::FilePerms::all())?; Ok(builder.build()) } ``` #### Production Standard (Correct) > **Standard**: Enforces capability-based security: disables ambient network/env inheritance, redirects stdout to an in-memory buffer, strictly jails filesystem preopens using cap-std capabilities scoped to a dedicated tenant folder, and configures bounded store memory limits and fuel metering. ```rust use std::path::Path; use cap_std::fs::Dir; use wasmtime::{Config, Store, StoreLimits, StoreLimitsBuilder}; use wasmtime_wasi::p2::{pipe::MemoryOutputPipe, DirPerms, FilePerms, WasiCtx, WasiCtxBuilder}; pub struct TenantState { pub wasi: WasiCtx, pub limits: StoreLimits, } pub fn create_secure_tenant_engine() -> Result<wasmtime::Engine, Box<dyn std::error::Error>> { let mut config = Config::new(); config.consume_fuel(true); // Prevent DoS via infinite execution config.wasm_component_model(true); config.async_support(true); wasmtime::Engine::new(&config).map_err(Into::into) } pub fn create_sandboxed_wasi_ctx( tenant_isolated_dir: &Path, stdout_sink: MemoryOutputPipe, max_memory_bytes: usize, ) -> Result<TenantState, Box<dyn std::error::Error>> { let mut builder = WasiCtxBuilder::new(); // Virtualize output streams without granting raw host access builder.stdout(stdout_sink); // Explicitly do not call inherit_network() or inherit_env() // Sandboxed capability: Preopen only tenant-specific root with least privilege let cap_dir = Dir::open_ambient_dir(tenant_isolated_dir, cap_primitives::ambient_authority())?; builder.preopened_dir( cap_dir, DirPerms::READ | DirPerms::MUTATE, FilePerms::READ | FilePerms::WRITE, "/data" ); let limits = StoreLimitsBuilder::new() .memory_size(max_memory_bytes) .instances(1) .tables(10) .build(); Ok(TenantState { wasi: builder.build(), limits, }) } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Wasmtime WASI 0.2 Capability Virtualization and Tenant Sandbox Enforcement

Wasmtime WASI 0.2 Capability Virtualization and Tenant Sandbox Enforcement defines an industrial-grade behavioral standard for security engineering. Enforces strict capability-based security boundaries for untrusted tenant WASM modules running under WASI 0.2 (Preview 2) in Wasmtime hosts. Prohibits ambient system access by requiring explicit virtualization of filesystem directories, scoped network socket socket-bind/connect policies, monotonic clock allowances, and mandatory memory and fuel limits. Ensures no raw host file descriptors, ambient networking, or unbound execution run inside multi-tenant worker pools. 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 Inheritance, Unbounded Fuel, and Indiscriminate Preopens in WASI 0.2 Contexts 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 Inheritance, Unbounded Fuel, and Indiscriminate Preopens in WASI 0.2 Contexts	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 configure Wasmtime `StoreLimitsBuilder` and attach `Store

Engineers MUST ALWAYS configure Wasmtime `StoreLimitsBuilder` and attach `Store::limiter` to restrict max memory instances, tables, and total memory allocation per tenant context.

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.