OpenClaw 发布安全建设方向:文件、网络、插件与命令执行的防护设计

来源：OpenClaw 官方博客《Where OpenClaw Security Is Heading》主题：OpenClaw 安全建设方向关键词：AI 个人助手、文件边界、网络出口、插件信任、命令审批、静态分析

OpenClaw 近期公布了安全建设方向，重点放在五个方面：

• • 文件访问
• • 网络请求
• • 插件安装
• • 命令执行
• • 代码安全检查

OpenClaw 的定位，是在用户真实电脑上运行的 AI 个人助手。它可以读取文件、执行命令、安装插件、访问网络，也可能接触代码仓库、文档、图片、配置文件等本地资料。

因此，安全问题也不再只停留在回答内容本身，而是延伸到文件访问、网络请求、插件来源和命令执行这些操作环节。

这些问题包括：

• • 文件会不会被越界访问？
• • 网络请求会不会打到内网地址？
• • 插件来源是否可信？
• • 危险命令是否能被识别？
• • 过去修过的漏洞会不会再次出现？

OpenClaw 给出的思路，是继续保留强执行能力，同时把关键边界做得更清楚。

01 文件访问：插件只能在自己的工作区内操作

本地 AI 助手一旦具备读写文件的能力，就必须明确哪些目录可以访问，哪些目录不能碰。

常见的路径穿越只是其中一种风险。符号链接、绝对路径、压缩包解压、路径拼接不严谨，都可能让程序越过原本设定的目录。

fs-safe 解决什么问题？

fs-safe 是 OpenClaw 用来处理文件系统边界的一套安全文件操作能力。

它把 OpenClaw 已经使用的一些安全文件操作方式整理成共享库，让核心代码、插件和相关服务都使用同一套受工作区边界约束的文件操作方式。

简单来说：

• • 插件在自己的工作区内写文件，可以正常完成；
• • 插件尝试通过路径穿越写到工作区之外，会被拒绝；
• • 插件尝试使用绝对路径写到工作区之外，也会被拒绝。

fs-safe 的边界

fs-safe 管的是文件操作边界。

它不能替代沙箱，也不能覆盖所有命令执行风险。如果一个插件已经获得了执行任意 shell 命令的权限，单靠 fs-safe 仍然不够。

OpenClaw 还在推进一项配套改动：将会话、对话记录、任务调度状态、插件运行状态等运行时数据迁移到 SQLite 中。

这样可以减少零散文件的读写，让状态管理更集中，也减少文件路径带来的风险。

文件安全不能只靠临时判断路径是否合法，更要从设计上减少不必要的文件读写。

02 网络请求：不能只在访问前检查 URL

OpenClaw 具备网络访问能力。

在实际使用中，用户可能会让它打开某个链接，模型也可能根据任务需要生成 URL 并发起请求。网络访问本身是正常功能，但一旦请求目标缺少约束，就可能访问到内网地址、回环地址或云服务元数据地址，从而带来 SSRF 风险。

只校验 URL 为什么不够？

只在访问前检查 URL，并不能完全避免风险。

原因在于，系统检查 URL 时会解析一次域名，真正发起请求时又可能再次解析。两次解析之间，域名指向的地址可能已经发生变化。

例如：

校验阶段：example.test -> 公网地址请求阶段：example.test -> 内网地址 / 回环地址 / metadata 地址

这样一来，访问前看起来“安全”的 URL，真正请求时可能已经指向了不该访问的目标，请求前校验也就可能失效。

Proxyline 的做法

Proxyline 可以理解为 OpenClaw 的网络出口路由组件。

它会把 OpenClaw 中常规的 Node 网络请求导向用户配置好的代理。真正建立连接时，由代理执行访问控制策略。

Proxyline 负责把请求送到代理出口，哪些地址可以访问、哪些地址需要拦截，由代理来判断。

可以在代理层重点拦截的目标包括：

• • 云服务元数据地址（metadata 地址）
• • 私有地址段
• • 回环地址探针（loopback canary）
• • 运行环境中明确禁止访问的其他目标

这种做法的好处是，网络访问不再完全依赖每个工具自己检查 URL。常规网络流量经过统一代理后，访问目标、访问频率和拦截记录也更容易被观察和审计。

Proxyline 的边界

Proxyline 主要覆盖 OpenClaw 中常规的 Node 网络请求路径，并不能充当完整的网络沙箱。

例如，原始套接字、原生模块、非常规传输方式、在 Proxyline 生效前就已经创建或持有的网络 Agent，以及不由 OpenClaw 管理的子进程，仍然可能绕过这层控制。

因此，Proxyline 更适合理解为一层网络出口路由机制。它负责把常规请求送到配置好的代理，再由代理判断哪些地址可以访问、哪些地址需要拦截。至于能够绕过 Node 网络路径的行为，还需要依赖更底层的系统隔离、权限控制或运行环境约束。

03 插件安装：ClawHub 要给出清晰的风险状态

插件是 OpenClaw 扩展能力的重要方式，也容易带来供应链风险。

一个插件是否可靠，不能只看它能不能运行，还要看这些问题：

• • 它来自哪里？
• • 由谁发布？
• • 是否经过扫描？
• • 是否有来源证明？
• • 当前版本有没有风险标记？

ClawHub 承担什么角色？

ClawHub 在这里承担插件分发和信任提示的作用。

