不到半年，143 次更新，最后长出了一套企业级安全体系。

这个故事的真正有趣之处，不在于它有多少安全功能，而在于这些安全能力是怎么"长出来"的。不是蓝图，不是设计文档，是一次又一次被真实威胁逼到墙角后的工程选择。

不到半年的项目，143 个版本。这个频率本身就说明了很多。

一、OpenClaw 的安全起点：功能优先，信任链式扩展

要理解 OpenClaw 今天的安全体系，先要理解它的安全起点。

OpenClaw 最早期的设计哲学，是典型的"功能优先"思维。一个能在 20 个消息渠道上跑 AI Agent 的网关工具，最初吸引用户的是什么？多渠道覆盖、API 灵活接入、记忆和会话管理。这些能力是真实的，也是 OpenClaw 早期增长的核心驱动力。

但"功能优先"的另一面，是安全模型建立在隐式信任的基础上——而且，这个"早期"距离今天只有不到半年。

第一层信任：用户信任自己安装的 Skill。 Skill 是 OpenClaw 的扩展机制，每一个 Skill 都是一个带有执行权限的代码包。早期版本中，Skill 的权限边界是宽松的——安装在本地目录后，就可以访问 Gateway 进程范围内的几乎所有资源。一旦用户安装了一个来源可信度不高的 Skill，攻击者就拥有了和 Gateway 同等的操作权限。

第二层信任：Gateway 信任所有连接的消息渠道。 OpenClaw 作为消息网关，需要处理来自 Telegram、Slack、Discord、飞书等不同渠道的消息。早期版本中，渠道接入的认证模型相对简单，部分渠道的 allowFrom 规则依赖配置而非强制执行。

第三层信任：workspace 信任所有环境变量。 OpenClaw 的 workspace 目录可以存放 .env 文件。早期版本中，workspace 下的 .env 文件可以注入带有 OPENCLAW_* 前缀的运行时控制键。

这套信任模型，在个人使用场景下不是问题。但当 OpenClaw 的部署量快速增长、企业用户开始评估它的生产可用性时，这套模型的脆弱性开始暴露。

关键在于，从第一个版本到第一个重大安全响应，之间只隔了不到半年。这个时间窗口比大多数安全团队的预期短得多。

二、真实威胁如何驱动安全体系"长出来"

OpenClaw 安全能力的演化，不是遵循一份预定的安全路线图，而是被一系列真实发生的安全事件推动的。

第一个转折点：ClawHub 恶意 Skill 事件

2026 年初，安全研究人员发现了 ClawHub（OpenClaw 官方 Skill 市场）上的多个恶意 Skill。这些 Skill 使用了有诱惑力的名称和描述，诱导用户安装，执行时却在后台运行恶意代码。攻击者利用了 OpenClaw 对 Skill 执行权限的宽松配置，获得了和 Gateway 进程同等的操作权限。

这个事件暴露了一个根本性矛盾：Skill 的扩展性是 OpenClaw 最重要的能力之一，但这个扩展性建立在对 Skill 来源和行为的信任之上。一旦这个信任被打破，攻击者就可以利用 Skill 的高权限属性，将 OpenClaw 实例变成攻击跳板。

事件之后，OpenClaw 在近期版本中引入了 skills.install.allowUploadedArchives opt-in 门控：用户必须显式允许，才能上传和安装 zip 格式的 Skill 归档文件。这是一个关键的安全范式转变——从"信任扩展"到"最小权限扩展"。配置默认关闭，而不是默认开放。

第二个转折点：容器逃逸链的公开

2026 年第一季度，多个安全社区和研究人员公开了 OpenClaw Docker 部署环境下的容器逃逸攻击路径（最早被分配编号 CNVD-2026-13380）。攻击者通过已知公开技术细节，可以在 5 个步骤内从 Docker 容器逃逸到宿主机，获取系统敏感文件并植入持久后门。整个攻击链不需要零日漏洞，是工程配置问题而非代码漏洞——这暴露出早期部署文档在生产环境安全配置指引（Hardening Guide）上的缺失。

