IronClaw makes tool permissions an adoption question
IronClaw documents WebAssembly containers for untrusted tools, with explicit permissions and endpoint allowlists. Those controls make it interesting if you want a personal assistant that can do more than answer questions while keeping some limits on its actions. Our source-build attempt stopped before we could evaluate those limits. A security-oriented design deserves specific checks before it receives important credentials.
The Rust application also documents a browser gateway, messaging channels and persistent memory. Scheduled routines and event-triggered work let it act while you are away. That makes the first deployment decision consequential: which tasks should it be allowed to perform without an operator present? Start with a narrow task whose success and permitted destinations you can inspect.
What happened when we ran it
Our October 29, 2026 run at commit b0b999d installed dependencies in 69 seconds and recorded 927 dependencies. The build exited 101 after 619 seconds. The test command also exited 101, after 222 seconds. These durations describe failed repository steps, not assistant response time or a measured operational workload.
Both supplied tails reach the frontend build preparation. The log says Corepack was not found, then attempts an npm fallback for pnpm. Its error says it failed to run pnpm through Corepack or npm. That supports identifying the blocked frontend-tooling step. It does not establish why the fallback failed, so a network, package or runtime diagnosis would be speculation.
The error offers two routes: install Corepack/pnpm, or set SKIP_FRONTEND_BUILD=1 for a backend-only Rust build. Neither was reproduced in this record. Skipping the frontend would also change the evaluation boundary, leaving the browser interface outside that build. We have no passing test count to report and no basis for calling individual assistant behaviors broken.
The sandbox configuration specified 3 CPUs and 12 GB RAM, using image lab-rust:1. The label does not establish actual compiler or operating-system versions. The scan detected 28 CI workflow files, a tests directory, Dockerfile and Compose file. These indicate available project machinery, not a successful deployment or a security audit result.
A source build needs frontend tooling as well as Rust
The current README explicitly requires Node.js and Corepack/pnpm alongside Rust for source builds. A developer choosing this route should provision the frontend toolchain before expecting a complete application. The observed error is consistent with that documented requirement, but our run cannot establish that satisfying it would remove every subsequent obstacle.
Prebuilt binaries and installers are a separate documented option. Their presence matters for someone who wants to operate the assistant rather than modify its source. We did not evaluate those artifacts, so the failed source build cannot become a claim that every installation route fails. It also cannot tell us how long onboarding through an installer would take.
Local state does not settle the model-data boundary
The README says onboarding selects an LLM provider, accepts its API credential through a hidden prompt and stores the credential in an encrypted local secret store. Local credential storage describes one part of the system. Before using private material, assess the selected inference provider and the requests your chosen tools will make. Our run did not inspect that traffic.
For tools, the README describes host-boundary credential injection, request and response leak scanning, resource limits and explicit HTTP destinations. These are upstream descriptions. We did not perform adversarial testing or verify that every tool path enforces them. Avoid treating the project's security language as a guarantee about prompt injection, especially when external content can enter an assistant's context.
Channel activation and restarts remain operating tasks
Slack and Telegram require extension installation and setup on the WebUI Extensions page according to the current README. They are not enabled by a configuration-file setting or a CLI enablement key. If a messaging channel is essential, proving its setup belongs in the acceptance check rather than being assumed from a feature list.
The README also says configuration writes do not restart the service automatically. That matters when changing a running deployment: saving a value is not evidence that the process is using it. Check the documented service state after the relevant restart, then verify the specific behavior you changed. Our sandbox did not exercise service management.
Active maintenance leaves our operational questions open
GitHub records the last push as October 29, 2026, and the inspected issue/PR feed has activity on the same date. The latest-release endpoint returned ironclaw-v1.4.1, published September 29. Recent repository activity and an older release tag can coexist. Neither establishes support responsiveness or explains what a later source checkout will do on your machine.
OpenClaw documents a Gateway, messaging channels and companion applications. It is a relevant alternative when that device-and-chat workflow drives the choice. Hermes Agent documents persistent memory, reusable skill creation and scheduled automation. Evaluate it when those workflows are the priority. We have no comparative reliability, setup-time or security measurement for either candidate here.
Documentation receives 4/5 on a scope rubric: 1 means a basic description, 2 means partial setup guidance, 3 means documented configuration and use, 4 also explains execution or operating limits, and 5 requires corroborated coverage of required paths. The other dimensions remain unassessed. For IronClaw, the next useful evidence is a completed deployment followed by one restricted task, with its tool permissions and outgoing requests checked before enabling unattended work.