OpenClaw 开始认真补安全了:不是喊口号,是把最容易出事的几层先堵上

大家好，我是 One。

我先直接说结论。

OpenClaw 这次安全更新，不是那种拿来做海报的更新。

但如果你真的想把它当个人助理长期跑，这篇反而很值得看。

因为 Agent 一旦开始碰你的电脑，问题就不再是“它聪不聪明”。

而是：

• 它会不会乱读乱写文件
• 它会不会被一条 URL 带歪去打内网
• 它装的插件到底靠不靠谱
• 它弹出来的命令确认你到底看不看得懂
• 它修过一次的洞，会不会下次又原样长回来

这些问题，平时看 demo 很难有感觉。 真上机器、真接消息、真跑插件、真让它替你干活的时候，才知道哪里最容易炸。

第一张图其实已经把这次安全方向摆明了：

• fs-safe
• Proxyline
• ClawHub trust evidence
• smarter command approvals

翻成人话就是四件事： 别乱碰文件，别乱出网，别乱装插件，别乱执行命令。

这四件事，正好就是 Agent 最容易把人搞毛的四件事。

第一层：先把文件边界收紧

OpenClaw 这次讲得最清楚的一件事，是文件系统边界。

很多人一听安全，第一反应是路径穿越。 没错，这当然重要。 但更大的问题其实是：边界到底清不清楚。

比如你以为插件只会写自己工作区里的文件。 结果一个绝对路径、一个软链接、一个拼接 sloppy 一点，它就越界了。

所以他们现在把这一层往 fs-safe 上收。

这个东西不是沙箱。 它也不是说你开了以后，插件就自动无敌安全。

它真正解决的是： 本来只该在一个根目录里活动的东西，不要因为代码写得烂，莫名其妙跑到外面去。

这件事特别重要。

因为很多事故，不是模型故意害你。 而是工程边界本来就没收好。

官方这次给出的例子也很明确： 在插件 workspace 里写文件应该成功，试图用 traversal 或绝对路径写到外面，应该直接失败。

这才像一个能长期跑的系统该有的样子。

你现在就可以做的两步

第一，把插件工作区和主工作目录分开。 别图省事，全都堆在一起。

第二，优先看插件是不是还在直接乱写文件。 如果一个插件本来只该写自己的 workspace，却老想碰别的目录，这就已经该提高警惕了。

更进一步，OpenClaw 后面还准备把 session、transcript、scheduler state、plugin state 这些运行时状态，逐步收进 SQLite，而不是继续散在一堆文件里。

这个方向我挺认同。

因为最安全的文件操作，往往就是少做文件操作。

第二层：网络问题，别再只靠“先校验一下 URL”

第二层是网络出口。

这个点很容易被低估。

Agent 和普通 Web 服务不一样。 普通服务里，用户控制 URL 往往是例外。 Agent 不是。 Agent 的日常工作，本来就可能是：

• 抓这个链接
• 打开那个网页
• 拉这个 API
• 读那个 feed

也就是说，“帮我去访问一个地址”本来就是正常需求。

这时候你只在请求前做一层 URL 校验，其实不够。

OpenClaw 这次点得很明白： 你校验时解析了一次 DNS，真正发请求时可能又解析一次。 中间如果结果变了，就可能出事。

所以他们开始把控制点往 egress 侧推，也就是 Proxyline 这层。

说白了：

不要只相信“我检查过这个 URL 看起来没问题”。 而是要让真正发出去的流量，经过一个你能管、能拦、能看的出口。

这就很实用。

你现在就可以做的检查

如果你已经在本地或服务器上跑 OpenClaw，我建议你至少做这一步：

openclaw proxy validate

这不是走形式。 这一步是确认你的代理策略到底是不是活的。

按官方这次的思路，至少应该做到：

• example.com 这种正常地址能过
• loopback canary 这种危险目标要被拦
• 你能看到验证结果

如果你现在已经有自己的 managed proxy，这波反而是利好。 因为你可以直接把 OpenClaw 的流量接进去，统一看目标地址、频率和拦截记录。

第三层：插件市场不能只看“能不能装”

第三层是 ClawHub 的插件信任。

这个我觉得非常关键。

以前很多工具对插件的态度，基本就是：能装就装，出事再说。

OpenClaw 这次更明确了： ClawHub 不只是一个下载入口，还应该是插件信任和来源判断的上游。

它提到的信号包括：

• ClawScan
• VirusTotal
• 静态分析
• 元数据检查
• source provenance
• 人工审核

这些当然都不是银弹。 但重点不是“有没有 100% 安全”。 重点是：你至少别让用户在完全没证据的情况下闭眼装。

