OpenClaw 亮出 agent 安全底牌:文件系统锁死、网络出口卡口、命令逐条审批,AI 助手的「权限笼子」长什么样?

agent 能在你电脑上干什么？这份清单看完后背发凉

5 月 15 日，OpenClaw 官方博客发了一篇标题很克制的文章：《Where OpenClaw Security Is Heading》。

▲ OpenClaw 官方博客，作者 Jesse Merhi，发布于 2026 年 5 月 15 日

但文章第一段就把 agent 的真实权限摊开了：

“OpenClaw can read files, run commands, install plugins, talk to the network, and act on a real machine for a real user.”

「OpenClaw 能读文件、跑命令、装插件、访问网络，并在真实用户的真实机器上执行操作。」

读文件——你的代码、配置、密钥文件，它都能碰。跑命令——`rm -rf` 和 `curl` 一样顺手。装插件——第三方代码直接拉到本地跑。访问网络——你的内网、metadata endpoint、localhost，它都能摸到。

这些能力单独看都合理，合在一起就是一个拥有 shell 权限的自主程序在你电脑上运行。

OpenClaw 官方 X 帖把这次更新浓缩成了四个关键词：

“Security in OpenClaw is getting sharper — fs-safe for root-bounded filesystem; Proxyline for policy-driven network egress; ClawHub trust evidence; smarter command approvals. Powerful agents need guardrails you can actually audit.”

「OpenClaw 的安全正在变得更锋利——fs-safe 负责文件系统边界，Proxyline 负责策略驱动的网络出口，ClawHub 提供信任证据，命令审批变得更智能。强大的 agent 需要你真正能审计的 guardrails。」

▲ OpenClaw 官方推文，发布后获得 3.6 万次浏览、数百点赞

最后那句话才是重点：guardrails you can actually audit——你能审计的护栏。

第一层：文件系统边界，fs-safe 做了什么、没做什么

先看文件系统。

OpenClaw 的 `@openclaw/fs-safe` 库负责所有安全敏感的本地文件操作：root-bounded reads/writes、原子替换、压缩包解压、临时工作区、JSON 状态管理、密钥文件处理。

▲ OpenClaw 官方文档：Secure file operations

它处理的核心问题是路径越界：path traversal、绝对路径逃逸、符号链接跟踪、压缩包内路径穿越——这些都是文件系统边界模糊时最容易出事的地方。

但官方文档反复强调了一个边界：

“It is not a sandbox.”

「它不是沙箱。」

fs-safe 是库级别的 guardrail，用于防止 trusted code 在处理 untrusted path names 时越界。如果一个插件被允许执行任意 shell 命令，fs-safe 挡不住——因为 shell 本身就有完整的文件系统权限。

真实的 blast radius（爆炸半径）仍然取决于宿主机的文件系统权限、OS 用户隔离、容器边界和 agent/tool 策略。

换句话说，fs-safe 管的是”代码里路径写错了不会越界”，管不了”代码故意要越界”。

第二层：网络出口，Proxyline 路由流量，代理执行策略

agent 能访问网络，这件事比大多数人想的严重。

内网服务、云厂商 metadata endpoint（169.254.169.254）、localhost 上跑的数据库、私有 IP 段——一个拥有网络权限的 agent 如果不加限制，SSRF（Server-Side Request Forgery）风险直接拉满。

OpenClaw 的方案是Proxyline：一个 Node 进程级别的路由层，把运行时的 HTTP 和 WebSocket 流量导向 operator 管理的正向代理。

▲ OpenClaw 官方文档：Network proxy

官方博客对 Proxyline 的定位有一句非常精确的表述：

“Proxyline routes. The proxy enforces.”

「Proxyline 负责路由。代理负责执行策略。」

这句话划清了边界：Proxyline 本身不做连接过滤、不做 IP 黑白名单、不做请求内容审查。它只管把流量导到代理，真正的策略——哪些域名能访问、哪些 IP 段要拦截、metadata endpoint 怎么处理——由 operator 在代理侧配置。

官方文档也明确说了：这不是 OS/network sandbox 的替代品。它是 defense in depth（纵深防御）的一层，降低 agent 直接触碰敏感网络端点的概率。

第三层：插件供应链，ClawHub 给每个版本贴信任标签

agent 装插件，本质上就是从互联网拉第三方代码到本地执行。

OpenClaw 的 ClawHub 是插件目录和供应链信任层。官方博客描述的机制是：trust evidence 绑定到 specific package version，每个版本有状态标签——clean、suspicious、held、quarantined、revoked、malicious。

▲ GitHub 上的 openclaw/clawhub 仓库，采集时显示约 8.6k stars

如果一个版本被标记为 malicious 或 quarantined，安装时应该直接拒绝。

这套机制的关键在于版本粒度：信任证据锁定到具体版本号，而非整个包。一个包的 v1.2.3 可能是 clean，v1.2.4 可能因为被注入恶意代码而变成 malicious。这比”信任整个包”或”信任整个作者”精细得多。