OpenClaw 官方在近期版本中强化了 Docker 安全相关的文档和默认配置，特别是 DOCKER-USER iptables 链的配置要求。这是一个典型的"被问题逼出来的安全加固"——在事件公开之前，这个配置缺陷没有在官方文档中得到明确说明。

第三个转折点：三大厂商的同期安全公告

2026 年 3 月，CrowdStrike、Cisco 和 Microsoft 在不到 30 天内，各自发布了针对 OpenClaw 部署的安全公告。安全行业极为罕见的同期独立公告模式——不是各自发现了不同漏洞，而是各自面对同一个体系性风险。

三份公告的核心信息相同：OpenClaw 实例被攻破后，攻击者获得的不是一个小工具，而是一套覆盖整个业务运营的"管理平面"。OpenClaw 作为消息网关，通常持有多个渠道的访问权限、API 密钥以及对内部系统的调用能力。这个管理平面一旦被攻破，攻击者可以用它来横向移动、数据窃取和持久化驻留。

这三份公告推动 OpenClaw 社区对安全架构的全面重新评估。从那时起，安全更新不再只是修复具体技术漏洞，而是开始收紧默认安全边界，重新设计关键操作的权限模型。

跑马圈地：中国OpenClaw安全防护产品盘点

三、四层防护体系的生长逻辑

从真实威胁的反馈中，OpenClaw 的安全架构逐渐形成了一个四层防护体系。每一层都对应着一个具体的安全问题和对应的工程响应。

第一层：身份层——从"配置可选"到"强制执行"

核心问题是：谁有权限访问 OpenClaw 实例，以及他们可以执行什么操作。

近期版本中，OpenClaw 在身份层做了大量收紧工作。channels.{platform}.allowFrom 规则的强制执行，不再只是建议配置；dmPolicy 和 allowFrom 配置别名统一化，让跨渠道访问控制策略保持一致；配对设备的可见性收紧，移动节点和桌面客户端的配对信息不再默认对所有会话可见，需要显式授权。

这些变化的共同特征是：把原来"推荐的最佳实践"变成了"不可绕过的默认"。不是安全功能的增加，而是安全默认值的迁移。

第二层：执行层——从"开放扩展"到"最小权限"

核心问题是：Skill 和插件可以在 OpenClaw 环境中执行什么操作，它们如何获得执行权限。

before-tool-call 授权钩子的引入是这个层面的关键变化。在执行任何 Skill 或插件工具之前，OpenClaw 现在会先检查一个授权层——允许管理员定义细粒度操作策略，例如禁止某个 Skill 访问文件系统、禁止执行特定的系统命令、或者要求对高风险操作进行人工确认。

inline skill dispatch 的权限收紧同样是重要变化。在此之前，Skill 的工具分发没有显式授权检查——现在，这个过程必须经过 before-tool 授权钩子，任何没有明确授权的 Skill 操作都会被拒绝或要求确认。

第三层：数据层——从"默认明文"到"默认保护"

核心问题是：OpenClaw 运行过程中产生的数据——日志、会话历史、API 密钥缓存——如何得到保护。

近期版本中，日志 redact 机制得到了显著强化。所有日志中的 auth、cookie 相关头部信息，现在都会被自动检测和脱敏处理。这意味着即使用户在调试时导出了 OpenClaw 日志，也不会意外泄露敏感的认证凭据。

敏感 payload 的持久化检测同样在加强。OpenClaw 明确增加了对"secret-shaped payload"的检测和 redact 规则——任何看起来像 API 密钥、Token、密码的字符串，都会在写入磁盘之前被标记和脱敏。这个能力对企业在合规审计场景下尤其重要——日志中不能出现的敏感信息，不应该依赖人工处理，而应该在系统层面被默认过滤。

第四层：可观测层——从"黑盒运行"到"透明可见"