如果一个版本被标记成 malicious 或 quarantined，安装链路就该直接拒绝。

这个门槛，我觉得很合理。

你现在就可以做的动作

如果你平时会装插件，我的建议很简单：

• 能走 ClawHub 的，优先走 ClawHub
• 先看 package version 对应的 trust evidence
• 对“别人私发给你一个文件，直接装吧”这类路径，天然多留个心眼

不是不能装。 而是别把“我自己的机器”理解成“所以我可以完全不看风险”。

第四层：命令审批，最怕的不是严格，是看久了麻木

前面三层，更多是在收系统边界。 到了命令审批这层，问题就变成了另一种更常见、也更烦的风险： 不是系统没拦住，而是用户被弹窗弹麻了，最后自己开始一路放行。

这一层我觉得很多人会有共鸣。

命令确认弹窗这东西，最容易出现一个问题： 前几次你还看，后面你就不看了。

最后直接开 YOLO。

这不是用户懒。 而是很多审批提示本来就做得很烂。

OpenClaw 这次在补的一个重点是，别只看最外层命令，要继续往里看 wrapper。 比如 bash -c "..." 这种，如果里面包着危险命令，不能因为外面套了一层壳就假装没看见。

这个方向对。

因为真实世界里，很多绕法都是这么来的。

而且它还在提 contextual approval，核心不是“永远别提示”，而是： 该提示的时候，提示要真有意义。

别把用户训练成条件反射式点通过。

这里我给三个很实操的建议

第一，不要长期全局开 YOLO。 临时开可以，常态化开很危险。

第二，重点盯 wrapper 命令。 比如 bash -c、sh -c、PowerShell 包一层的这种。

第三，把审批当审动作，不要当点按钮。 如果你根本没时间看，那说明不是审批设计对了，而是流程已经在逼你忽略风险了。

第五层：安全不是修完一个洞就结束，还得防它下次再回来

最后一层，是静态分析。

这个点听起来没那么“用户向”，但其实很重要。

因为很多项目修安全问题，修法是这样的：

• 这个洞补了
• 发个公告
• 完

但真正难的不是这次补掉。 是真正把这类 bug 以后尽量别再长回来。

OpenClaw 现在在用 OpenGrep 和 CodeQL 这类方式，把过去 advisory 对应的 bug pattern 继续沉淀成规则。

这个事情的意义在于： 以后不是只靠人肉记忆“这个坑以前踩过”，而是尽量让 CI 在更前面就把相似问题抓出来。

这类活很脏，也很工程。 但长期看，它比“发一篇安全博客”更有用。

第三张图讲的就不是安全本身了，而是另一件同样关键的事：速度。

官方现在已经开始持续跑端到端 RTT 测试，而且是真走 Telegram 这类真实消息链路，不是在本地自嗨跑个 benchmark。 这件事为什么值得放在这里？ 因为一个 Agent 要长期可用，光安全还不够。 它还得别太慢，别老回得像卡住了一样。

所以我更愿意把这张图理解成一个补充判断： OpenClaw 现在不是只想把边界收紧，也想把真实使用体验拉上来。

真正能长期用的 Agent，既得跑得动，也得收得住。

总结

我看完这次 OpenClaw 的安全路线图，最大的感受不是“它讲了很多安全术语”。

而是它终于开始把几件最该补的底层问题，按正确顺序在补：

• 文件边界
• 网络出口
• 插件信任
• 命令审批
• 漏洞模式回归

这些都不花哨。 但真想把 OpenClaw 变成一个能长期跑在自己机器上的个人助理，这几层比多几个新功能重要得多。

如果你现在只是围观，可以先知道它往哪边走。 如果你已经在用，我建议你今天就做三件小事：

openclaw proxy validateopenclaw doctoropenclaw plugins list

然后再回头看你自己的配置：

• 插件是不是还在乱碰文件
• 网络是不是还裸奔
• 审批是不是已经被你点麻了

安全这件事，最怕的不是没有口号。 最怕的是系统看起来很强，边界却一直是糊的。

这次 OpenClaw 至少在做一件对的事： 先把边界讲清楚，再谈更大的能力。

以上，

—免费体验 3 天<生财有术>—

生财有术现在可以免费体验 3 天。互联网Top1大社群！

关注 AI、OpenClaw、Agents、互联网项目的，建议先进去白嫖看看。

公开网上的信息很多已经是二手、三手了，但社群里能更早看到一线实战者的项目反馈和机会判断。

不满意还能退款，基本没什么试错成本。

先看 3 天，再决定要不要留下。

有时候差距不是努力，而是你离优质信息源太远。