By ByteBot
AI agents need new tools constantly. Fetching and executing arbitrary code from the internet to give them those tools is a security hole most teams treat as someone else’s problem. Microsoft’s Azure Core Upstream team just open-sourced Wassette — a Rust-powered runtime that runs WebAssembly Components as sandboxed MCP tools. The core idea: compile your tool to WebAssembly, push it to an OCI registry, and any MCP-compatible AI agent can fetch and execute it with browser-grade isolation and a deny-by-default permission model. No daemon, no bloated container, no silent privilege escalation.
Any Wasm Component Becomes an MCP Tool
The mechanism is cleaner than it sounds. Wassette reads a WebAssembly Component’s typed WIT (WebAssembly Interface Types) interface and automatically exposes each exported function as a separate MCP tool. A component that exports reverse_text(), count_words(), and parse_json() becomes three MCP tools instantly — no custom integration code, no schema writing by hand.
cargo install wassette
wassette run oci://ghcr.io/myorg/reverse-text:1.0.0 --allow-stdioThat second command fetches the component from an OCI registry, inspects its WIT interface, and presents its exports to any connected MCP client. Your agent calls them like any other tool. The component runs inside Wasmtime’s sandbox and is discarded after execution — no persistent state, no lingering process, no footprint.
The Security Model Is the Point
Most MCP servers today are Node.js or Python processes running with full host privileges. They can read your filesystem, make arbitrary network requests, and spawn child processes. The only thing standing between a compromised MCP server and your laptop is the hope that nobody published a malicious tool. That’s not a security model — that’s optimism.
Wassette uses a capability-based, deny-by-default approach built on Wasmtime — the same runtime that powers Cloudflare Workers and the Bytecode Alliance’s reference WebAssembly implementation. Each component loads with zero capabilities. Network access to a specific domain? The user sees a permission prompt. File system access? Same. The agent can’t silently grant itself more than it needs because Wassette enforces at the runtime level, not the policy level.
This matters because the agent security problem is real. When agents execute tools dynamically, classic security boundaries break down. An unconstrained MCP server is a potential remote code execution proxy. Wassette’s architecture assumes tools are untrusted by default and structures isolation around that assumption.
On-Demand Tools from OCI Registries
The OCI registry integration is where Wassette gets interesting architecturally. Agents don’t need pre-installed tools. When a task requires a capability the agent doesn’t have, Wassette fetches the Wasm component from ghcr.io or any OCI-compatible registry, runs it, and discards it. This is closer to an app store model for agent tools than the current approach of maintaining a curated list of pre-approved MCP servers.
Wassette ships with setup instructions for GitHub Copilot in VS Code, Claude Code, Cursor, and Gemini CLI. Install the binary, register it as an MCP server in your config, and the agent can start using Wasm components as tools. Components can be written in Rust, Go, Python, JavaScript, or C — anything that compiles to the WebAssembly Component Model.
Early Stage — Worth Tracking, Not Yet Blind Trust
Wassette is at v0.3.4 and Microsoft is explicit that it’s not production-ready. The current limitations are real: stateless tools only (networking and threading constraints make long-running sessions impractical), and the WebAssembly component ecosystem is still thin enough that you’ll likely be porting your own tools rather than pulling from a rich registry.
The OCI fetching model also deserves scrutiny. Fetching and executing code from a registry — even inside a sandbox — is a supply chain surface. The Wasmtime isolation limits blast radius, but you still need to trust component provenance. Registry signing and verification workflows for Wasm components are not yet standardized.
That said, the architecture is right. The Wasm Component Model combined with MCP is a credible answer to how agent tool ecosystems can scale securely. Follow the project. Experiment with it for internal tooling where you control the registry. Don’t ship it to production users yet.
Wassette is MIT-licensed. Source and install instructions at github.com/microsoft/wassette. Read the concepts documentation before registering it as an MCP server — the permission model requires some upfront thought about what access you’re willing to grant.
