WASI 0.2 Capability-Based Sandbox Isolation and Resource Attenuation

--- description: WASI 0.2 Capability-Based Sandbox Isolation and Resource Attenuation - Enforces strict zero-ambient-authority capability derivation and deterministic resource attenuation for untrusted tenant guest components in WASI 0.2 edge runtimes. Mandates explicit capability binding, virtualized network/filesystem handles, strict epoch-based interruption, and dedicated per-tenant resource tables to mathematically prevent cross-tenant escape and resource exhaustion. globs: src/**/*.{rs,wit} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/wasi-0-2-component-model-capability-sandbox-isolation" --- # WASI 0.2 Capability-Based Sandbox Isolation and Resource Attenuation > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Ambient Host Resource Inheritance and Unmetered Dynamic Linking in WASI 0.2 Guest Runtimes ## System Constraints You are a Principal Systems Architect enforcing WASI 0.2 Component Model Capability-Based Edge Sandbox Isolation. Mandate zero ambient authority: untrusted guest components must never receive wholesale host system calls or unattenuated interfaces. Every component instance must receive custom, per-request virtualized WIT resources, explicit capability descriptors, strict epoch-based interruption, and bounded resource tables. ## Strict Guidelines - Engineers MUST NEVER link ambient host capabilities (e.g., WasiCtxBuilder::inherit_all() or raw host filesystem preopens) into untrusted tenant linkers. - Engineers MUST bind attenuated, virtualized implementations for all WASI interfaces (such as wasi:http/outgoing-handler and wasi:filesystem) to restrict guest access strictly to authorized namespaces. - Host runtimes MUST enforce deterministic compute bounds using epoch-based interruption or fuel metering on every guest call to prevent edge worker denial of service. - Host runtimes MUST instantiate a discrete ResourceTable and WasiCtx per invocation; reusing stateful tables or sharing resource pointers across tenants is STRICTLY PROHIBITED. - Engineers MUST configure explicit linear memory ceilings and component table limits within the engine configuration to prevent host memory exhaustion attacks. ## Bad vs Good Implementations ### Configuring WASI 0.2 Sandboxed Host Linker and Context #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Inheriting ambient environment variables, standard I/O, and raw host network access bypasses WASI 0.2 isolation guarantees, allowing untrusted tenant code to leak host secrets or make arbitrary outbound connections. ```rust use wasmtime::component::Linker; use wasmtime_wasi::preview2::{WasiCtx, WasiCtxBuilder, WasiView, ResourceTable}; struct HostState { ctx: WasiCtx, table: ResourceTable, } impl WasiView for HostState { fn ctx(&mut self) -> &mut WasiCtx { &mut self.ctx } fn table(&mut self) -> &mut ResourceTable { &mut self.table } } // ANTI-PATTERN: Inheriting ambient host resources and allowing unattenuated network/fs pub fn create_insecure_host_state() -> HostState { let mut builder = WasiCtxBuilder::new(); builder.inherit_stdio() .inherit_network() .inherit_env(); // Leaks host environment and grants raw network access HostState { ctx: builder.build(), table: ResourceTable::new(), } } ``` #### Production Standard (Correct) > **Standard**: Enforces mathematically sound capability isolation: ambient host privileges are stripped, memory ceilings are explicitly clamped, epoch interruption is enabled to halt runaway executions, and per-tenant resource tables prevent cross-tenant state bleeding. ```rust use wasmtime::{Config, Engine}; use wasmtime_wasi::preview2::{WasiCtx, WasiCtxBuilder, WasiView, ResourceTable}; use std::time::Duration; struct IsolatedTenantState { ctx: WasiCtx, table: ResourceTable, tenant_id: String, } impl WasiView for IsolatedTenantState { fn ctx(&mut self) -> &mut WasiCtx { &mut self.ctx } fn table(&mut self) -> &mut ResourceTable { &mut self.table } } // PRODUCTION FIX: Attenuated capabilities with strict limits and isolated resource tables pub fn create_sandboxed_tenant_state(tenant_id: String) -> IsolatedTenantState { let mut builder = WasiCtxBuilder::new(); // Zero ambient authority: no ambient fs, no host environment, no raw sockets // Network is mediated strictly via virtualized outbound HTTP or locked down entirely builder.env("TENANT_ID", &tenant_id); IsolatedTenantState { ctx: builder.build(), table: ResourceTable::default(), tenant_id, } } pub fn configure_secure_engine() -> Engine { let mut config = Config::new(); config.epoch_interruption(true); config.max_wasm_stack(512 * 1024); config.static_memory_maximum_size(16 * 1024 * 1024); // Cap linear memory at 16MB Engine::new(&config).expect("Failed to create secure wasmtime engine") } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: WASI 0.2 Capability-Based Sandbox Isolation and Resource Attenuation

WASI 0.2 Capability-Based Sandbox Isolation and Resource Attenuation defines an industrial-grade behavioral standard for security engineering. Enforces strict zero-ambient-authority capability derivation and deterministic resource attenuation for untrusted tenant guest components in WASI 0.2 edge runtimes. Mandates explicit capability binding, virtualized network/filesystem handles, strict epoch-based interruption, and dedicated per-tenant resource tables to mathematically prevent cross-tenant escape and resource exhaustion. 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 Resource Inheritance and Unmetered Dynamic Linking in WASI 0.2 Guest Runtimes 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 Resource Inheritance and Unmetered Dynamic Linking in WASI 0.2 Guest Runtimes	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 link ambient host capabilities (e.g., WasiCtxBuilder

Engineers MUST NEVER link ambient host capabilities (e.g., WasiCtxBuilder::inherit_all() or raw host filesystem preopens) into untrusted tenant linkers.

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.