核心问题是：当 OpenClaw 出现异常行为时，运维人员能否快速看清状态、定位问题、追踪影响。

cron list --json 和 cron show --json 的机器可读输出是这个层面的典型代表。在此之前，cron 任务的状态信息主要是给人阅读的格式，在需要自动化监控或系统集成时会遇到困难。现在，关键运营数据的输出格式正在向"机器可读"方向迁移，使得企业级监控和告警体系可以更好地与 OpenClaw 对接。

deliverySucceeded=false 的显式错误报告同样是重要变化。早期版本中，当消息发送操作失败时，系统有时会返回一个模糊的成功状态——操作"完成"了，但实际的投递结果并不明确。现在，失败状态会显式报告，运维人员可以更快地发现和响应问题。

session 历史血缘追踪和 model failover 诊断 OTLP 事件的导出，是在更深层次解决"黑盒运行"的问题。当 OpenClaw 长时间运行后出现异常，运维人员需要能够追溯：这个问题是什么时候开始的、是什么操作触发的、影响范围有多大。这些可观测性能力，解决的是企业级运营中真实存在的痛点——而不是纸面上设计出来的需求。

四、为什么说它是"长出来"而不是"建出来的"

观察 OpenClaw 的安全演进，一个核心区别是：它的安全能力是应对真实威胁后的工程收敛，而不是从一开始就规划好的设计蓝图。

这个区别很重要。

如果安全是"建出来的"，我们可以期待它有一份完整的架构图、一份详细的设计文档、一条清晰的从 A 点到 B 点的演进路径。但 OpenClaw 的安全演进没有这条路径。它的每一个重要安全更新，都对应着一个真实发生的事件：ClawHub 事件触发了 Skill 权限的门控收紧；容器逃逸公开触发了 Docker 安全配置的强化；三大厂商的公告触发了整个供应链信任模型的重新评估。

这不是设计，是被迫的工程选择。

但这恰恰是 OpenClaw 安全体系最有价值的地方。一个从真实事件中被迫收敛的安全体系，比一个设计良好的安全体系更值得信任——因为前者经历了真实威胁的验证，而后者可能还停留在纸面上。

更关键的是，这种"被迫收敛"的演进模式，在最近几个版本中正在转化为更主动的安全设计。OpenClaw 开始引入一些不再是单纯响应事件的安全更新：skills.install.allowUploadedArchives 的 opt-in 设计、before-tool-call 钩子的细粒度授权模型、workspace 环境的更强隔离。这些更新不再是"这个问题不能再拖了"，而是开始有了前瞻性的安全边界设计。

这意味着 OpenClaw 的安全体系正在从"被动响应"向"主动防御"过渡。但这个过渡还没有完成——它目前处于"有能力响应"和"尚未形成预防体系"之间的状态。这不是批评，而是企业用户在评估时需要知道的真实状态。

回到本文开头的问题：OpenClaw 的企业级安全体系是怎么"长出来"的？

答案是：它不是规划出来的，不是设计出来的，是被真实威胁一次又一次逼到墙角后，一次又一次选择"这个问题不能再拖了"之后，工程选择逐渐收敛的结果。

143 个版本背后（根据公开 release 记录统计），不是 143 次功能增加，而是 143 次功能与安全完善的跃迁，OpenClaw 至今仍处于极高速的迭代更新中。

这个逻辑，对每一个正在部署 AI Agent 的企业安全团队都值得关注。AI Agent 的安全边界到底在哪里？它今天解决了哪些问题？它还有哪些没有被发现的盲点？这些问题没有简单的答案，但它们值得每一个决策者认真对待。

OpenClaw 用 143 次版本更新证明了一件事：一个工具可以在被问题追着跑的同时，一步步建立起真正的安全体系。但这个证明的代价，是每一次"不能再拖"的选择背后的真实风险。理解这个逻辑，比记住它有多少安全功能重要得多。

本文基于截至 2026 年 5 月的第 143 个版本（根据公开 release 记录统计）分析，具体配置项请参考最新版官方文档。