【开发者blog】OpenClaw 安全路线图:让强大与可控不再矛盾

我们的目标是让 OpenClaw 成为运行强大 AI 个人助手的安全之选。强大不等于盲目、不等于无边界、也不等于无法审计。

OpenClaw 可以读取文件、运行命令、安装插件、连接网络、代表真实用户在真实机器上操作。这种能力容易被描述为”危险”，但这种担忧是公平的——强大不等于失控。

一、文件系统边界：fs-safe

OpenClaw 运行在你的机器上，意味着它能触及你的文档、代码库和照片。

最常见的文件系统风险是路径遍历（path traversal）——这是”边界模糊”这一大类 Bug 的一个表现：代码以为自己在一个根目录下写入，但符号链接、绝对路径、压缩包解压或粗暴的路径拼接，让它越过了另一个边界。

fs-safe 解决方案

fs-safe^[1] 是 OpenClaw 已经积累的安全文件系统模式，被提炼成共享库，让核心代码、插件和相邻服务都能使用相同的根边界原语。

• • 在插件工作空间内写入 ✓
• • 遍历或绝对路径写入被拒绝 ✗
• • 插件作者无需自己重新实现这些检查

未来方向

最安全的文件系统调用，是根本不做的那个。 这就是 SQLite 运行时状态重构的安全动机——会话、转录本、调度器状态和插件状态应该存在于类型数据库中，有清晰的归属和事务，而不是散落的文件。把运行时状态迁移到 SQLite，从运行时路径中移除整类文件系统访问。

二、网络出口：Proxyline

Agent 系统比普通 Web 服务更难防范 SSRF（服务器端请求伪造）。在普通服务中，用户控制的 URL 是例外；在 Agent 运行时中，用户控制或模型影响的 URL 是正常产品行为。”获取这个 URL，因为有人或某个东西要求了它”是正常的工作。

验证不够用了

我们最初的做法很直接：获取前验证 URL。但这不够——验证时解析一次 DNS，真正请求时再解析一次 DNS，两次答案可能不同。一个在验证时指向公网 IP 的主机，在请求发出时可能已经指向元数据端点。

Proxyline 解决方案

Proxyline^[2] 是 OpenClaw 的 Node 进程路由层。它在进程全局安装路由，把流量送入你配置的代理。代理才是连接时策略应该存在的地方：阻止元数据地址、私网范围、环回探针，以及你环境需要的任何其他要阻止的东西。

Proxyline 负责路由，代理负责执行

如果你已经运行了托管代理，可以让 OpenClaw 经过它，监控目的地、请求率和阻止尝试——用你已经信任的基础设施。

Proxyline 不是完美的笼子。原始套接字、本地模块、异常传输、早捕获的 Agent 和非 OpenClaw 子进程仍可能绕过。但对于普通 OpenClaw 网络路径，把控制点从”某个包装器记得验证这个 URL”移到”出口经过代理策略”，是更好的形态。

三、插件信任：ClawHub

当插件来自 ClawHub 时，ClawHub 必须是插件信任和来源的权威。OpenClaw 应在安装和更新时使用这些信号，而不是仅依赖事后本地检查。

ClawHub 管道综合了多种信号：ClawScan、VirusTotal、静态分析、元数据检查、来源溯源和人工审核。没有哪个是万能的。扫描器在不同方式下会产生噪音，而一个对所有东西都尖叫的管道会训练用户忽略它。

ClawHub 能做到本地安装流程做不到的事

• • 可以为特定版本附加信任证据
• • 可以声明这个版本是”干净、可疑、待审、隔离、撤销或恶意”
• • 可以阻止恶意或隔离版本的下载
• • 可以向用户展示改变了什么、为什么

安全基线

如果 ClawHub 标记某个版本为恶意和隔离，ClawHub 安装路径应该拒绝它。这是基线。

我们也在探索更高信任层级：官方包、受信任发布者、更高审核标准的包。对于 ClawHub 之外的插件，我们希望扫描也能触达，但具体产品形态仍在研究中。

四、命令审批：对抗提示疲劳

提示来得比任何人能阅读的都快。几分钟后，用户就会打开 YOLO 模式让工作继续——到那时，提示已经在训练用户停止阅读。

修复方向：更少的提示，更好的提示。

解析精度

字符串匹配不够。如果允许列表或阻止列表只看到外层命令，包装器就成了绕过。一个能理解 rm 但看不到 bash -c "rm -rf ~/something" 内部的政策，不是用户应该信任的政策。

OpenClaw 的 shell 审批路径^[3] 现在会评估常见 shell -c 包装器的内部命令链。如果内部链包含不被允许的可执行文件，包装器不应该让它变安全。命令高亮器也使用 Tree-sitter 来呈现 OpenClaw 在包装器中发现了什么。

PowerShell 有自己的陷阱；对于不理解的表单我们失败关闭（fail closed），更广泛的支持已在路线图上。

情境审批

解析是较简单的部分。更难的部分是决定何时提问。

静态审批策略要么对每个可能危险的东西都提示，要么依赖一个无法判断命令是否适合当前任务的固定允许/拒绝列表。

用户真正关心的问题是：我刚才想要这个发生吗？

这就是为什么我们在试验情境审批。目标不是”从不提示”，而是让提示有意义——当提示出现时，用户应该停下来阅读。

对于 OpenAI 用户，我们暴露了 Auto Review^[4]，这是一个 Codex 特有的功能，用独立的审阅者 Agent 替换沙箱边界的手动审批。

五、静态分析：OpenGrep + CodeQL

OpenClaw 收到了很多 GitHub 安全公告（GHSA）。第一项工作是堵住漏洞。下一项工作是确保同类 Bug 不会卷土重来。

补丁发布后很容易认为”完成了”。但 GHSA 是关于 Bug 类的证据，不只是一个 Bug。分类后的真正问题是：我们能找到所有长得像这个的代码吗？

我们的方案

使用 OpenGrep + 精确规则包。每个规则都关联到一个公告、报告或审核发现。基线目标是回归检测：如果相同的漏洞形态回来，CI 在 review 之前捕获它。更好的目标是变体检测：捕获同一种错误的附近版本。

精度就是一切。 噪音大的规则比没有规则更糟糕，因为它训练团队忽略这个渠道。

当前已入库精确规则：148 条运行位置：PR diffs + 手动全量扫描新补丁公告 → 新规则候选

CodeQL 配合运行，提供更深入的语义覆盖（更慢、维护噪音更大）。

总结：对用户意味着什么

OpenClaw 不会变弱。我们只是在让边界更容易看清、更容易防守。

我们不会承诺”零风险 Agent”。任何这么承诺的人，要么在卖东西，要么还没上线过足够多的功能。

我们能承诺的是方向：OpenClaw 可以在保持强大的同时变得更可防御。这才是我们在建设的。

安全改进一览

原文：Where OpenClaw Security Is Heading | OpenClaw Blog

引用链接

[1] fs-safe: https://fs-safe.io/[2] Proxyline: https://proxyline.dev/[3] shell 审批路径: https://docs.openclaw.ai/tools/exec-approvals[4] Auto Review: https://developers.openai.com/codex/concepts/sandboxing/auto-review