OpenClaw 正在经历一次令人警惕的「野蛮生长」。根据 Censys 扫描器的公开数据，仅在某个时间点就有 21639 个 OpenClaw 网关暴露在公网直接可访问，而不到一周前这个数字还只有约一千。更严重的是，部分操作者将端口绑定为 0.0.0.0 而不是 127.0.0.1，等于让一个拥有邮件、文件乃至命令行权限的个人 AI 代理直接挂在互联网上。
这不是一次代码漏洞——而是一次部署习惯和生态安全的集体暴露。和 8 月初社区关注的 OAuth 令牌泄露与 XSS 漏洞 相比，公网暴露的威胁面更广、门槛更低：不需要挖掘 0-day，只需要扫描公网 IP 就能找到成千上万个入口。
为什么 OpenClaw 暴露在公网特别危险
OpenClaw 不是一个简单的聊天机器人。它是一个拥有用户系统级权限的代理——可以代你收发消息、执行 shell 命令、读写文件、操控浏览器。在已确认的安全事件中，攻击者获取的不是聊天记录，而是邮件权限、shell 访问、API 密钥、SSH 密钥、加密钱包和各类账号凭证。
这个攻击面和 证据包 里监控的 Agent 行为是同一套：一个暴露的 OpenClaw 网关，本质上就是一个拥有系统权限的 Agent 被放在了任何人都能敲门的位置。它的每一次工具调用、每一条消息发送、每一个文件读写，都没有经过任何外部审计。
插件市场：一扇没有上锁的门
比公网暴露更让人不安的，是 OpenClaw 的 skills（插件）机制。目前 OpenClaw 的插件系统在加载和执行插件代码之前，不进行安全扫描。有开发者在 issue #11014 中提出增加验证管道，但维护者回应「not planned」。
这意味着插件市场不是展示橱窗，而是一扇没有上锁的门。任何人上传的 skills 代码，只要被用户安装了，就可以在拥有系统级权限的 Agent 环境中执行。这和我们一直在写的 质量门禁 理念正好相反：质量门禁是在每一次变更前设卡，而 OpenClaw 的插件系统是零卡。
创始人怎么说
项目创始人 Peter Steinberger 对此的态度相当坦率：「一个拥有系统级权限的 AI 代理是个安全雷区，但它也代表着未来。」在他的视角里，这是个人电脑未来的方向——危险，却无法回避。
这个判断本身没有错。问题是：当方向正确但路还没修好时，用户需要的不是口号，而是明确的部署指引。比如：默认绑定 127.0.0.1、开启身份验证、限制插件来源、接入 回放对照 做行为审计。
安全加固：三条最低限度的建议
如果你正在使用 OpenClaw，以下三条是今天就应该检查的：
第一，绑定本地地址。在配置中将网关监听地址改为 127.0.0.1，不要使用 0.0.0.0。如果确实需要远程访问，通过 SSH 隧道或 VPN 转发，不要直接暴露在公网。
第二，审查插件来源。只安装你理解其行为的 skills，不安装来源不明或维护不活跃的插件。可以把插件管理纳入 知识库陈旧内容巡检 的同类流程——定期审查、标记风险、下架不安全的。
第三，开启日志与监控。确保所有 Agent 的工具调用都有完整日志，接入 失败升级规则 的报警链路。一旦出现异常行为——比如未经授权的邮件发送、异常文件操作——能第一时间发现并阻断。
总结
OpenClaw 公网暴露危机的核心，不是技术有多脆弱，而是社区在享受系统级 Agent 能力的同时，忽略了最基本的安全边界。绑定本地地址、审查插件来源、开启行为监控——这三条在今天之前就该做，在今天之后不该不做。
