Skip to main content
WASM tools run inside a WebAssembly sandbox powered by wasmtime. They have access to IronClaw’s host functions (logging, time, workspace), but all other capabilities — network, filesystem, credentials — must be explicitly declared in a capabilities.json file. This is IronClaw’s recommended approach for custom integrations that need stronger isolation than a built-in Rust tool provides.

How It Works


Sandbox Architecture

Fuel Metering

Every WASM instruction consumes “fuel.” When a module runs out of fuel, it is terminated immediately. This prevents infinite loops and runaway computation.

Memory Limits

WASM modules are allocated a fixed linear memory. Attempting to allocate beyond the limit traps and terminates the module.

Rate Limiting

Each WASM tool has a per-tool rate limiter to prevent a misbehaving or compromised tool from making excessive API calls. Rate limits are declared in capabilities.json:

capabilities.json

Every WASM tool must include a capabilities.json alongside its .wasm binary. This file is the single source of truth for what the tool is allowed to do.

Network allowlist

The network.allowed_hosts list controls which domains the tool can reach. Requests to any domain not in this list are rejected by the network proxy before the TCP connection is established. HTTPS traffic uses the CONNECT tunnel method. The proxy validates the target hostname against the allowlist before establishing the tunnel.

Filesystem access

WASM tools cannot access the host filesystem by default. Paths declared under filesystem.read and filesystem.write are mounted into the WASM module’s sandbox at the declared paths.

Credential injection

Credentials listed in capabilities.json are never passed into the WASM module’s memory. Instead, when the module makes an outbound HTTP request, the proxy intercepts the request and injects the specified header before forwarding it. The WASM module never sees the raw credential value — it only makes an unauthenticated HTTP request, and the proxy adds the auth header transparently.

Host Functions

WASM modules can call the following host functions provided by IronClaw: These are the only host capabilities available. A WASM tool cannot call arbitrary OS functions, fork processes, or access the network directly — all network access goes through the proxy.

Tool Discovery

WASM tools are discovered at startup from two locations:
  • ~/.ironclaw/tools/ — User-installed tools
  • <workspace>/tools/ — Per-workspace tools
Each tool directory must contain:
  • <toolname>.wasm — The compiled WebAssembly module
  • capabilities.json — The capability declaration

Installing WASM Tools

Or via the extension_install tool in chat:
“Install the tool from https://example.com/tools/my-tool.wasm

Module Compilation and Caching

WASM modules are compiled by wasmtime on first load and cached. Subsequent loads use the compiled artifact, so only the first invocation of a new tool incurs compilation overhead. The cache is stored at ~/.ironclaw/wasm-cache/.

Security Notes

Review capabilities.json before installing any WASM tool from an untrusted source. The capability file determines exactly what the tool can access — network hosts, filesystem paths, and which credentials are injected.
The proxy injects credentials into outgoing requests. There is no mechanism for a WASM module to read stored secrets directly. Even if a WASM module is compromised, it cannot access the secrets store.
WASM modules cannot spawn child processes, execute shell commands, or load dynamic libraries. The WASI interface exposed to modules is minimal.
A buggy or malicious WASM tool that enters an infinite loop will be terminated when it exhausts its fuel allocation. This prevents a single tool from blocking the agent indefinitely.