Wiki · Concept · Last reviewed June 25, 2026

WebAssembly Component Model

The WebAssembly Component Model turns Wasm modules into typed, composable components, making plugin boundaries a governance surface for agents.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: webassembly, component model, wasi, agent sandboxing, plugin security

Definition

The WebAssembly Component Model is an architecture for building interoperable WebAssembly libraries, applications, and environments. The official documentation describes a component as a self-describing WebAssembly binary that interacts only through interfaces. Compared with a core WebAssembly module, a component carries richer import and export type information, so a host or another component can inspect what functionality it provides and what functionality it depends on.

For Spiralism's vocabulary, the component model is a boundary language. It does not make untrusted code harmless. It gives runtimes a typed contract for loading, composing, and constraining pieces of software that may become tools inside agent systems.

Mechanism

A component may contain core WebAssembly modules, other components, or both. The component encodes the interfaces of those contained pieces using WebAssembly Interface Type, or WIT. Composition works when the imports required by one module or component are satisfied by exports from another. The documentation says composition can be repeated to build one component out of many interlocking modules and components.

WIT is the interface-description language for the model. It defines interfaces, worlds, packages, functions, records, variants, resources, and other types. A WIT interface groups functions and types. A WIT world describes the broader contract of a component: what it imports, what it exports, and therefore what external capabilities must exist for it to run.

The WebAssembly System Interface, or WASI, sits next to this model as a set of APIs for WebAssembly programs outside narrow browser-only assumptions. The WebAssembly/WASI README describes WASI 0.2, also called Preview 2, as a modular collection of APIs defined with WIT, with broader source-language support, modularity, a richer type system, and virtualizability. That matters because a component can target a world such as a command-line or HTTP-oriented environment instead of assuming direct ambient access to a host machine.

Agent Context

Agent platforms need tool code. Some tools are written by the platform, some by users, some by vendors, and some by automated build chains. If those tools run as ordinary native extensions, the boundary between "agent reasoning" and "host authority" can collapse into one process with broad filesystem, network, or credential access.

The component model offers a more legible shape for plugin systems. A runtime can ask: which world does this component target, which imports does it need, which exports does it provide, what WIT package defines the contract, and which host implementation will fulfill the imports? That is directly relevant to AI Agent Sandboxing, Tool Use and Function Calling, and Agentic Supply-Chain Vulnerabilities.

Governance Use

Governance should treat a component as a declared capability bundle, not as a harmless file. A review should capture the component hash, source package, build toolchain, WIT package, targeted world, imports, exports, host bindings, filesystem scope, network scope, secrets scope, outbound data classes, update channel, signing state, and logs produced by the runtime.

The useful policy move is to bind agent permission to WIT-level capability. A weather tool should not import a filesystem world merely because its implementation language has a standard library that can open files. A document classifier should not receive network imports unless the workflow explicitly requires them. A component boundary becomes meaningful only when the host refuses imports outside the approved world.

Limits

The component model is not a complete security policy. It describes typed composition and ABI boundaries, but a runtime still decides which imports to provide, how to meter CPU and memory, how to isolate storage, how to authenticate packages, and how to record execution. A component can also be faithfully typed while still performing an unsafe, biased, or privacy-invasive task.

Maturity varies across runtimes, languages, and WASI interfaces. The model is strongest when teams treat WIT as a reviewable contract and keep host bindings small. If every component receives a broad "system" world, the interface becomes documentation rather than containment.

Review Record

Source Discipline

Claims about components, imports, exports, self-description, composition, interfaces, worlds, and WIT should cite the WebAssembly Component Model documentation and specification repository. Claims about WASI 0.2, Preview 2, WIT IDL, modular APIs, source-language support, richer types, and virtualizability should cite the WebAssembly/WASI README. Claims about agent plugin governance are Spiralist inferences from those technical boundaries.

Spiralist Reading

Spiralism reads the component model as a grammar for saying no. Agent systems are tempted to turn every useful program into a tool and every tool into implied authority. Components do not remove that temptation. They give reviewers a smaller surface to inspect: here is the world, here are the imports, here are the exports, and here is where the host must decide whether the agent may proceed.

Sources

Return to Wiki