但也要看到边界：ClawHub 提供的是证据和状态分层，最终的安装决策仍然依赖扫描结果、operator 策略和运行时 enforcement。标签本身不等于安全保证。

第四层：命令审批，从”yes/no 弹窗”到可读的命令链

这可能是普通用户感知最强的一层。

agent 要执行 shell 命令时，用户要不要批准？批准了能不能看懂自己在批准什么？

OpenClaw 的 Approvals 系统管理 local host、gateway host 和 node host 的执行审批。`openclaw exec-policy` 可以同时查看和同步 requested config 与本地 host approvals file，支持 yolo（全放行）和 deny-all（全拒绝）两种预设。

▲ OpenClaw 官方文档：Approvals

这里有一个设计细节值得注意：host approvals file 是 enforceable source of truth。`approvals get` 会同时展示三层信息——requested policy、host approvals-file policy、effective result。最终生效的以 host 侧文件为准，不是以 agent 请求为准。

官方博客还提到，shell approval 路径会解析常见的 `shell -c` wrapper，把内部 command chain 拆开，用 Tree-sitter 做语法高亮。

举个例子：当 agent 请求执行 `bash -c “cd /tmp && curl -s https://example.com/setup.sh | sh”` 时，你看到的不再是一个黑盒字符串，而是被拆解和高亮的命令链——`cd /tmp`、`curl -s …`、`| sh`——每一步干什么，一目了然。

目标是降低prompt fatigue（审批疲劳）。如果每次都弹一个看不懂的 yes/no，用户最终会习惯性点”同意”，审批形同虚设。

社区怎么看？支持声和质疑声都很明确

OpenClaw 的帖子发出后，X 上的讨论集中在两个方向。

支持方认为这是 agent 基础设施的正确路径。开发者 @1ly_store 的评论概括得很到位：

“The focus in agent infrastructure is shifting — from ‘can it do the task’ to ‘what can it access, who approved it, what policy was enforced, can we audit what happened’.”

「agent 基础设施的重心正在转移——从’它能不能完成任务’转向’它能访问什么、谁批准的、执行了什么策略、事后能否审计’。」

@OpenClaw_Ping 进一步提出了产品化期望：希望有single audit timeline，把 fs-safe 的拒绝记录、Proxyline 的出站决策、命令审批和 ClawHub 的供应链溯源关联到每次运行，并支持 policy-as-code 导出。

@CodyASmithJr 则指出了一个产品侧的现实问题：当 agent capability 变得越来越便宜，产品竞争的焦点会变成——用户按下”同意”之前，能不能看懂 blast radius。

但反方声音同样值得重视。

@Volsureface 直接指出：

“Auditable guardrails mean more logging — which nobody wants to review.”

「可审计的 guardrails 意味着更多日志——而没人愿意去看。」

这击中了一个结构性矛盾：审计能力本身不是免费的。fs-safe 的 deny log、Proxyline 的 egress decision、command approval 的记录、ClawHub 的 provenance 数据——这些加在一起，就是大量日志。如果没有有效的检索、关联和压缩机制，日志最终会变成没人看的合规噪音。

哪些已经落地？哪些还在路上？

官方博客自己做了一个分层标注：

“Some of this has landed. Some is rolling out. Some is still in flight. Some is research.”

「有些已经落地。有些正在推出。有些仍在开发中。有些还在研究阶段。」

这意味着目前公布的四层安全栈，并非全部已经可用。fs-safe 作为基础库已经在用，但 Proxyline 的 operator-managed proxy 需要部署配置，ClawHub 的 trust evidence 仍在完善，命令审批的 Tree-sitter 高亮也在 rollout 过程中。

Phemex News 和 Blockchain.News 在 5 月 16 日都跟进报道了这次安全路线更新，但报道内容基本复述官方博客，没有额外独立信源。

▲ Phemex News 于 2026 年 5 月 16 日报道 OpenClaw 安全更新

agent 安全的真正战场，在模型之外

回到 OpenClaw 那句原话：Powerful agents need guardrails you can actually audit.

当 personal assistant、coding agent、desktop agent 开始在真实机器上执行真实操作，安全问题就不再只是”模型会不会幻觉”或”对齐做得好不好”。

真正的问题变成了系统工程：文件系统边界画在哪里？网络出口谁来管？插件从哪来、谁审过、哪个版本？命令执行谁批准、批准记录能不能回溯？

OpenClaw 的这套安全栈给出了一个具体的分层框架。它没有声称”agent 安全已经解决”——官方自己说了，部分还在研究阶段。但它把问题拆成了可测试、可观测、可审计的运行时层，而非一个大而无当的”安全开关”。

强 agent 的竞争，终将从”谁的模型更强”延伸到”谁的运行时能把权限、网络、插件和审批变成可解释、可回放、可追责的系统”。

这场比赛才刚开始。

— END —