Sandboxed AI Tools & Plugins

Introduction and mental model

An AI tool is executable code at a trust boundary. The model may propose a tool and interpret its result, but authority, validation, computation, and enforcement belong to deterministic software.

The governing principle is: the model interprets and chooses; deterministic code calculates and verifies. A WebAssembly Component makes the callable contract typed; a WIT world makes required capabilities visible; the host grants only those imports and enforces memory, compute, time, and state budgets. Sandboxing reduces authority and blast radius, but it does not make arbitrary code or an unsafe host automatically safe.

Why it matters

Tool-using agents turn model mistakes and prompt injection into real actions. Native plugins often inherit ambient filesystem, network, process, and credential access from their host. Wasm can provide a smaller execution boundary with explicit interfaces, portable binaries, deterministic fixtures, and runtime-enforced limits.

The important artifact is not merely a .wasm file. It is a reviewed tuple of binary, WIT contract, capability policy, resource budget, provenance, version, and expected behavior.

Questions this branch answers

• Which values and errors belong in a stable typed tool contract?
• How can a host deny filesystem, network, clock, randomness, or secrets by default?
• Which capabilities should be statically declared and which require per-call approval?
• How are memory limits, fuel, epoch deadlines, timeouts, output size, and concurrency enforced?
• When must a tool be deterministic, idempotent, stateful, or explicitly non-repeatable?
• How should binaries, WIT packages, policies, and signatures be versioned together?
• What evidence lets an operator distinguish model choice from deterministic calculation?
• How are malformed input, budget exhaustion, traps, and denied capabilities reported safely?

Scope

• WebAssembly Components and WIT contracts for typed tool inputs, outputs, and errors.
• Deny-by-default host capability policy for filesystem, network, clocks, randomness, and secrets.
• Per-tool and per-invocation memory, compute, time, output, and concurrency budgets.
• Fuel metering, epoch interruption, host deadlines, cancellation, and trap handling.
• Determinism, idempotency, stateful resources, and explicit persistence boundaries.
• Component identity, checksums, versions, provenance, signatures, and policy compatibility.
• Agent-to-tool selection, argument validation, human approval, invocation, and audit separation.
• Fuzzing, adversarial fixtures, capability-denial tests, and supply-chain review.

Out of scope

• Agent planning, memory, prompting, or general model alignment.
• Treating sandboxing as a defense against every host bug, runtime vulnerability, or side channel.
• Running untrusted native libraries outside the Wasm boundary.
• Granting ambient network or filesystem access for developer convenience.
• Letting model-generated text define executable policy at runtime.
• Claiming deterministic results when tools depend on undeclared time, randomness, external state, or floating-point variation.

Expected outcomes

After this branch, a reader should be able to define a least-authority WIT world for a tool, separate model interpretation from deterministic execution, configure resource budgets, and design an auditable invocation state machine. They should be able to prove that denied capabilities remain unavailable, distinguish policy rejection from a guest trap, and reproduce a tool result from versioned input, binary, contract, and host data.

Candidate note roadmap

• typed-ai-tool-contracts-in-wit — design narrow inputs, outputs, variants, and failure semantics.
• capability-oriented-host-design — translate a WIT world into deny-by-default runtime authority.
• fuel-epoch-time-memory-and-output-budgets — bound each invocation and classify exhaustion correctly.
• filesystem-network-secrets-and-approval-policy — separate unavailable, pre-granted, and human-approved capabilities.
• determinism-idempotency-and-stateful-resources — define replay and persistence contracts explicitly.
• component-versioning-provenance-and-policy-compatibility — bind binary, WIT, policy, checksum, and release metadata.
• agent-tool-selection-validation-and-audit — keep probabilistic choice distinct from deterministic execution records.
• fuzzing-adversarial-inputs-and-sandbox-escape-testing — test parser, budget, capability, and host-boundary failures.

Future runnable artifact

Build a WasmAI Workbench tool host where every tool is a versioned WebAssembly Component with a WIT contract and a separate capability manifest. The initial future tool set will cover deterministic calculation, document parsing, JSON validation, and scoring. Each invocation will validate typed input, pin component and policy versions, apply memory, fuel, deadline, output-size, and concurrency limits, deny network and filesystem unless explicitly granted, and emit a structured audit record.

An optional local agent may choose which registered tool to request, but it cannot alter the capability policy or accept an unverified binary. The host performs argument validation, approval checks, execution, output verification, and result classification. Golden fixtures must be runnable without any model so the deterministic layer can be tested independently.

How to verify and measure

• Inspect each WIT world and prove that undeclared capabilities cannot be reached by the component.
• Test no-access, approved-access, denied-access, malformed-input, trap, timeout, fuel exhaustion, and memory-limit paths.
• Replay identical deterministic inputs and compare typed outputs plus checksums across supported hosts.
• Fuzz serialized inputs, boundary lengths, parser states, error variants, and oversized outputs.
• Record component hash, WIT package version, policy version, runtime, budgets, duration, peak memory, result class, and output hash.
• Verify that model logs show only tool selection and interpretation, while host logs prove validation, authorization, execution, and verification.
• Test rollback and revocation so a compromised component or policy version cannot remain silently active.

Primary sources

• WebAssembly Component Model specification repository — primary component and Canonical ABI specification work; evolving, consulted 2026-07-16.
• WIT reference — authoritative interface-language guide for typed contracts; consulted 2026-07-16.
• WIT worlds — official explanation of imports, exports, and capability boundaries; consulted 2026-07-16.
• WebAssembly/WASI repository — primary host-interface and capability source; baseline and runtime support must be pinned, consulted 2026-07-16.
• Wasmtime Store API — official implementation reference for fuel and epoch interruption; version-sensitive, consulted 2026-07-16.
• WebAssembly Core Specification — primary semantics for validation, execution, memory, and traps; living specification, consulted 2026-07-16.
• SLSA specification — primary supply-chain provenance framework used to reason about component build and release evidence; evolving specification, consulted 2026-07-16.

Connects to: WASI, Components & WASI-NN · WebAssembly Execution Model · Linear Memory, ABI & Host Interop · Browser LLMs, Embeddings & RAG · Wasm AI Performance, Security & Craftsmanship