从OpenClaw到IronClaw:AI安全重构

作为一款具有强大Agent能力的现象级应用，OpenClaw在极短时间内席卷GitHub和各大技术社区。然而，它的安全状况堪称灾难——一键式远程代码执行、提示注入攻击、恶意技能窃取密码，这些漏洞在OpenClaw的生态系统中被逐一曝光。

Transformer八位共同作者之一、NEAR Protocol创始人Illia Polosukhin也是OpenClaw的早期使用者，并称这是他等了20年的技术。“它已经改变了我与计算交互的方式。”但他同时看到了OpenClaw的致命缺陷。

问题的根源在于架构本身。当用户将自己的邮箱Bearer Token交给OpenClaw时，会被直接送入LLM提供商的服务器。再多的便利也不值得拿自己和家人的安全与隐私去冒险。

1 OpenClaw的架构“有毒”

OpenClaw的安全问题并非某个代码漏洞，而是源于架构本身的缺陷。

当用户将自己的凭证交给智能体时，这些凭证会直接进入LLM提供商的服务器。这意味着，你的所有对话记录、API密钥、甚至未经授权的数据，都可能暴露给第三方。

OpenClaw的第三方技能可以自由运行，缺乏有效的隔离机制。恶意技能可以窃取密码、执行任意脚本，甚至通过提示注入攻击，诱骗智能体泄露用户隐私。

问题的根源可以归结为三点：

IronClaw是用Rust语言对OpenClaw的完全重写。Rust的内存安全特性能从根本上消除缓冲区溢出等传统漏洞，这对于需要处理私钥和用户凭证的系统至关重要。

在安全架构上，IronClaw建立了四层纵深防御：

Rust的所有权系统和编译时检查，确保没有空指针、悬垂引用和数据竞争。这一层从根源上杜绝了大量内存安全漏洞。

所有第三方工具和AI生成的代码都在独立的WebAssembly容器中运行。即使某个工具是恶意的，其破坏范围也被严格限制在沙箱之内，无法触及主机系统。

即使你运行了一个被植入后门的技能，它也只能在沙箱里“折腾”，无法窃取系统文件、无法访问其他进程、无法持久化驻留。

所有API密钥和密码都使用AES-256-GCM加密存储，每一条凭证都绑定了策略规则，规定它只能用于特定域名。

这套设计中最关键的一点是：大模型本身永远接触不到原始凭证。只有当智能体需要与外部服务通信时，凭证才会在网络边界被注入。

利用硬件级别的隔离保护数据，即使是云服务提供商也无法访问用户的敏感信息。这意味着，即使部署在云端，你的数据也在一个“黑盒”中运行，连云厂商都无法窥探。

这四层防御不是简单的叠加，而是协同工作：

对于企业而言，员工使用AI智能体的最大顾虑就是数据泄露。

IronClaw的架构设计从根本上解决了这个问题：凭证永不接触LLM，第三方技能在沙箱中运行，企业可以放心地让智能体处理敏感任务。

OpenClaw的第三方技能市场曾爆出大量恶意技能，窃取用户密码、植入后门。IronClaw的WASM沙箱隔离意味着，即使技能是恶意的，它也只能在沙箱里“闹腾”，无法触及你的系统文件和真实凭证。

IronClaw的设计哲学是“安全内置”，而非“安全附加”。开发者可以在安全的基础上构建智能体，而不必担心每个新功能都可能引入漏洞。

IronClaw背后是NEAR Protocol一个更大的战略构想：用户自有AI。在这个愿景中，用户完全掌控自己的数据和资产，AI智能体在可信环境中代替用户执行任务。

NEAR已经为此搭建了AI云平台和去中心化GPU市场等基础设施，IronClaw是这套体系的运行时层。

OpenClaw的爆火揭示了市场对智能体的巨大需求，而其安全灾难则警示行业：便利不能以安全为代价。未来的智能体框架，必须将安全作为核心设计要素，而非事后补丁。

WebAssembly的轻量、安全、跨平台特性，使其成为运行第三方代码的理想沙箱。IronClaw的实践可能会推动WASM成为智能体技能运行的标准环境。

菠萝哥认为，纯本地方案存在明显局限：设备关机时智能体就停止工作，移动端的能耗难以承受，复杂的长时间任务也无法运行。他提出“机密云”作为最优折中方案，既能提供接近本地设备的隐私保障，又能解决“永远在线”的问题。

当用户可以完全掌控自己的数据和AI智能体时，现有的中心化AI服务模式可能被颠覆。

每一代技术都在解决上一代遗留的问题，同时为下一代埋下新的种子。

链接：https://github.com/nearai/ironclaw