通过 ClawHub 安装或更新插件时，OpenClaw 会使用 ClawHub 提供的安全信号。

这些安全信号包括：

• • ClawScan 扫描结果；
• • VirusTotal 检测结果；
• • 静态分析结果；
• • 插件元数据检查；
• • 来源证明或来源溯源信息；
• • 人工审核结果。

同一个插件，不同版本的安全状态可能不同。某个版本可以被标记为：

如果某个版本已经被标记为 malicious 或 quarantined，通过 ClawHub 安装时就应当被拦截。

开放插件生态里，用户仍然可能从 GitHub、私有仓库，或者别人发来的文件安装插件。OpenClaw 没有取消用户对本机的控制权。

因此，更推荐的方式，是把插件发布到 ClawHub，经过扫描和审核后，为具体版本附加安全证据。这样用户在安装前就能看到相关风险状态，再决定是否继续安装。

后续，ClawHub 还会探索更高可信级别，例如官方插件包、可信发布者，以及更严格的审核要求。

OpenClaw 还表明：对于 ClawHub 之外的插件，扫描能力也会继续扩展，具体形态还在完善。

04 命令执行：审批提示要少一点，也要准一点

OpenClaw 可以执行系统命令，命令审批就是安全设计里的关键环节。

审批提示太多，会带来一个现实问题：用户很快就不看了。

提示一多，用户很容易习惯性点击确认，甚至开启类似“全部放行”的 YOLO mode，让任务先跑起来。这样一来，审批机制原本想起到的保护作用就会被削弱。

OpenClaw 的方向，是减少无意义提示，让真正重要的提示更准确。

命令审批首先要看懂命令

简单的字符串匹配并不可靠，因为危险操作可能被包在 bash -c 这类外层封装命令里。

例如，表面上看到的是：

bash -c

但完整命令可能是：

bash -c "rm -rf ~/something"

如果审批系统只识别外层的 bash，却没有继续解析内部命令链，就可能漏掉真正的风险。OpenClaw 的命令审批会继续检查这类 shell -c 封装命令中的内部内容，识别其中真正要执行的可执行程序。

Shell 命令审批流程如何处理？

OpenClaw 的 Shell 命令审批流程，会继续解析 shell -c 这类外层封装命令中的内部命令链。

如果内部命令链里包含不被允许的可执行程序，外层封装并不会让这条命令变得安全。

命令高亮器还会使用 Tree-sitter 进行语法解析，把识别出来的内部命令展示给用户，让用户看清真正即将执行的内容。

PowerShell 的情况更复杂。对于无法准确识别的命令形式，OpenClaw 采用“无法识别就不默认放行”的处理方式，避免把风险命令误判为安全。更完整的 PowerShell 支持仍在后续计划中。

审批难点在于什么时候提醒用户

命令解析只是第一步，更难的是判断什么时候需要提醒用户确认。

固定的允许清单或拒绝清单，很难理解当前任务的具体语境。用户真正关心的不是某条命令在规则表里属于哪一类，而是：

这条命令是否符合当前任务目标？这是不是自己希望 OpenClaw 执行的动作？

因此，OpenClaw 正在探索“上下文审批”，也就是结合当前任务、命令内容和执行场景来判断是否需要用户确认。

它的目标不是增加更多提示，而是减少无意义提示，让真正需要确认的提示更值得用户停下来阅读。

对于 OpenAI 用户，OpenClaw 还提供 Auto Review。这个功能主要用于 Codex 场景，会在沙箱边界引入一个单独的审查智能体，用来替代部分人工审批。

05 代码检查：把历史漏洞变成长期有效的检查规则

OpenClaw 的安全建设还延伸到了代码检查环节。

修复漏洞只是第一步。每一条 GitHub 安全公告背后，往往都对应着一类容易反复出现的代码问题。漏洞修完之后，还需要继续检查：类似代码是否仍然存在，后续提交会不会再次引入同类问题。

OpenGrep 和 CodeQL 的作用

OpenClaw 使用 OpenGrep 和 CodeQL 来做代码安全检查。

OpenGrep 的规则会关联到具体的安全公告、安全报告或代码审查发现。这样，过去发现过的问题就可以沉淀为可重复执行的检查规则。

它的主要目标有两个：

1. 1. 回归检测：如果同类漏洞再次出现，CI 可以在人工审查之前发现问题；
2. 2. 变体检测：识别同一类问题的相近变种，避免只修掉表面上的一个点。

目前，OpenClaw 已经提交的精确 OpenGrep 规则包包含 148 条规则。这些规则会在 Pull Request 的代码变更部分运行，也可以手动执行全量扫描。

CodeQL 则用于更深层的语义检查。两者配合使用，可以兼顾规则精度和代码覆盖面。

安全检查也要控制噪声。告警太多、太泛，开发者很容易忽略。

无论是命令审批，还是代码扫描，提示的质量都比数量更重要。

写在最后

整体来看，OpenClaw 的安全建设主要围绕五类关键动作展开：

这些设计指向同一个目标：

OpenClaw 可以继续保持较强的执行能力，但文件、网络、插件、命令和代码流程中的关键动作，需要更清楚、更可控，也更容易审计。

对于运行在用户真实电脑上的 AI 个人助手来说，安全能力本身就是产品能力的一部分。

只有把文件访问、网络请求、插件安装、命令执行和代码检查这些关键环节管清楚，用户才更有信任基础，也更容易放心让它在真实环境中完成任务。