III · Tool Use & EnvironmentExperimental·

WebAssembly Skill Runtime

also known as Wasm Cognitive Skills, Polyglot Skill Sandbox, Capability-Sandboxed Tool Plane

Package each agent skill as a WebAssembly module with a capability manifest, and run it inside a Wasm runtime that enforces those capabilities, so untrusted skills cannot weaken the host's sandbox.

This pattern helps complete certain larger patterns —

  • specialisesSandbox Isolation★★— Run agent-emitted code or actions in a contained environment with restricted filesystem, network, and process privileges.

Context

A team is operating an enterprise agent platform that must accept skills authored by external users or partners and execute them on shared infrastructure. The skills are written in different languages — Rust, Python compiled to a runnable form, TypeScript, Go — and the platform has to enforce per-skill limits on CPU, memory, network access, and filesystem access while still serving them at the rate of incoming agent requests.

Problem

Running third-party skills as plain in-process code gives them the host's full privileges, which is unacceptable when the author is not fully trusted. Language-specific sandboxes such as a Python sandbox have a long history of escape vulnerabilities and only cover one language at a time. Spinning up a full container per skill invocation is too slow at request rate and too heavy on infrastructure. The team needs a sandbox that is light enough to start per request, language-agnostic enough to cover the polyglot skill set, and strict enough that a hostile skill cannot weaken the host environment.

Forces

  • Skills authored by partners cannot be trusted with host privileges.
  • Per-request container start-up is too slow and too expensive.
  • Polyglot authoring is a real requirement; Python-only is restrictive.
  • Capability declarations have to be checkable, not advisory.

Example

A team wants to let the community contribute third-party skills to their agent but plain-process tools share the host's privileges and per-skill containers are too heavy. They define a Wasm Component Model interface for skills: each compiles to a Wasm module shipped with a manifest declaring filesystem paths, network hosts, env vars, and syscalls it needs. The Wasm runtime enforces those capabilities. Untrusted skills can run safely alongside trusted ones because a misbehaving skill cannot weaken the host's sandbox.

Diagram

Solution

Therefore:

Define a Wasm Component Model interface for skills: each skill compiles to a Wasm module and ships with a manifest declaring (filesystem paths, network hosts, env vars, syscalls) it needs. The host runtime instantiates a fresh sandbox per call with only those capabilities. Skills can be authored in any language compiling to Wasm. The host treats the manifest as the contract; missing-capability calls fail at the boundary.

What this pattern forbids. A skill may not exercise any capability not declared in its manifest; manifest drift is detected at load time.

And the patterns that stand alongside it, or against it —

  • complementsSkill Library★— Let the agent grow its own toolkit by writing reusable skills that subsequent runs can call.
  • complementsTool Discovery★— Let the agent discover available tools at runtime rather than hardcoding the tool list at agent build time.
  • complementsSecrets Handling★— Ensure the model never receives secrets in plaintext; tools resolve credentials from references at runtime.
  • complementsCode Execution★★— Let the model emit code, run it in a sandbox, and treat the run as the answer instead of trusting the model to compute in its head.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance