夜雨聆风从关注到上手：我与 OpenClaw 的故事
我与OpenClaw的缘分始于今年2月上旬。那时，它刚刚在社交平台上露出一点苗头，便被我一眼捕捉。起初只是零星的帖子，但很快，越来越多的人开始分享自己的“养虾”经历，那些关于自动化处理、信息收集的场景描述像钩子一样，让我也忍不住下载安装了它，成为早期亲历者。
不过，尝鲜总要付出代价。早期版本Bug之多，足以消磨掉大部分的耐心，安装调试过程磕磕绊绊。为了跑通环境，往往要折腾大半天。所幸产品的迭代速度很快，稳定性一天比一天好，曾经让人抓狂的问题逐渐成为历史。我也从一个skill尝鲜者，变成了将 OpenClaw 融入日常的深度用户。
现在，我最满意的一个固定任务是：每5分钟，它都会帮我收一遍邮件，自动提炼摘要、判断是否要take action，然后标记已读。这个看似微小的流程，省掉了我反复点进邮箱、扫一眼又退出的碎片时间，让注意力可以更聚焦。
当然，作为IT从业者，我对安全不敢马虎。隔离环境、不暴露端口、安全扫描、谨慎安装skill、定期更新版本——这套组合拳打下来，我以为已经足够严密。但现实告诉我，有时候，防线崩塌，往往就在一念之间。
半夜的推送：一次精心设计的钓鱼
某天半夜，我被 OpenClaw 的推送吵醒——它提示我收到了一封疑似钓鱼邮件，建议不要点击链接。我打开邮件原文一看，却感到很诡异：发件人是 GitHub，货真价实的官方通知，内容是有人在某个仓库的 Discussion 里 @ 了我。邮件的内容里有个链接，声称访问后可以领取加密货币奖励。实际上，链接指向了一个伪造的 OpenClaw 官网，页面上有连接加密钱包的入口，后续发生的事情不难想象。
我侥幸没中招：一是没有加密货币，二是给 OpenClaw 配置的邮件任务只做内容总结，没有授权它执行任何操作，钓鱼内容对它而言没有可执行的意义。但换一个场景，结果就会完全不同。
这个攻击的构造颇为精妙。攻击者利用 GitHub的公开 Star 列表，收集了一批 OpenClaw 用户，再借助"任何人都可以在 Discussion 里 @ 他人"的机制批量触发官方通知邮件。而 GitHub 的 @ 通知功能本就无法关闭——项目协作中互相 @ 是常见需求——攻击者正是利用了这个死角，绕过了 Google 的垃圾邮件过滤，把钓鱼内容借 GitHub 之手送进了收件箱。
深入研究：安全隐患到底有多大
这次经历让我开始认真研究 OpenClaw 的安全问题。结论是：问题比我想象的要多，而且涉及多个不同层面。
Skill 代码投毒
OpenClaw 的 skill 生态依赖开源代码仓库，任何人都可以发布自己的 skill 到 ClawHub。这意味着恶意代码的注入路径是完全存在的——攻击者可以将恶意代码或恶意 prompt 混入 skill 的代码库，以看起来合法的工具形式分发出去。
开源带来了协作共赢，但也带来了复杂性。仓库owner对代码的 review 要求非常高，普通用户不一定会逐行审查每一行代码，而自动化工具也并不能识别所有的恶意内容，尤其是那些通过 prompt 注入而非传统恶意代码实现的攻击。
权限过大的多重风险
为了执行复杂的任务，人们往往给 OpenClaw 开通较大的权限，这导致了安全问题在几个不同的维度上同时存在。
在 tool 的执行层面，安全沙盒是否开启、是否在执行前询问用户确认，都直接影响着一个被感染的 skill 能造成多大的破坏。在全自动运行模式下，等于把执行权完全交出去了，没有任何人工审核的环节介入。
在命令执行层面，exec 是否允许所有命令、还是只允许一部分只读命令，两种配置之间的风险差距是巨大的。允许任意 shell 命令执行，意味着一旦 OpenClaw 被攻击者操控，本地系统就处于完全暴露的状态。
在隐私泄露层面，OpenClaw 当前的运行机制会把所有交互都与大模型进行通信，这本身就存在数据泄露的风险。如果用户不慎把含有 API key 或机密信息的文件纳入了 OpenClaw 的处理范围，这些敏感数据就有可能通过大模型调用被传递出去。更值得注意的是，部分大模型服务提供方实际上是转发代理而非原始服务，这在数据传输链路上引入了新的攻击节点。
与此同时，过大的本地权限让 OpenClaw 成为了一个理想的木马宿主。一旦它被攻击者利用，本地文件将面临被批量盗取的风险——因为它本身就拥有读写文件系统的能力。
提示词注入：一种新型攻击面
传统的 Web 应用和移动应用，输入来源相对确定，平台层面通常能自然抵御一部分安全风险，比如 SQL 注入在有了参数化查询之后基本上成了可管控的问题。但 OpenClaw 这类智能体的输入来源极其多样——邮件正文、网页内容、文档、聊天消息，任何被智能体读取的信息都可能成为攻击载体。
攻击者可以在这些内容里植入指令，试图让模型忽略系统 prompt、执行未授权的操作、或者将敏感信息发送到外部地址。即便只有你自己能给 OpenClaw 发消息，提示词注入依然可以通过它读取的外部内容发生——钓鱼邮件的正文就是一个典型例子。当 tool 可用时，典型的攻击目标是窃取上下文信息或触发特定的 tool 调用。
OpenClaw 自身的代码漏洞
除了上述使用方式带来的风险外，OpenClaw 本身的代码也存在可被利用的漏洞。以早期披露的 CVE-2026-25253 为例，这类漏洞可能在用户完全不知情的情况下被攻击者利用，绕过正常的安全配置。保持版本更新是使用 OpenClaw 必须养成的习惯，尽管很多普通用户并不会主动去做这件事。
微软安全团队的结论
微软 Defender 安全研究团队在今年2月发布了一篇题为《Running OpenClaw safely: identity, isolation, and runtime risk》的博文，对 OpenClaw 的安全风险进行了系统分析。文章指出，OpenClaw 内置的安全控制极其有限，运行时可以获取不受信任的文本、从外部来源下载并执行 skill 代码，并使用分配给它的凭证执行操作。
微软将这种情况描述为：执行边界从静态应用代码转移到了动态提供的内容和第三方能力，却没有围绕身份、输入处理或权限范围建立等效的控制手段。在无保护的部署环境中，三类风险会迅速显现：密钥和可访问数据可能被泄露或外泄；智能体的持久状态或"记忆"可能被篡改，导致它长期遵循攻击者提供的指令；如果智能体被诱导检索并执行恶意代码，宿主环境本身也可能遭到入侵。
这篇文章最终给出的建议颇为直接：对于大多数环境而言，不部署 OpenClaw 或许是更合适的选择。如果组织确实需要评估 OpenClaw，应当仅在完全隔离的环境中部署，使用专用的非特权凭证，且只能访问非敏感数据。
OpenClaw 官方的安全建议
OpenClaw 官方的安全文档中明确了几个核心原则：
OpenClaw 的安全模型假设单一可信用户边界，不适合多用户或多租户的对抗性场景；建议定期运行 openclaw security audit 进行安全审计；推荐的基线配置包括将 Gateway 绑定到本地loopback、启用 token 认证、关闭不必要的 tool 权限，以及在可能的情况下启用沙盒隔离。
官方也坦承没有"完美安全"的配置——核心目标是在最小可用权限的前提下，有意识地决策谁能与智能体对话、智能体被允许在哪里行动、以及智能体能接触到什么数据。
我们正处于 Windows XP 时代
目前，OpenClaw 的安全问题，就好比 Windows 系统在XP时代。那时候操作系统功能强大、应用生态繁荣，但安全漏洞层出不穷，用户需要时刻关注系统补丁、安装杀毒软件、谨慎对待每一个来路不明的链接和安装包。这是新生事物在发展过程中必然经历的阶段，不是某一个产品的独特问题，而是整个生态成熟度的体现。
OpenClaw 及类似的 AI 智能体平台，现在就处于这个阶段。系统很强大，功能很新鲜，安全意识和防护工具还在追赶。行业目前已经意识到了这个问题——360 龙虾安全伴侣、腾讯龙虾安全工具箱等工具相继推出，安全配套正在逐步跟上。
对个人用户而言，需要关注的方向有三个层面：持续追踪 OpenClaw 平台本身的安全动态和版本更新；认真对待平台级的安全配置，包括权限边界、沙盒隔离和 skill 来源审查；同时也要意识到数据泄露风险，避免将敏感信息暴露在智能体的处理范围之内。
养虾很好玩，但要养得安全。
❤️ 喜欢本文内容？欢迎点赞、转发。关注公众号，了解更多Vibe Coding资讯。
参考资料
[1] Running OpenClaw safely: identity, isolation, and runtime risk | Microsoft
https://www.microsoft.com/en-us/security/blog/2026/02/19/running-openclaw-safely-identity-isolation-runtime-risk
[2] Security | OpenClaw Docs
https://docs.openclaw.ai/gateway/security/index#security