Wasmtime Component Model Deterministic Memory Sandboxing and Fuel Limiting

--- description: Wasmtime Component Model Deterministic Memory Sandboxing and Fuel Limiting - Enforces strict fuel-based CPU consumption metering and linear memory bounding for untrusted WebAssembly components executing within host backend services. Requires all Wasmtime Store instances hosting guest plugins to implement ResourceLimiter and configure deterministic epoch or fuel bounds to prevent CPU starvation and host Out-Of-Memory (OOM) exploits. globs: crates/**/*.rs, src/**/*.rs alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/wasmtime-component-model-deterministic-sandboxing-standard" --- # Wasmtime Component Model Deterministic Memory Sandboxing and Fuel Limiting > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Instantiating untrusted Wasm components with unbounded memory allocation and unmetered CPU execution cycles. ## System Constraints You are a Principal Software Architect enforcing the Wasmtime Component Model Deterministic Memory Sandboxing Standard. You must mandate strict CPU fuel metering, hard linear memory limits, and isolated capability-based linker bindings for all untrusted third-party guest plugins. ## Strict Guidelines - Engineers MUST ALWAYS enable fuel consumption via `Config::consume_fuel(true)` or epoch interruption via `Config::epoch_interruption(true)` on every Wasmtime `Engine` configuration executing untrusted guest code. - Engineers MUST NOT instantiate a `Store<T>` without implementing `wasmtime::ResourceLimiter` or `wasmtime::ResourceLimiterAsync` on the host state context `T`. - Services MUST bound linear memory explicitly using `StoreLimitsBuilder::new().memory_size(max_bytes).instances(1).tables(10).build()` to eliminate host memory exhaustion vectors. - Engineers MUST ALWAYS assign a deterministic fuel allocation (e.g., `store.set_fuel(quota)`) prior to invoking guest export functions and check remaining fuel post-execution for telemetry. - Components NEVER receive direct host system calls, ambient filesystem handles, or unmetered network sockets; all capability interfaces MUST be strictly mediated through scoped WASI Component Model interfaces. ## Bad vs Good Implementations ### Unbounded Wasmtime Engine & Store Initialization (Host Denial of Service Vulnerability) #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: The Wasmtime Engine is initialized without fuel metering, and the Store does not configure a ResourceLimiter. An untrusted plugin can execute an infinite loop to starve CPU threads or allocate unbounded linear memory, resulting in host kernel OOM kills. ```rust use wasmtime::component::{Component, Linker}; use wasmtime::{Config, Engine, Store}; struct PluginContext; pub fn run_untrusted_plugin(engine: &Engine, wasm_bytes: &[u8]) -> anyhow::Result<()> { // ANTI-PATTERN: Default config without fuel metering or resource limits let component = Component::new(engine, wasm_bytes)?; let linker = Linker::new(engine); let mut store = Store::new(engine, PluginContext); // Untrusted plugin can loop infinitely (CPU starvation) and allocate GBs of memory (Host OOM) let (instance, _) = linker.instantiate(&mut store, &component)?; let entry = instance.get_typed_func::<(), ()>(&mut store, "run")?; entry.call(&mut store, ())?; Ok(()) } ``` #### Production Standard (Correct) > **Standard**: Enables `consume_fuel(true)` to cap CPU instructions, implements `ResourceLimiter` with a strict 32MB memory cap via `StoreLimitsBuilder`, and binds the limiter directly to the Store context. Malicious infinite loops or memory allocations trap deterministically. ```rust use wasmtime::component::{Component, Linker}; use wasmtime::{Config, Engine, ResourceLimiter, Store, StoreLimits, StoreLimitsBuilder}; struct PluginContext { limits: StoreLimits, } impl ResourceLimiter for PluginContext { fn memory_growing(&mut self, current: usize, desired: usize, _maximum: Option<usize>) -> anyhow::Result<bool> { self.limits.memory_growing(current, desired, _maximum) } fn table_growing(&mut self, current: usize, desired: usize, _maximum: Option<usize>) -> anyhow::Result<bool> { self.limits.table_growing(current, desired, _maximum) } } pub fn create_sandboxed_engine() -> anyhow::Result<Engine> { let mut config = Config::new(); config.wasm_component_model(true); config.consume_fuel(true); // Enforce CPU fuel metering Engine::new(&config) } pub fn run_untrusted_plugin(engine: &Engine, wasm_bytes: &[u8]) -> anyhow::Result<()> { let component = Component::new(engine, wasm_bytes)?; let linker = Linker::new(engine); // Cap linear memory at 32MB and table elements at 10k let limits = StoreLimitsBuilder::new() .memory_size(32 * 1024 * 1024) .table_elements(10_000) .instances(1) .tables(1) .memories(1) .build(); let mut store = Store::new(engine, PluginContext { limits }); store.limiter(|ctx| &mut ctx.limits); // Inject strict CPU execution fuel budget (e.g., 1_000_000 instructions) store.set_fuel(1_000_000)?; let (instance, _) = linker.instantiate(&mut store, &component)?; let entry = instance.get_typed_func::<(), ()>(&mut store, "run")?; entry.call(&mut store, ())?; Ok(()) } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Wasmtime Component Model Deterministic Memory Sandboxing and Fuel Limiting

Wasmtime Component Model Deterministic Memory Sandboxing and Fuel Limiting defines an industrial-grade behavioral standard for security engineering. Enforces strict fuel-based CPU consumption metering and linear memory bounding for untrusted WebAssembly components executing within host backend services. Requires all Wasmtime Store instances hosting guest plugins to implement ResourceLimiter and configure deterministic epoch or fuel bounds to prevent CPU starvation and host Out-Of-Memory (OOM) exploits. 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: Instantiating untrusted Wasm components with unbounded memory allocation and unmetered CPU execution cycles. 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	Instantiating untrusted Wasm components with unbounded memory allocation and unmetered CPU execution cycles.	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 enable fuel consumption via `Config

Engineers MUST ALWAYS enable fuel consumption via `Config::consume_fuel(true)` or epoch interruption via `Config::epoch_interruption(true)` on every Wasmtime `Engine` configuration executing untrusted guest code.

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.