AgentRules.org
RulesStacksClientsAuditorPrunerSelf-HealRFCsBenchmarkCLICI/CDAuthorsSubmit
This specification is maintained by the AgentRules Working Group. Have enhancements or want to claim maintainership?Submit Specification →
backendcritical PriorityID: go-wasi-reactor-memory-ceiling-isolation

Deterministic Linear Memory Ceiling and Page-Growth Hard Boundary Guardrail for WASI Reactors

Enforces strict compile-time and runtime linear memory limits on untrusted multitenant WebAssembly reactor instances running on Go 1.24 runtimes (such as wazero). Prevents host OOM panics and tenant starvation by bounding initial and maximum WebAssembly page allocations and intercepting runtime dynamic growth requests. Guarantees deterministic failure semantics when guest modules exceed deterministic execution quotas.

Prohibited Anti-Pattern: Unbounded WASM linear memory growth permitting untrusted tenant guest modules to trigger host-level out-of-memory crashes.

Export Ready-to-Drop Configuration

Select format below to copy code or download file directly.

---
description: Deterministic Linear Memory Ceiling and Page-Growth Hard Boundary Guardrail for WASI Reactors - Enforces strict compile-time and runtime linear memory limits on untrusted multitenant WebAssembly reactor instances running on Go 1.24 runtimes (such as wazero). Prevents host OOM panics and tenant starvation by bounding initial and maximum WebAssembly page allocations and intercepting runtime dynamic growth requests. Guarantees deterministic failure semantics when guest modules exceed deterministic execution quotas.
globs: pkg/**/*.go, internal/**/*.go, **/*wasm*.go
alwaysApply: true
verified_by: "agentrules.org"
license: "CC-BY-4.0"
source: "https://agentrules.org/rules/go-wasi-reactor-memory-ceiling-isolation"
---

# Deterministic Linear Memory Ceiling and Page-Growth Hard Boundary Guardrail for WASI Reactors

> **Severity**: CRITICAL | **Category**: backend
> **Anti-Pattern Warning**: Unbounded WASM linear memory growth permitting untrusted tenant guest modules to trigger host-level out-of-memory crashes.

## System Constraints
You are a Principal Systems Architect enforcing Go 1.24 WASI Reactor Memory Ceiling Isolation Barriers. Untrusted guest WebAssembly modules MUST never be permitted to dynamically grow linear memory beyond pre-allocated host quotas, nor may they inherit unmetered host resources. You must mandate deterministic memory bounds, pool reuse protections, and explicit page limits on all wazero/wasm runtime instantiations.

## Strict Guidelines
- Engineers MUST ALWAYS set explicit runtime Page Limits (Min and Max) in runtime configurations, bounding WASM 64KiB pages strictly to tenant SLA boundaries.
- Engineers MUST NOT instantiate untrusted guest modules using default ModuleConfig or Memory limits without an explicit MemoryLimitPages cap.
- Code SHOULD leverage runtime memory wrappers or custom allocators to track cumulative guest allocations before invoking exported WASI reactor entrypoints.
- Services MUST evict, terminate, and cleanly close module instances immediately upon encountering an ErrMemoryOutOfBounds or allocation-limit breach.
- Components NEVER share mutable linear memory or WASI state across concurrent goroutines or across discrete tenant contexts.

## Bad vs Good Implementations
### Configuring Hard Memory Ceilings and Reactor Isolation in Go (wazero)

#### Bad Antipattern (AI Common Hallucination)
> **Why it fails**: Omitting explicit memory bounds on module compilation or instance configuration enables untrusted guest code to execute memory.grow instructions arbitrarily, leading to uncontained host memory exhaustion and denial of service.
```go
package runtime

import (
	"context"
	"github.com/tetratelabs/wazero"
)

func InstantiateUntrustedPlugin(ctx context.Context, r wazero.Runtime, wasmBytes []byte) (wazero.CompiledModule, error) {
	// BAD: Compiles and instantiates without linear memory ceilings or growth limits.
	// A malicious guest can execute memory.grow until host exhausts system RAM.
	return r.CompileModule(ctx, wasmBytes)
}
```

#### Production Standard (Correct)
> **Standard**: Statically inspects and enforces an immutable hard ceiling (16 MiB) on imported and exported WASM linear memory declarations before module initialization, completely preventing unbounded dynamic page allocation.
```go
package runtime

import (
	"context"
	"errors"
	"fmt"
	"github.com/tetratelabs/wazero"
)

const (
	WasmPageSize    = 65536 // 64 KiB
	MaxMemoryPages  = 256   // 16 MiB strict ceiling per tenant reactor
)

var ErrQuotaExceeded = errors.New("guest linear memory allocation exceeded quota")

func InstantiateUntrustedReactor(ctx context.Context, r wazero.Runtime, wasmBytes []byte) (wazero.CompiledModule, error) {
	cm, err := r.CompileModule(ctx, wasmBytes)
	if err != nil {
		return nil, fmt.Errorf("compilation failure: %w", err)
	}

	// Enforce deterministic maximum memory ceiling across all module exports
	for _, mem := range cm.ImportedMemories() {
		if max, hasMax := mem.Max(); !hasMax || max > MaxMemoryPages {
			return nil, fmt.Errorf("%w: imported memory exceeds ceiling", ErrQuotaExceeded)
		}
	}
	for _, mem := range cm.ExportedMemories() {
		if max, hasMax := mem.Max(); !hasMax || max > MaxMemoryPages {
			return nil, fmt.Errorf("%w: exported memory exceeds ceiling", ErrQuotaExceeded)
		}
	}

	return cm, nil
}
```
Recommended MCP Servers (mcp-serverlist.com)

Equip agent with system tools to verify code for this stack.

WASM Binary & AST Security Linter
Validates WebAssembly binaries for dangerous imports, missing page limit definitions, and unbound dynamic growth instructions prior to host loading.
Recommended Agent Skills (askills.dev)

Ready-to-use executable skill functions tailored to this stack.

Wasm-Objdump Static Limit Verifier
CLI utility to disassemble and verify memory section boundaries and growth instructions within compiled tenant reactor binaries.
Architectural Specification & Invariant Rationale

Architectural Invariant Design: Deterministic Linear Memory Ceiling and Page-Growth Hard Boundary Guardrail for WASI Reactors

Deterministic Linear Memory Ceiling and Page-Growth Hard Boundary Guardrail for WASI Reactors defines an industrial-grade behavioral standard for backend engineering. Enforces strict compile-time and runtime linear memory limits on untrusted multitenant WebAssembly reactor instances running on Go 1.24 runtimes (such as wazero). Prevents host OOM panics and tenant starvation by bounding initial and maximum WebAssembly page allocations and intercepting runtime dynamic growth requests. Guarantees deterministic failure semantics when guest modules exceed deterministic execution quotas. 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: Unbounded WASM linear memory growth permitting untrusted tenant guest modules to trigger host-level out-of-memory crashes. 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 ModeAI Symptom (The Anti-Pattern)SeverityProduction Impact & Remedy
AI Hallucination & Deprecation DriftUnbounded WASM linear memory growth permitting untrusted tenant guest modules to trigger host-level out-of-memory crashes.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 InconsistencyAI 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:

1

Engineers MUST ALWAYS set explicit runtime Page Limits (Min and Max) in runtime configurations, bounding WASM 64KiB pages strictly to tenant SLA boundaries.

Engineers MUST ALWAYS set explicit runtime Page Limits (Min and Max) in runtime configurations, bounding WASM 64KiB pages strictly to tenant SLA boundaries.

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.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
2

Engineers MUST NOT instantiate untrusted guest modules using default ModuleConfig or Memory limits without an explicit MemoryLimitPages cap.

Engineers MUST NOT instantiate untrusted guest modules using default ModuleConfig or Memory limits without an explicit MemoryLimitPages cap.

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.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
3

Code SHOULD leverage runtime memory wrappers or custom allocators to track cumulative guest allocations before invoking exported WASI reactor entrypoints.

Code SHOULD leverage runtime memory wrappers or custom allocators to track cumulative guest allocations before invoking exported WASI reactor entrypoints.

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.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
4

Services MUST evict, terminate, and cleanly close module instances immediately upon encountering an ErrMemoryOutOfBounds or allocation-limit breach.

Services MUST evict, terminate, and cleanly close module instances immediately upon encountering an ErrMemoryOutOfBounds or allocation-limit breach.

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.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
5

Components NEVER share mutable linear memory or WASI state across concurrent goroutines or across discrete tenant contexts.

Components NEVER share mutable linear memory or WASI state across concurrent goroutines or across discrete tenant contexts.

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.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
Technical Questions & Answers

Frequently Asked Technical Questions

Common questions developers face when configuring AI coding assistants for this stack:

Q:Why is Deterministic Linear Memory Ceiling and Page-Growth Hard Boundary Guardrail for WASI Reactors critical for AI coding assistants?

Enforces strict compile-time and runtime linear memory limits on untrusted multitenant WebAssembly reactor instances running on Go 1.24 runtimes (such as wazero). Prevents host OOM panics and tenant starvation by bounding initial and maximum WebAssembly page allocations and intercepting runtime dynamic growth requests. Guarantees deterministic failure semantics when guest modules exceed deterministic execution quotas. Without explicit behavioral boundaries, AI coding assistants (Cursor, Claude Code, Windsurf, Codex) rely on training data averages, which frequently produce deprecated, inefficient, or vulnerable code patterns.

Q:How does adopting this rule prevent AI hallucinations?

This rule explicitly declares what the AI must avoid (Unbounded WASM linear memory growth permitting untrusted tenant guest modules to trigger host-level out-of-memory crashes.) and prescribes verified positive examples. Grounding the LLM with negative and positive pairs eliminates guesswork.

Q:Which AI coding environments are supported?

This specification is multi-platform compatible: Cursor (.cursor/rules/*.mdc & .cursorrules), Anthropic Claude Code (CLAUDE.md), Windsurf (.windsurfrules), Codex / Cline (AGENTS.md), and GitHub Copilot (.github/copilot-instructions.md).

Q:Can I combine this rule with other technology stacks?

Yes. Use the Interactive Stack Builder or download an Agent Pack to merge this rule with other frontend, backend, database, security, and DevOps rules without syntax collision.

Open Specification · CC BY 4.0·Free for Personal, Team & Commercial In-Repo Use

Citation & Open Source Attribution Guidelines

This specification is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). You are completely free to adapt and share this rule in your workspace. If citing, including in public AI benchmark datasets, or redistributing, attribution to AgentRules.org is required.

Related BACKEND Rules

View all rules →
backend
42

Fastify 5 Schema Compilers & Encapsulation Production Standard

Fastify relies on lexical encapsulation contexts to sandbox decorators, hooks, and compiled validation/serialization schemas without memory leaks or cross-tenant bleed. In Fastify 5, misuse of global compilers or failing to encapsulate plugin boundaries causes compiled `fast-json-stringify` serializers and Ajv validators to either crash on duplicate IDs, leak private data across sibling scopes, or bypass JIT compilation optimizations. Production services must enforce strict encapsulation hierarchies and type-safe schema compilation across every routing subtree.

backend
68

Bun Embedded SQLite WAL Mode & Transaction Synchronization Standard

Production database standard for bun:sqlite. Mandates enabling Write-Ahead Logging (PRAGMA journal_mode = WAL), busy timeouts, and using db.transaction() for atomic operations without lock starvation.

backend
68

Drizzle ORM Batch API & Interactive Transaction Isolation Standard

Production database standard for Drizzle ORM (PostgreSQL & MySQL). Mandates using db.batch() over HTTP drivers to prevent round-trip waterfalls, explicit db.transaction() with serializable/read-committed isolation, and strictly avoids unawaited query promises.

1 Rule in Stack

Deterministic