Last updated: 2026-09-30

IronClaw Security Architecture

⚠️ This page documents IronClaw 0.29.x, not the current 1.1.0

Current stable is 1.1.0 — a ground-up rebuild of the runtime, storage, extension host and web UI, with no migration path from 0.29.x. The threat model and sandbox mechanics below are accurate for 0.29.1. Do not assume they describe 1.x's isolation boundaries — the extension host in particular was rebuilt, and memory is now a userland extension with declared capabilities rather than a built-in.

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. Cross-platform hardening that applies either way: our security center. This page is queued for a 1.x rewrite.

IronClaw's pitch is defence in depth. Secrets are encrypted and never enter the sandbox. Tools run in isolation and can reach only allowlisted hosts. Everything headed for the model is scanned for leaked secrets, and several layers handle prompt injection. This page sets out that model as IronClaw documents it, then the hardening steps that are yours to take.

This page was rewritten on 2026-09-27

The previous version described "strict / standard / audit-only" sandbox modes, a mandatory audit log with ironclaw audit tail/show/export, an allowlist file and seccomp profiles per skill. None of that is in IronClaw's documentation or CLI. Everything below is checked against IronClaw's own documentation and release notes.

The four layers

Encrypted at rest: credentials sit in an encrypted store whose master key is in the OS keychain, or IRONCLAW_REBORN_SECRET_MASTER_KEY on headless hosts. Config files name environment variables, never values.
Sandboxed execution: WASM tools run under wasmtime with instruction (fuel) and memory limits and per-tool rate limits. Since 1.4.0, the local-Docker profile gives each user a persistent sandbox container. 1.4.1 (2026-09-29) is a security update for this layer: The WASM runtime now uses Wasmtime and WASI 48.0.3, fixing recent guest fuel-accounting vulnerabilities and a WASI filesystem timestamp panic. If you run third-party WASM tools or extensions, update.
Network allowlisting: a tool can reach only the hosts in its capabilities.json. The proxy refuses anything else before the connection opens and injects credentials into outgoing requests, so the tool never sees them. 1.4.0 added a managed per-user egress proxy.
Leak detection: everything sent to the model, including user input and tool results, is scanned for secret-like patterns (API keys, tokens, private keys) and blocked before it can leak.

Prompt-injection defence

Input validation (length, encoding, forbidden patterns)
A sanitizer that escapes dangerous content
A policy engine with actions by severity
The leak detector (15+ secret patterns)
Tool output wrapped in a structured format, so it's treated as data

Skills add a trust rule on top: skills installed from IronHub can't be self-activated by the model, only named by you. See skills, tools & allowlisting.

Your part: hardening checklist

Pick the right profile. local-dev is for one person on their own machine. A deployment serving more than one user must not run a single-user profile, and local-dev-yolo gives host filesystem access.
Keep the web UI local. ironclaw serve listens on 127.0.0.1:3000. Reach a server over an SSH tunnel (ssh -N -L 3000:127.0.0.1:3000 you@server), and rotate the login token with ironclaw config set webui.token --rotate if it leaks.
Set spend caps in budget.* (user_daily_usd, pause_at…) before leaving routines unattended. See configuration.
Install IronHub entries by digest (--expected-artifact-digest), and only acknowledge unverified community entries after reading them.
Don't drop unreviewed skills into ~/.ironclaw/skills/; that's full trust.
Prefer HTTP MCP servers you control. stdio servers are rejected anyway.
Keep secrets out of files and chat. config set <provider>.api_key prompts with hidden input so keys never reach your shell history.
Check health regularly with ironclaw doctor, and read the service log files (there's no ironclaw logs yet).

What it doesn't protect you from

Your model provider. Whatever you send to a hosted model is visible to that provider. NEAR AI and Tinfoil offer privacy-focused and TEE-attested inference if that matters.
A trusted skill or a host-access profile. Both carry your own authority.
Someone with root on the host, or you approving a bad action.

Cross-platform guidance: Security centre. Comparison: IronClaw vs OpenClaw.

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: Skill Allowlisting · Configuration Reference · OpenClaw Security Hardening