The most important insight to come out of the NEAR Day security session at Consensus Miami 2026 was not about any particular exploit. It was about where the security community has been looking at the wrong thing entirely. For the past two years, the AI industry has been obsessed with the model: aligning it, jailbreaking it, patching it. What the session laid bare is that the most consequential vulnerabilities in agentic AI are not in the model at all. They live in the harness.
The harness is the orchestration layer: the runtime environment that controls what tools an agent can call, what credentials it can access, what memory it can read and write, and what actions it can execute on your machine or in your cloud environment. You can have the safest, most aligned LLM on earth sitting at the center of your agent, and if the harness is insecure, the whole system is compromised. NEAR AI’s IronClaw project, and the adaptive security benchmarking work demonstrated at the event, are built entirely on this premise.
How OpenClaw Became the Most Dangerous Thing in AI
To understand why IronClaw exists, you need to understand what happened with OpenClaw in the 60 days after it launched. Austrian developer Peter Steinberger published a weekend project called Clawdbot in November 2025. It crossed 250,000 GitHub stars by February 2026, surpassing React to become the most-starred non-aggregator software project on GitHub. No launch event, no Product Hunt campaign. Pure word-of-mouth, because what it did was genuinely different.
OpenClaw is a local AI agent harness. It connects an LLM to tools, runs it on your machine, gives it terminal access, reads your email, manages your calendar, stores your API keys, and executes multi-step tasks autonomously. It is extraordinarily capable. It is also, by architecture, a security problem waiting to detonate.
The core issue is how OpenClaw was originally built: as a Node.js server using JavaScript plugins called Skills, which execute with full access to the host environment. Every skill in the ecosystem, whether you downloaded it from ClawHub or built it yourself, runs with the same trust level. There is no isolation. There is no sandbox. The AI sees your credentials directly. Slowmist reported that 341 of the available ClawHub skills contained malicious code designed to harvest passwords or exfiltrate data. A viral post showed that OpenClaw could be prompted to reveal private keys despite explicit instructions not to. The “brain” of the agent was safe. The harness was not.
IronClaw: What NEAR AI Built Instead
NEAR AI co-founder Illia Polosukhin loved what OpenClaw could do and hated what it represented architecturally. His response was IronClaw, a ground-up Rust reimplementation of the OpenClaw concept built with security as the primary design constraint, not an afterthought.
The differences are structural, not cosmetic. IronClaw treats prompt injections as first-class security threats rather than edge cases. Credentials are stored in an encrypted vault and injected at the network boundary only, meaning the LLM never sees your raw API keys, passwords, or wallet credentials at any point. The agent has permission to use a credential for a specific approved endpoint, and nothing more. Even if an attacker successfully injects a malicious prompt that tricks the model into attempting to exfiltrate a secret, the value was never available to it.
Every tool in IronClaw runs inside its own WebAssembly sandbox with strict resource limits. If one tool is compromised, whether through a malicious skill or a supply chain attack, it cannot affect anything outside its sandbox. Outbound traffic is scanned in real time; anything that looks like a secret attempting to leave the system is blocked automatically. The choice of Rust eliminates entire classes of memory safety bugs that are architecturally unavoidable in JavaScript-based harnesses.
IronClaw vs OpenClaw: Architectural Security Comparison
NEAR Day at Consensus Miami 2026 | @cryptonewsbytes
| Feature | OpenClaw | IronClaw (NEAR AI) |
|---|---|---|
| Runtime Language | Node.js / JavaScript | Rust (memory-safe) |
| Tool Isolation | None | WASM Sandbox per tool |
| Credential Handling | LLM sees raw values | Encrypted vault, injected at network boundary |
| Prompt Injection Defense | Model-level only | Architectural (LLM never touches secrets) |
| Outbound Traffic Scanning | No | Real-time, blocks secret leakage |
| Cloud Deployment | Standard VPS / local | TEE on NEAR AI Cloud |
| Enterprise Readiness | Not recommended | Designed for teams and organizations |
Sources: NEAR.ai/openclaw, FlowHunt, Product Hunt, CoinTelegraph AI Eye | @cryptonewsbytes
The TEE Advantage: Why Cloud Alone Is Not Enough
Running IronClaw on your own hardware addresses a significant part of the security surface, but it reintroduces a different problem: you become your own IT department. NEAR AI’s solution is running both OpenClaw and IronClaw inside Trusted Execution Environments on NEAR AI Cloud. A TEE is a cryptographic enclave: code and data inside it are protected from everything outside, including the host operating system and the cloud provider itself.
For IronClaw running in a TEE, this means your agent’s long-term memory, credentials, and tool access persist without ever leaving encrypted memory, even while running in the cloud. The combination of Rust’s memory safety guarantees, WASM per-tool sandboxing, the encrypted credential vault, and the TEE enclave is layered defense: no single point of failure can compromise the whole system. The LLM never touches raw secrets. The tools cannot see each other. The host cannot see the execution.
For the crypto context specifically, this architecture matters more than it does for general-purpose agent use. An agent managing DeFi positions, executing trades, or handling cross-chain transactions through intent networks is a high-value target. The difference between an agent that holds a private key in plaintext memory accessible to the LLM, and one where that key is vaulted, endpoint-scoped, and never exposed to the model, is the difference between a productive tool and a honeypot.
Benchmarking Security: Why Static Tests Are Already Obsolete
The second major thread from the NEAR Day session was how the industry measures whether any of this security work actually holds up under adversarial conditions. The session discussed Attackbench, an adaptive benchmark framework that pits LLMs against each other in a red-team/blue-team format, specifically designed to expose vulnerabilities in agent harnesses rather than in the models themselves.
The adaptive framing matters because static security benchmarks have a fundamental problem: they become obsolete almost immediately. Frontier models saturate capability benchmarks within months of release, and security benchmarks face the same issue in reverse. A defense that achieves a 0% attack success rate on last quarter’s attack set may have no resistance to current techniques. The research literature is explicit on this: prompt injections that achieve a 100% attack success rate against current state-of-the-art agents have already been demonstrated in competitive red-teaming environments.
Attackbench’s approach is to treat agent security benchmarking as an ongoing arms race rather than a one-time certification. The attacking LLM is continuously updated with new techniques. The defending harness is continuously updated with new mitigations. The benchmark score at any given moment is not a grade; it is a snapshot of the current equilibrium in a dynamic conflict. That framing is honest in a way that most security product marketing is not.
The Agentic AI Attack Surface: Where Exploits Actually Live
Based on NEAR Day session at Consensus Miami 2026 | @cryptonewsbytes
Prompt Injection
Malicious instructions embedded in external content (emails, documents, web pages) that redirect agent behavior. 100% success rates demonstrated against current SOTA agents in competitive red-teaming.
Credential Theft
When the LLM can directly see API keys, private keys, or passwords in context, a single successful injection can exfiltrate everything. OpenClaw’s viral private-key leak demonstrated this in production.
Malicious Skills / Supply Chain
341 of available ClawHub skills contained malicious code per Slowmist. Without tool isolation, one bad plugin compromises the entire agent and its host environment.
Memory Poisoning
Corrupting the agent’s persistent memory store to alter long-term behavior. Particularly dangerous in 24/7 autonomous agents managing financial positions over extended time horizons.
Config Self-Modification
Tricking an agent into disabling its own security flags via a crafted prompt. OpenClaw patched this in April 2026 by implementing kernel-level hard rejections for security-critical config changes.
IronClaw’s Defense Model
Architectural mitigations that do not depend on telling the model to behave: credential vaulting, WASM sandboxing, TEE enclave, real-time outbound scanning, and Rust memory safety.
Sources: NEAR Day Consensus Miami 2026, Slowmist, OpenClaw 2026.4.14 release notes, research literature | @cryptonewsbytes
The Unsolved Problem: The Marketplace
One candid moment from the NEAR Day security discussion: the skill marketplace problem has no clean solution yet. OpenClaw’s power comes from anyone being able to build a skill. Its danger comes from exactly the same property. Polosukhin acknowledged this directly. “The cool thing is that anyone can build a skill. But the dangerous thing about the current marketplace is that anyone can build a skill. How do you make a marketplace that’s safe and effective? We’re still going through how exactly do you make that work. I think it’s reasonable to consider maybe a curated marketplace.”
The tension here is not easily resolved. A fully curated marketplace kills the permissionless innovation that drove OpenClaw’s viral growth. An uncurated one is a malware delivery channel. IronClaw’s WASM sandboxing mitigates the damage a malicious skill can do by containing its blast radius, but it does not prevent the skill from executing its intended malicious behavior within its sandbox. The next layer of the problem is probably reputation systems, automated static analysis, and community auditing, none of which exists at the scale needed yet.
That candor is actually one of the more encouraging things to come out of the Consensus Miami security track. The teams building this infrastructure are not claiming their systems are secure. They are being precise about which attack vectors they have addressed, which ones remain open, and where the research frontier currently sits. For an industry with a long history of overstating security guarantees, that specificity matters.
Why Crypto Is the Highest-Stakes Deployment Environment
Most discussions of agentic AI security are framed around enterprise productivity tools: an agent that manages your email or schedules meetings. The damage from a compromised agent in that context is significant but recoverable. In the crypto context, the calculus changes completely. An agent managing on-chain assets, executing DeFi strategies, or handling cross-chain transactions via NEAR Intents operates with private keys, on-chain permissions, and real financial exposure. A single successful prompt injection that exfiltrates a wallet’s signing credential is not a data breach. It is an irreversible fund loss.
This is the specific context in which IronClaw’s credential vault architecture becomes something more than an academic security improvement. NEAR’s broader ecosystem bet, that confidential execution environments and intent-based networks will handle institutional capital flows, depends on the harness layer being trustworthy at a level that current JavaScript-based frameworks simply are not.
The session at Consensus Miami was, at its core, an argument that the harness is not a commodity layer sitting beneath the interesting AI work. It is the security foundation on which everything else in agentic crypto finance depends, and it is currently being rebuilt from scratch.
Frequently Asked Questions
What is an AI agent harness and why does it matter more than the LLM?
An AI agent harness is the orchestration layer that connects a language model to real-world tools: terminal access, email, file systems, APIs, wallets, and so on. The LLM provides reasoning; the harness provides action. Most AI security research has focused on the model itself, but the harness controls what the agent can actually do, what secrets it can access, and what actions it can execute. A compromised or poorly designed harness can be exploited even with a perfectly safe model at its center.
What makes IronClaw more secure than OpenClaw?
IronClaw uses four layers that OpenClaw lacks: Rust for memory safety (eliminating a class of bugs inherent to JavaScript), WASM sandboxing for every tool (so a compromised plugin cannot affect the rest of the system), an encrypted credential vault where the LLM never sees raw secrets, and real-time outbound traffic scanning. Running in a TEE on NEAR AI Cloud adds cryptographic enclave protection at the infrastructure level.
What is a Trusted Execution Environment (TEE) and why is NEAR using it?
A TEE is a cryptographic enclave running on hardware that ensures the code and data inside it are protected from everything outside, including the host operating system, the hypervisor, and the cloud provider. For agentic AI, this means the agent’s memory, credentials, and execution state cannot be inspected or modified even by the server it is running on. NEAR AI uses TEEs to offer the autonomy of cloud deployment without requiring trust in the infrastructure provider.
What is prompt injection and why can it not be solved by aligning the model?
Prompt injection is an attack where malicious instructions are embedded in content the agent reads, such as a webpage, email, or document, that redirect the agent’s behavior against the user’s intent. It is a structural reality of how LLMs process context, not a bug that can be patched. Telling the model to be careful does not work reliably. IronClaw’s approach is to ensure the agent cannot do anything catastrophically harmful even when successfully injected, because the secrets are architecturally inaccessible, not because the model refused to leak them.
IronClaw: Layered Security Architecture
Each ring blocks a different class of attack. The LLM core never touches raw credentials. | @cryptonewsbytes
Sources: NEAR.ai, NEAR AI GitHub, FlowHunt | @cryptonewsbytes
Further Reading
The trust assumptions in agent and bridge architecture share the same structural flaw discussed at NEAR Day: single points of failure in the orchestration layer.
LayerZero’s DVN exploit and the Drift hack are part of the same pattern IronClaw is designed to address at the agent layer.
As crypto firms gain access to Treasury-level threat intelligence, the security posture of their agentic infrastructure becomes a compliance issue, not just a technical one.
This article is for informational purposes only and does not constitute financial or legal advice. Sources: NEAR.ai, NEAR AI GitHub, CoinTelegraph AI Eye, FlowHunt, Slowmist. Published May 13, 2026. Recorded at NEAR Day, Consensus Miami 2026 (May 7, 2026).
