我们的目标是让 OpenClaw 成为一种值得信赖的方式，用来运行强大的 AI 个人助手。
OpenClaw 可以读取文件、运行命令、安装插件、访问网络，并代表真实用户在真实机器上执行操作。这样的能力很容易被描述成危险，这种担心是合理的。但强大并不一定意味着盲目、无边界，或无法审计。
其中有些能力已经落地，有些正在逐步推出，有些仍在开发中，还有一些仍处于研究阶段。我想把这些区别说清楚，因为模糊这些边界的文章会误导读者。
文件系统边界与 fs-safe
OpenClaw 运行在你的机器上。这意味着它可以接触你的文档、代码库和照片。
人们谈到文件系统风险时，通常最先想到路径穿越。这个风险是真实存在的，但它也只是更大一类问题的一个症状：边界不清。代码以为自己在某个根目录内写入，但符号链接、绝对路径、压缩包解包或草率的路径拼接，都可能让它越过另一个边界。
fs-safe 是对此的一种回应。它把 OpenClaw 已经在沉淀的一组安全文件系统模式抽成共享库，让核心代码、插件和相邻服务都能使用同一套受根目录约束的基础能力。
它不是沙箱。一个被允许运行任意 shell 命令的插件，仍然可以做任意 shell 命令能做的事。fs-safe 保护的是文件系统代码里的越界类漏洞。
在插件工作区内写入应该成功。穿越路径和写入工作区外绝对路径应该失败。插件作者不应该反复自己实现这些检查。
outside-workspace 被拒绝。下一步是让这些基础能力也成为 ClawHub 插件的预期模式。绕过它们并不自动代表恶意，但它与安全相关。随着时间推移，这类选择应该影响插件的信任姿态。
最安全的文件系统调用，仍然是我们根本不发起的调用。这也是正在推进的 SQLite 运行时状态重构背后的安全动机。会话、转录记录、调度器状态和插件状态应该放在一个有明确所有权和事务的类型化数据库中，而不是散落的文件里。把运行时状态迁入 SQLite，可以从运行路径中移除整类文件系统访问。
网络出口与 Proxyline
在智能体系统里，SSRF 比普通 Web 服务更难处理。在普通服务中，由用户控制的 URL 往往是例外；在智能体运行时中，由用户控制或受模型影响的 URL 是正常产品行为。“有人或某个东西要求获取这个 URL，所以去抓取它”是正常工作。
我们一开始采用了最直观的做法：在抓取前验证 URL。但这还不够。验证会解析一次 DNS，真正抓取时又会再解析一次 DNS，而两次之间答案可能改变。一个在验证时指向公网 IP 的主机，等请求真正发出时，可能已经指向元数据端点。
修复点必须更靠近出口。
Proxyline 就是我们的 Node 进程路由层。它为 Node 网络接口安装进程级路由，并把流量发送到你配置的代理。真正的连接时策略应该放在配置的代理上：阻止元数据地址、私有网段、回环探针，以及你的环境需要阻止的任何目标。
Proxyline 负责路由，代理负责执行策略。
它也给运维人员带来可观察性。如果你已经在使用托管代理，就可以让 OpenClaw 通过它出网，并在你已经信任的基础设施里观察目的地、请求速率和被阻止的尝试。
Proxyline 并不是能困住每一个字节的完美笼子。原始 socket、原生模块、非常规传输、过早捕获的 agent，以及非 OpenClaw 的子进程，仍然可能绕过 Node 层防护。但对于普通的 OpenClaw 网络路径，把控制点从“某个包装器记得验证这个 URL”移到“出口流量经过代理策略”，形态要好得多。
验证路径很简单：example.com 应该通过，回环探针应该失败，openclaw proxy validate 应该证明配置的路由确实如此工作。
example.com，阻止回环探针，并且 openclaw proxy validate 通过。ClawHub 上的插件信任
当插件来自 ClawHub 时，ClawHub 必须成为插件信任与来源的权威。OpenClaw 应该在安装和更新期间消费这些信号，而不是事后只依赖本地检查。
ClawHub 流水线混合使用多种信号：ClawScan、VirusTotal、静态分析、元数据检查、源码来源和人工审核。这些都不是魔法。扫描器会以不同方式产生噪音，而一个对所有事情都尖叫的流水线，只会训练用户忽略它。
这正是 ClawHub 能做而本地安装流程做不到的地方。它可以把信任证据绑定到特定包版本。它可以说明某个版本是干净、可疑、暂缓、隔离、撤销还是恶意。它可以阻止恶意或隔离版本下载。它也可以向用户展示发生了什么变化，以及为什么。
插件可以来自 GitHub、私有注册表，或别人发给你的文件。这不会消失，OpenClaw 也不应该假装用户不拥有自己的机器。
我们能做的是让安全路径变得更好。在 ClawHub 发布，接受扫描，附上证据，让用户在安装前权衡这些证据。
我们也在探索基线之上的更高信任层级：官方包、可信发布者，以及遵循更严格审核预期的包。对于存在于 ClawHub 之外的插件，我们也希望扫描能够覆盖它们，但确切的产品形态仍需要继续打磨。
如果 ClawHub 将某个版本标记为恶意并隔离，ClawHub 安装路径就应该拒绝它。这就是标准。
命令审批与提示疲劳
提示弹出的速度比任何人阅读的速度都快。几分钟后，用户就会打开 YOLO 模式，让工作继续跑下去。到那时，这些提示反而训练用户停止阅读。
修复这个问题意味着更少的提示，以及更好的提示。
准确性从解析开始。字符串匹配不够。如果允许列表或阻止列表只能看到外层命令，包装器就会成为绕过方式。一个理解 rm、却看不到 bash -c "rm -rf ~/something" 内部内容的策略，不是用户应该信任的策略。
现在，shell 审批路径会评估常见 shell -c 包装器中的内部命令链。如果内部链包含不被允许的可执行程序，外层包装器不应该让它变安全。命令高亮器也使用 Tree-sitter 展示 OpenClaw 在包装器内部发现了什么。
PowerShell 有自己的陷阱；对于我们无法理解的形式，我们会默认失败关闭，更广泛的支持也在路线图上。
解析是较容易的一半。更难的一半是决定什么时候该询问用户。
静态审批策略要么对所有可能有风险的内容都弹提示，要么依赖固定的允许/拒绝列表，而它无法判断某条命令是否符合当前任务。
用户真正关心的问题是：这是我想让它发生的吗？
这就是我们正在实验上下文审批的原因。目标不是“永远不提示”。目标是让提示真正有意义，并且当它出现时，用户应该停下来阅读。
对于 OpenAI 用户，我们提供 Auto Review。这是 Codex 专属功能，会在沙箱边界用独立的审查 agent 替代人工审批。
静态分析
OpenClaw 曾经收到过不少 GitHub Security Advisories。第一项工作是补洞。下一项工作，是确保同一类漏洞不会回来。
在一个安全公告被修复后，很容易说事情已经结束。但 GHSA 说明的是一类漏洞，而不只是一个漏洞。分诊后的问题应该是：我们能不能找出所有看起来像这样的代码？
为此，我们使用 OpenGrep 和一组精确规则包。每条规则都关联到某个公告、报告或审查发现。基线目标是回归检测：如果同样的脆弱形态再次出现，CI 会在代码审查前抓住它。更好的目标是变体检测：抓住同一错误的相近版本。
精确性就是一切。嘈杂的规则比没有规则更糟，因为它会训练团队忽略这个通道。
今天，仓库中受检入库的精确 OpenGrep 规则包包含 148 条规则。它会在 PR diff 上运行，完整扫描也可以手动执行。新修复的安全公告会成为新增规则的候选来源。
CodeQL 会并行运行，用来提供更深层的语义覆盖。它更慢，也更难维护；我们两者都会使用。
这对 OpenClaw 用户意味着什么
OpenClaw 并不会变得不强大。我们是在让边界更容易看见，也更容易防守。
我们不会承诺零风险 agent。任何这样承诺的人，要么是在卖东西，要么还没有交付过足够多真实系统。
我们能承诺的是方向。OpenClaw 可以保持强大，同时变得更可防御。这正是我们正在构建的东西。