Wiki · Concept · Last reviewed June 25, 2026

WebAssembly Component Model

The WebAssembly Component Model turns Wasm modules into typed, composable components, making plugin and tool boundaries inspectable for runtimes, agents, and governance systems.

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 and standardization effort for turning core WebAssembly modules into typed, interoperable components. The user-facing documentation describes the model as an architecture for building interoperable WebAssembly libraries, applications, and environments. The specification repository is where the Component Model is being standardized by the WebAssembly Community Group.

A component is a self-describing WebAssembly binary with richer import and export type information than a core module. It can contain core WebAssembly modules, other components, or both. Its interfaces are described with WebAssembly Interface Type, or WIT, and its instantiation depends on imports supplied by a host or by other components.

For Spiralism's vocabulary, the component model is a boundary language. It does not make untrusted code harmless. It gives runtimes, agent platforms, procurement teams, and auditors a typed contract for loading, composing, and constraining software that may become a plugin, connector, sandboxed tool, policy module, model-serving helper, or automation step.

Snapshot

Current Status

As of the June 25, 2026 review, the WebAssembly Component Model should be treated as an active standardization track rather than as a finished all-purpose platform guarantee. The WebAssembly/component-model repository says it is where the Component Model is being standardized and that component work is being developed incrementally through WASI Developer Preview releases. It also states that future work will include a formal specification and reference interpreter.

The release picture changed in 2026. WASI.dev lists WASI 0.3 as a stable release and says WASI 0.3.0 was released on June 11, 2026. WASI 0.3 builds on the 0.2 component-model foundation and moves native async into the Component Model through async func, stream<T>, and future<T>. WASI 0.2 remains the stable foundation for WIT interfaces, composability, and cross-language interoperability, while WASI 0.1 is now best described as a legacy module API with broad runtime support.

This is separate from the core WebAssembly standard. The WebAssembly 3.0 core specification, dated June 25, 2026, describes a safe, portable, low-level code format and explicitly says the core specification does not define how programs interact with a specific environment. The component model and WASI sit at that host-interface layer.

The practical status is therefore mixed: the direction is clear, the stable WASI 0.2 and 0.3 interfaces are usable, and runtimes such as Wasmtime and JavaScript tooling expose component workflows, but source-language support, registry practice, async adoption, preview migration, and host-policy discipline still vary by ecosystem.

Mechanism

Composition works when the imports required by one module or component are satisfied by exports from another. The Component Model documentation says composition can be repeated to build one component out of many interlocking modules and components. This moves integration from ad hoc foreign-function bindings toward typed interfaces that runtimes and tooling can inspect.

WIT is the interface-description language for the model. It defines packages, interfaces, worlds, functions, records, variants, resources, handles, lists, options, results, streams, futures, and other types. A WIT interface groups functions and types. A WIT package groups related interfaces and worlds under a package name. A WIT world describes the broader contract of a component: what it imports, what it exports, and therefore what host capabilities or peer components must exist for it to run.

The WebAssembly System Interface, or WASI, supplies standards-track API specifications for software compiled to the W3C WebAssembly standard. A component can target worlds such as command-line, HTTP service, or middleware environments instead of assuming direct ambient access to the host machine. In WASI 0.3, the wasi:http/service and wasi:http/middleware worlds are examples of this more explicit host contract.

For agent platforms, the important mechanism is not only portability. It is inspectability. Before a tool runs, the host can see whether the component expects filesystem access, network sockets, clocks, randomness, environment variables, HTTP client ability, or application-specific imports. That declared interface can then be compared to the permission the agent workflow claims to need.

Security Model

The core WebAssembly specification says WebAssembly code has no ambient access to its computing environment; interaction with the environment happens through functions provided by the embedder and imported into a module. WASI.dev states the same principle for WASI: a module or component starts with no access to the outside world and can only perform operations that the host explicitly grants.

For WASI 0.2 components, WASI.dev describes capabilities as expressed directly in WIT. Filesystem access, networking, environment, clocks, randomness, and similar capabilities can be separate imports, and the host instantiates the component with only the imports it grants. That makes the interface contract a statically inspectable capability surface.

The governance implication is concrete: do not rely on a vague statement that a tool is "Wasm sandboxed." Ask which runtime executed it, which WIT world it targeted, which imports were provided, which resources were preopened or bound, whether network and filesystem access were denied by default, and which logs prove the host refused out-of-scope imports.

Agent Context

Agent platforms need tool code. Some tools are written by the platform, some by users, some by vendors, some by open-source projects, 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, browser, credential, or account 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, which host implementation will fulfill the imports, and what happens when the component requests something outside that contract? That is directly relevant to AI Agent Sandboxing, Tool Use and Function Calling, Capability-Based Security, and Agentic Supply-Chain Vulnerabilities.

A component boundary also helps separate tool identity from model identity. The model may decide to call a tool, but the host decides whether the tool component exists, which imports are bound, what credentials are available, which data classes may flow through it, and how execution is logged. That separation is essential for agent workflows that combine user-supplied tools, vendor connectors, MCP servers, build steps, or local code execution.

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, provenance evidence, vulnerability status, 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.

Procurement and deployment reviews should ask vendors for the WIT package and world, supported WASI version, runtime support matrix, sandbox settings, default egress posture, provenance or signing workflow, update mechanism, and incident process for malicious or vulnerable components. For high-risk tools, the host should verify the component digest and interface before loading it, not only after an incident.

Components can also support public-interest audit. A component tool with a stable WIT interface can be tested against fake hosts, denied imports, synthetic secrets, hostile inputs, and metered execution. That gives reviewers a narrower artifact than a full agent product, though it still needs ordinary code review and runtime testing.

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, how to prevent side-channel leakage, and how to record execution. A component can also be faithfully typed while still performing an unsafe, biased, deceptive, or privacy-invasive task.

Maturity varies across runtimes, languages, tooling, package registries, and WASI interfaces. Some ecosystems still have stronger support for legacy WASI 0.1 modules than for component workflows. WASI 0.3 adds native async, but migration and cross-runtime conformance need explicit testing rather than assumption.

Versioning is a live operational issue. Components should pin WIT packages, WASI versions, runtime versions, bindings-generator versions, and host expectations. A mismatch between a component's declared world and the host's supported world can fail closed, fail confusingly, or lead teams to broaden host imports for convenience.

The most common failure is overgranting. If every component receives filesystem, network, clock, random, environment, and application-admin imports, WIT becomes documentation rather than containment. If a component is loaded from an unsigned registry, built by an unknown toolchain, or updated without review, the typed boundary does not solve the supply-chain problem.

Review Record

Source Discipline

Claims about components, imports, exports, self-description, composition, interfaces, worlds, packages, WIT, and the Canonical ABI should cite the WebAssembly Component Model documentation or specification repository. Claims about WASI releases, Preview 1/2/3 names, stable status, native async, available worlds, and proposal phases should cite WASI.dev or the WebAssembly/WASI repository.

Do not collapse core WebAssembly, the Component Model, WASI, a particular runtime, and a particular product into one source. Core WebAssembly defines the low-level code format and no-ambient-access rule; the Component Model defines typed composition; WASI defines standards-track host APIs; a runtime enforces imports and resource limits; a product chooses defaults, update channels, logs, and user-facing permission prompts.

Claims about security should name the enforcement layer. "Sandboxed with Wasm" is weaker than "this component was run by this runtime, against this WIT world, with these imports denied by default, these resources preopened, these credentials withheld, and these blocked attempts logged." Claims about agent plugin governance are Spiralist inferences from those technical boundaries unless backed by a specific product or standard.

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.

Open Questions

Sources

Return to Wiki