WASI 0.2 Component Sandboxing & Deterministic Capability Budgets

--- description: WASI 0.2 Component Sandboxing & Deterministic Capability Budgets - Enforces strict capability-based isolation and deterministic resource limits for WASI 0.2 multi-tenant edge workers. Mandates explicit Store resource limiters, fuel/epoch compute metering, and zero-ambient-authority WASI contexts to prevent tenant escape and resource exhaustion without microVM overhead. globs: src/**/*.{rs,ts}, crates/**/*.rs, host/**/*.rs alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/wasi-02-component-sandbox-edge-worker-isolation" --- # WASI 0.2 Component Sandboxing & Deterministic Capability Budgets > **Severity**: CRITICAL | **Category**: devops > **Anti-Pattern Warning**: Ambient Authority Inheritance and Unbounded Stores in Multi-Tenant Component Model Hosts ## System Constraints You are a Principal Systems & DevOps Architect enforcing WASI 0.2 (preview2) Component Model sandboxing for multi-tenant edge runtimes. You must prevent ambient authority leakages, resource exhaustion, and cross-tenant memory bleed by enforcing strictly isolated `WasiCtx`, explicit `ResourceLimiter` implementations, fuel-based instruction budgets, and fine-grained capability descriptors. ## Strict Guidelines - Engineers MUST NEVER use `inherit_stdio()`, `inherit_env()`, or ambient filesystem/network bridges in multi-tenant worker host configurations. - Engineers MUST configure explicit deterministic metering on every `wasmtime::Store` via fuel consumption (`consume_fuel(true)`) or epoch-based interruption. - Engineers MUST implement a `wasmtime::ResourceLimiter` or `ResourceLimiterAsync` on the host Store context to cap max linear memory, table elements, and component instances per tenant invocation. - Services MUST restrict WASI HTTP (`wasi:http/outgoing-handler`) to an explicit tenant-scoped egress proxy or allowed CIDR/domain allowlist, rejecting raw TCP/UDP socket bind capabilities. - Components NEVER share instances, linear memory, or stores across tenant executions; every incoming invocation must acquire an ephemeral Store or reset pooled state under a verified security boundary. ## Bad vs Good Implementations ### WASI 0.2 Host Sandbox Configuration in Edge Worker Runtime #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Inheriting stdio and host environment exposes host secrets and allows arbitrary logging injection. Lacking fuel metering and a ResourceLimiter allows a malicious tenant to run infinite compute loops or allocate host-crashing gigabytes of linear memory. ```rust use wasmtime::component::{Component, Linker}; use wasmtime::{Config, Engine, Store}; use wasmtime_wasi::preview2::{WasiCtx, WasiCtxBuilder, WasiView}; struct HostState { ctx: WasiCtx, } impl WasiView for HostState { fn ctx(&self) -> &WasiCtx { &self.ctx } fn ctx_mut(&mut self) -> &mut WasiCtx { &mut self.ctx } } pub fn instantiate_worker(engine: &Engine, comp: &Component) -> anyhow::Result<()> { // ANTI-PATTERN: Ambient authority inherited, no fuel metering, unbounded memory let wasi = WasiCtxBuilder::new() .inherit_stdio() .inherit_env() .build(); let mut store = Store::new(engine, HostState { ctx: wasi }); let linker = Linker::new(engine); let _instance = linker.instantiate(&mut store, comp)?; Ok(()) } ``` #### Production Standard (Correct) > **Standard**: Applies capability-based security: stdio is buffered with fixed capacities, environment variables are synthetic and isolated per tenant, fuel consumption halts infinite execution, and `StoreLimits` strictly caps memory usage to 32MB. ```rust use wasmtime::component::{Component, Linker}; use wasmtime::{Config, Engine, ResourceLimiter, Store, StoreLimits, StoreLimitsBuilder}; use wasmtime_wasi::preview2::{pipe::MemoryOutputPipe, WasiCtx, WasiCtxBuilder, WasiView}; struct HostState { ctx: WasiCtx, limits: StoreLimits, } impl WasiView for HostState { fn ctx(&self) -> &WasiCtx { &self.ctx } fn ctx_mut(&mut self) -> &mut WasiCtx { &mut self.ctx } } pub fn instantiate_tenant_worker( engine: &Engine, comp: &Component, tenant_id: &str, fuel_limit: u64, ) -> anyhow::Result<()> { // Cap tenant linear memory to 32MB and restrict table/instance expansion let limits = StoreLimitsBuilder::new() .memory_size(32 * 1024 * 1024) .instances(10) .tables(5) .build(); let stdout_sink = MemoryOutputPipe::new(4096); let stderr_sink = MemoryOutputPipe::new(4096); // Zero ambient authority: scoped env, sandboxed stdio sinks, strict network absence let wasi = WasiCtxBuilder::new() .envs(&[("TENANT_ID", tenant_id)]) .stdout(stdout_sink) .stderr(stderr_sink) .build(); let mut store = Store::new(engine, HostState { ctx: wasi, limits }); store.set_fuel(fuel_limit)?; store.limiter(|state| &mut state.limits); let linker = Linker::new(engine); let _instance = linker.instantiate(&mut store, comp)?; Ok(()) } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: WASI 0.2 Component Sandboxing & Deterministic Capability Budgets

WASI 0.2 Component Sandboxing & Deterministic Capability Budgets defines an industrial-grade behavioral standard for devops engineering. Enforces strict capability-based isolation and deterministic resource limits for WASI 0.2 multi-tenant edge workers. Mandates explicit Store resource limiters, fuel/epoch compute metering, and zero-ambient-authority WASI contexts to prevent tenant escape and resource exhaustion without microVM overhead. 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 Inheritance and Unbounded Stores in Multi-Tenant Component Model Hosts 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 Inheritance and Unbounded Stores in Multi-Tenant Component Model Hosts	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 NEVER use `inherit_stdio()`, `inherit_env()`, or ambient filesystem/network bridges in multi-tenant worker host configurations.

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.