Deterministic Capability-Based WASI 0.2 Sandboxing for Multi-Tenant Runtimes

--- description: Deterministic Capability-Based WASI 0.2 Sandboxing for Multi-Tenant Runtimes - Enforces strict capability-based isolation for WASI 0.2 (Preview 2) Component Model runtimes embedded in multi-tenant services. Mandates zero ambient authority inheritance by forbidding default host filesystem, socket, and stdio bindings, requiring isolated per-tenant WasiCtx instances with explicit resource table quotas, fuel limits, and epoch interruption. globs: crates/**/sandbox/**/*.rs, crates/**/plugin/**/*.rs, src/wasm/**/*.rs, src/plugins/**/*.rs alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/wasi-p2-component-sandbox-security" --- # Deterministic Capability-Based WASI 0.2 Sandboxing for Multi-Tenant Runtimes > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Ambient Authority Leakage via Unrestricted WASI Context and Inherited Host Capabilities ## System Constraints You are a Principal Security Architect and Systems Engineer specializing in WebAssembly and the WASI 0.2 Component Model. You enforce zero-trust, capability-based security boundaries for guest plugins executing inside multi-tenant backend hosts. Ensure zero ambient authority leakage, enforce deterministic fuel/epoch limits, and forbid shared mutable state across tenant instances. ## Strict Guidelines - Engineers MUST NOT call `inherit_all()`, `inherit_network()`, or `inherit_stdio()` on `WasiCtxBuilder` in multi-tenant execution paths. - Engineers MUST construct a fresh, discrete `WasiCtx` per tenant execution, scoped strictly through explicit virtualized filesystem capabilities and preopened directory mappings. - Preopened directories MUST be constrained to tenant-isolated chroot prefixes or in-memory virtual paths; host roots (`/` or `C:\`) MUST NEVER be mapped directly. - Network access MUST be restricted by replacing default `wasi:sockets` implementations with an allowlist-enforcing proxy or explicit denial hooks (`SocketAddrCheck`). - Host runtimes MUST configure both synchronous `Fuel` consumption tracking and asynchronous `EpochInterruption` on the Wasmtime `Engine` and `Store` to eliminate algorithmic complexity and infinite-loop DoS attacks. - Guest-host resource tables (`ResourceTable`) MUST be configured with strict maximum capacity ceilings to prevent host file-descriptor exhaustion via unbounded handles. - Every dynamic component instantiation MUST use an immutable `Linker` cache while instantiating isolated `Store<T>` instances holding distinct tenant-bounded state structs. ## Bad vs Good Implementations ### WASI 0.2 Capability-Based Context Builder and Store Configuration #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Using `inherit_all()` grants untrusted tenant plugins ambient authority over host stdio, host environment variables, and host networking. Binding a root directory without capability fencing and failing to enable fuel or epoch interruption permits filesystem traversal, SSRF, host information disclosure, and unconstrained denial-of-service. ```rust use wasmtime::component::Linker; use wasmtime::{Engine, Store}; use wasmtime_wasi::preview2::{WasiCtx, WasiCtxBuilder, WasiView}; struct HostState { ctx: WasiCtx } impl WasiView for HostState { fn ctx(&mut self) -> &mut WasiCtx { &mut self.ctx } } pub fn run_tenant_plugin(engine: &Engine, tenant_dir: &str) -> anyhow::Result<()> { // DANGEROUS: Ambient inheritance grants tenant access to host stdio, host network, and host disk let mut builder = WasiCtxBuilder::new(); builder.inherit_all(); // Leaks host stdin/stdout, environment variables, and network builder.preopened_dir(tenant_dir, "/", wasmtime_wasi::DirPerms::all(), wasmtime_wasi::FilePerms::all())?; let mut store = Store::new(engine, HostState { ctx: builder.build() }); // Missing fuel metering and epoch interruption: vulnerable to CPU exhaustion DoS Ok(()) } ``` #### Production Standard (Correct) > **Standard**: Constructs an isolated, capability-secured WASI 0.2 runtime using cap-std preopened directories without ambient authority. Implements explicit linear memory caps via StoreLimits, deterministic CPU execution bounds via fuel consumption, and asynchronous timeout defense via epoch deadlines. ```rust use std::sync::Arc; use std::time::Duration; use wasmtime::component::Linker; use wasmtime::{Engine, Store, StoreLimits, StoreLimitsBuilder}; use wasmtime_wasi::preview2::{DirPerms, FilePerms, ResourceTable, WasiCtx, WasiCtxBuilder, WasiView}; use cap_std::fs::Dir; struct TenantContext { wasi_ctx: WasiCtx, table: ResourceTable, limits: StoreLimits, } impl WasiView for TenantContext { fn ctx(&mut self) -> &mut WasiCtx { &mut self.wasi_ctx } fn table(&mut self) -> &mut ResourceTable { &mut self.table } } pub fn build_isolated_store( engine: &Engine, isolated_dir: Dir, fuel_limit: u64, ) -> anyhow::Result<Store<TenantContext>> { let mut wasi_builder = WasiCtxBuilder::new(); // Explicit capability: Preopen only the isolated tenant directory with restricted permissions wasi_builder.preopened_dir(isolated_dir, DirPerms::READ | DirPerms::MUTATE, FilePerms::READ | FilePerms::WRITE, "/sandbox")?; // Zero ambient authority: no stdio inheritance, no host sockets, isolated memory streams only let wasi_ctx = wasi_builder.build(); let table = ResourceTable::new(); // Resource quotas and memory limits let limits = StoreLimitsBuilder::new() .memory_size(64 * 1024 * 1024) // 64 MB maximum linear memory per tenant .instances(5) .tables(10) .build(); let mut store = Store::new(engine, TenantContext { wasi_ctx, table, limits }); // Enable deterministic execution bounds store.set_fuel(fuel_limit)?; store.set_epoch_deadline(1); store.limiter(|state| &mut state.limits); Ok(store) } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Deterministic Capability-Based WASI 0.2 Sandboxing for Multi-Tenant Runtimes

Deterministic Capability-Based WASI 0.2 Sandboxing for Multi-Tenant Runtimes defines an industrial-grade behavioral standard for security engineering. Enforces strict capability-based isolation for WASI 0.2 (Preview 2) Component Model runtimes embedded in multi-tenant services. Mandates zero ambient authority inheritance by forbidding default host filesystem, socket, and stdio bindings, requiring isolated per-tenant WasiCtx instances with explicit resource table quotas, fuel limits, and epoch interruption. 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 Unrestricted WASI Context and Inherited Host Capabilities 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 Unrestricted WASI Context and Inherited Host Capabilities	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 NOT call `inherit_all()`, `inherit_network()`, or `inherit_stdio()` on `WasiCtxBuilder` in multi-tenant execution paths.

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.