IronClaw Skills, Tools & Allowlisting
Current stable is 1.1.0 — a ground-up rebuild with no migration path from 0.29.x. This page is the one most affected by that rewrite: in 1.x, skills is list-only from the CLI, production and migration deployment modes return errors for extensions and skills, and the capability model moved to 12 first-party extensions embedded in the binary plus IronHub installs and custom hosted MCP servers. The ironclaw allowlist commands below are 0.29.x-only.
For a clean 1.1.0 install, see the 1.1.0 quick start. Background: the 1.0.0 rearchitecture · 1.1.0 stable and 1.1.1-rc.1. This page is queued for a 1.x rewrite.
IronClaw separates two kinds of extension. Skills are Markdown instructions injected into the model's context. Tools are code that does things. Each has its own guard rail: skills get a trust level that controls whether the model can pull them in on its own, and tools run in a WebAssembly sandbox that can reach only the hosts listed in their capabilities.json. That's IronClaw's allowlisting.
The previous version described an ~/.ironclaw/allowlist.json file with per-skill "authorised" grants and ironclaw allowlist add/grant/revoke commands. IronClaw has no such file or command. Everything below is checked against IronClaw's own documentation and release notes.
Skills: trusted vs installed
| Where the skill lives | Trust | What the model can do with it |
|---|---|---|
~/.ironclaw/skills/<name>/SKILL.md or a workspace skills/ folder | Trusted | Sees the full body; can auto-select it (skill_activate) |
Installed from IronHub (~/.ironclaw/installed_skills/) | Installed | Sees only the description; can't self-activate. It runs only when you name it ($name or /name) |
A skill activates when the scorer matches its activation keywords, tags or regex patterns (no model involved), or when you mention it explicitly. Each activation is limited by max_context_tokens (default 2,000). exclude_keywords vetoes a match, and auto_activate: false means explicit mentions only. A skill with no activation criteria never auto-activates, which is the usual reason one shows up in ironclaw skills list but never gets used.
The trust rule that matters: a skill in ~/.ironclaw/skills/ has the same power as you. Review an IronHub skill before moving it into a trusted folder.
IronHub: signed catalogue, provenance and pinning
ironclaw ironhub search github
ironclaw ironhub list --kind skill
ironclaw ironhub info <name> --kind tool # provenance, version, SHA-256 digest
ironclaw ironhub install <name> --kind tool --expected-artifact-digest "sha256:…"
ironclaw ironhub install <name> --kind skill --expected-version "1.2.3"Community entries (provenance "New") need an explicit --acknowledge-unverified from the operator. The agent can't install them, even if you approve in chat. You can ask the agent to search and install reviewed entries, and it asks your approval first.
Tools: the network allowlist lives in capabilities.json
WASM tools run under wasmtime (Wasmtime and WASI 48.0.3 since 1.4.1, which fixed recent guest fuel-accounting vulnerabilities), with fuel metering (default 100M instructions), a memory cap (default 16 MB) and per-tool rate limits. Everything beyond logging, time and the workspace must be declared:
{
"name": "my-tool",
"network": { "allowed_hosts": ["api.example.com"] },
"filesystem": { "read": ["/workspace/data/*"], "write": ["/workspace/output/*"] },
"credentials": [ { "name": "example_api_key", "inject_as": "Authorization", "format": "Bearer {value}" } ],
"rate_limit": { "requests_per_minute": 30, "requests_per_day": 500 }
}- Hosts not in
allowed_hostsare refused at the network proxy before a connection opens. - Credentials never enter the tool. The proxy adds the header on the way out, so a compromised tool can't read your key.
- No filesystem access unless paths are declared.
Since 1.4.0, sandboxed code on the local-Docker profile runs in persistent per-user containers behind a managed per-user egress proxy, with credential bindings declared in the manifest.
MCP servers and other extensions
Tools arrive as extension packages (ironclaw extension search / install / remove). MCP servers are wrapped as extensions too, reached only over HTTP(S). stdio MCP servers are rejected, because process-level egress controls aren't in place for them yet. MCP servers are treated as untrusted: their outbound requests go through the host's egress controls, and credentials are injected at that boundary and redacted from results.
See also: IronClaw security and the cross-platform skill allowlisting guide.
Sources: IronClaw's official docs in github.com/nearai/ironclaw/docs and the release notes (1.4.1 stable, 2026-09-29; 1.4.0 stable, 2026-08-28). Checked 2026-09-30.
← Back to IronClaw hub · See also: Security Architecture · OpenClaw Skills Guide · 53 Official Skills Database