Definition
IronClaw is NEAR AI's open-source runtime for personal AI agents. It is written in Rust and combines a model-driven action loop with tools, persistent memory, scheduled routines, and messaging or web interfaces. It supports local deployment and hosted instances on NEAR AI Cloud.
IronClaw's security design separates credentials from the model and gives tools explicit capabilities. A deployment combines this runtime with a separately selected reasoning model.
Origin and attribution
The NEAR AI team introduced IronClaw at NEARCON on February 23, 2026. The official repository describes it as a Rust reimplementation inspired by OpenClaw and tracks its own feature coverage. It has a separate codebase and release history.
The runtime's source is available under either Apache 2.0 or the MIT license, at the user's option. Hosted service access, connected applications, and any model weights or inference APIs remain separate artifacts with their own terms.
How it works
Configured channels bring requests into the agent loop. The runtime selects tools, records state, and can run scheduled or event-driven routines. Persistent memory combines text and vector retrieval, while identity files supply continuing preferences and instructions. The user selects a supported inference provider or local endpoint.
WASM extensions execute inside a Wasmtime sandbox. Their capability manifests declare network destinations, filesystem access, and required credentials. A host proxy checks outgoing requests and injects approved credentials, keeping their raw values outside the WASM module's memory. Resource limits restrict runaway execution.
MCP extensions have a different execution path: the tool server runs remotely over HTTP, and IronClaw mediates calls through its host controls. Connecting an MCP server does not place that server inside a local WASM sandbox.
Scope and limits
A credential boundary limits exposure of a secret; it does not establish that every action using that secret is correct. An agent with valid access can still choose an unwanted operation at an approved destination. Capability grants, task instructions, and verification of results remain necessary.
The hosted trusted execution environment protects the cloud instance. A local installation has its own execution boundary and does not acquire that enclave protection. Choosing cloud inference also introduces a request path to that provider; local application storage alone does not mean every prompt stays on the user's machine.
IronClaw documents pattern and heuristic checks for leaks and prompt injection. Their presence is not proof that every malicious instruction or sensitive value will be detected. Built-in tools, WASM extensions, and remote MCP services must be assessed according to their actual execution and permission boundaries.
Operational significance
Review each extension's granted endpoints, filesystem paths, and usable credentials. Record the runtime release and selected model route, distinguish local deployment from an attested cloud instance, and verify external changes at the target service. Use a credential with only the authority the task requires.
Distinguish it from nearby terms
- OpenClaw inspired IronClaw, but the two names do not describe interchangeable installations.
- Hermes Agent is another personal-agent harness with its own memory and approval controls.
- A sandbox constrains execution. A trusted execution environment protects a hardware-backed confidentiality boundary; the two controls address different risks.
- The Model Context Protocol specifies tool communication. It does not itself establish trust in a remote service.
- Least privilege concerns the authority a tool receives, even when credentials are hidden from the model.
Check your understanding
An IronClaw tool can call an approved email endpoint without seeing the account token. Does that establish permission to send any message the model chooses? Which capability, authorization, and destination checks would you need before reporting that the communication was correct?