文章总结： OpenClaw是一个自托管的多渠道AI智能体网关，支持通过聊天应用与AI编程智能体交互并实现数据本地化。文档分析了其核心组件的实现原理与安全机制，包括登录认证、Channels消息安全策略、文件系统隔离等，同时指出其存在的安全风险，如认证绕过、路径穿越、命令执行、容器隔离逃逸、Channels攻击面及供应链安全威胁。 综合评分： 88 文章分类： 漏洞分析,安全建设,应用安全,网络安全

---

OpenClaw机制与安全风险分析

原创

r0 r0

联想全球安全实验室

2026年4月10日 17:46 北京

在小说阅读器读本章

去阅读

点击蓝字 关注我们

OpenClaw简介

OpenClaw 是一个自托管的多渠道 AI 智能体网关(Gateway)，可以在任意操作系统上运行。它的核心定位是：让开发者和高级用户能够通过自己熟悉的聊天应用，随时随地与 AI 编程智能体进行交互，同时完全掌控自己的数据，无需依赖任何托管服务。OpenClaw还实现了一些有特色的功能，如通过在本地磁盘保存配置和用户对话交互数据，实现了跨会话的长久记忆和自适应行为；通过统一的接口，兼容了多个聊天应用的消息收发和应用内的特定操作。

OpenClaw核心组件与实现原理

本着一切不谈系统实现原理只凭空猜测风险都是耍流氓的原则，我们这里先从实现原理分析一些OpenClaw的核心组件。

登录认证

OpenClaw的登录认证机制主要在Gateway组件中实现，进行登录认证时，核心认证入口函数authorizeGatewayConnect负责整个认证流程，根据通信协议分别使用WebSocket(authorizeWsControlUiGatewayConnect)或HTTP(authorizeHttpGatewayConnect)进行连接认证。登录认证过程可以总结为下图：

我们先从核心的认证模式分析，Gateway支持四种认证模式，系统会根据配置(config.gateway.auth.mode)和传入的凭证来决定使用哪种验证方式，由ResolvedGatewayAuthMode类型定义的四种认证模式：

Token：OpenClaw默认使用Token进行认证，Gateway在启动时会随机生成或加载一个Token(通常在配置文件或环境变量 OPENCLAW_GATEWAY_TOKEN 中设置)。使用Token这种认证方式时，客户端在连接时必须提供Token，服务端使用防时序攻击的字符串比较safeEqualSecret来对比提供的Token和配置的Token是否一致。

password：类似于Token模式，使用用户自行设置的自定义字符串做验证，校验时同样使用safeEqualSecret做比较。

none：完全关闭认证。

trusted-proxy：从指定 HTTP 头(trustedProxy.userHeader)中提取用户身份，通过验证请求是否来自可信代理IP来判断认证是否通过。

然后我们分别分析WebSocket连接认证和HTTP连接认证。

OpenClaw的主要通信通过WebSocket进行，WebSocket的握手和认证流程可以大致分为如下过程：

1.连接请求:

客户端发起WebSocket连接。服务端发送connect.challenge事件，包含一个随机的nonce(一次性随机数)，用于后续的签名验证。

2.握手请求:

客户端发送第一条消息，必须包含connect方法的请求参数(ConnectParams)，ConnectParams包含客户端信息(ID,版本)、请求的角色(如operator、node)、请求的权限范围以及认证信息。

3.登录认证:

服务端调用resolveConnectAuthState进行登录认证。首先检查是否提供了全局Token或Password，若提供则使用。检查握手请求的ConnectParams是否包含设备信息(deviceId，publicKey)，如果包含则进行设备认证；设备认证过程主要进行了签名验证，具体为验证设备使用私钥对nonce的签名，确保请求未被篡改且来自持有私钥的设备；设备认证通过配对成功后会获得DeviceToken。

4.设备配对：

如果客户端提供了设备公钥但尚未配对或令牌无效，且未通过共享认证，服务端会触发requestDevicePairing设备配对。进行设备配对时，服务端会向管理员(已连接的Control UI或CLI)广播配对请求；管理员批准后，设备获得授权，并获取DeviceToken。

Channels

OpenClaw实现的一个非常有特色的功能就是用统一的接口，把常用的聊天应用的消息格式统一转化为了Agent能够理解的标准事件，这个功能官方文档抽象称为channels。由于通过channels可以直接给AI Agent下发指令，指令执行是Agent防御的核心，OpenClaw在实现channels时构建了一套安全体系：

1.私聊与群组

OpenClaw将聊天应用里的对话场景严格区分为私聊(Direct Message，DM)和群组(Group)，针对这两个场景分别有不同的安全策略。

DM策略：

1. pairing：DM默认使用pairing策略。在这种策略下，未在白名单中的用户发来消息时，系统不会直接执行指令，而是会回复一个“配对码”。用户必须在Gateway的控制台输入该配对码，完成设备绑定后，才可以成为受信任的发件人并在AI Agent中执行指令。这种配置策略可以有效防止陌生人攻击。
2. allowlist：只允许配置文件中allowFrom列表里的用户与AI Agent交互。
3. open：任何知道OpenClaw聊天应用账号的人都可以与它交互，这种配置策略是非常危险的。
4. disabled：禁用DM。

Group策略：

1. open：任何在群组中的人都可以和OpenClaw聊天应用账号交互，这种配置策略同样是非常危险的。
2. allowlist：只允许配置文件中channels列表中显式声明的群组才可以与AI Agent交互，且Group的allowlist名单和DM的allowlist名单是分开管理的。
3. disabled：禁用群组聊天。

2.白名单

OpenClaw的白名单系统(allowFrom)不仅仅是简单的字符串相等比较，它实现了一套比较复杂的解析引擎：

多维度匹配：支持根据 Sender ID、Username 甚至手机号进行匹配。

正则匹配：支持正则匹配和通配符，如配置为”*”则等同于open配置策略；白名单在比较前会统一转换为小写，以防止大小写绕过。

3.指令网关

OpenClaw实现了“使用权”和“管理权”的分离，消息中的普通对话和控制命令(如/reset，/system.run)会被严格区分。具体实现为，resolveControlCommandGate函数会检查当前发件人是否具备执行高级命令的权限，这样即使用户在allowFrom列表中具有向AI Agent发送消息的权限，但如果没有useAccessGroups的权限，他依然无法在AI Agent执行特权命令。

4.Webhook签名

OpenClaw支持两种主要的入站通信模式，Webhook和WebSocket。WebSocket主要用于Gateway连接各种内部客户端、外部平台，一般会采取前文登录认证部分的安全机制来保障安全性；Webhook会在公网暴露web接口，仅仅使用Bearer Token来进行认证是不够的，OpenClaw还在src/plugin-sdk/webhook-request-guards.ts采取了一些其他策略来进一步保证安全性：

请求方法限制：只允许POST请求，对扫描器常用的GET探测进行拦截。

请求载荷限制：preAuth限制最大请求为64KB，超时5秒；postAuth限制最大请求为1MB，超时30秒。限制请求载荷大小的原因是防止读取、处理无限大的HTTP body导致资源耗尽。

并发请求限制：使用createWebhookInFlightLimiter限制同一来源的并发请求数，默认单Key最大8个并发。

OpenClaw的channels安全体系建立在DM Pairing、Allowlist之上;

Channels是OpenClaw的亮点功能，但同时也需要我们正确配置才能最大发挥OpenClaw的作用。

文件系统隔离

OpenClaw 的文件系统安全分为多个层次，从底层路径验证到沙箱容器隔离，形成了比较完整的防御体系。

1. 容器隔离

OpenClaw通常默认启用沙箱模式，默认情况下会尝试在Docker容器中执行系统命令。OpenClaw的每个Agent或Session都运行在独立的Docker容器中，这天然的将Agent的文件系统操作限制在容器内部，使其无法直接访问宿主机的根文件系统；同时，在Docker启动时可以配置–read-only，使得容器的根文件系统变为只读，进一步防止恶意软件持久化或篡改系统文件。OpenClaw还会在Docker容器启动时过滤掉敏感的环境变量，防止宿主机的敏感信息(如API Key)泄露到沙箱环境中。

2. 路径防护

即使在Docker容器内部，OpenClaw也未将其视为完全受信的环境，在宿主机和Docker容器交互以及Agent执行文件操作时，实施了严格的应用层检查。

3. 根目录锁定

Docker容器内所有文件操作必须限制在配置的rootDir内，且校验解析后的绝对路径是否依然位于rootDir下，防止通过../进行路径穿越攻击。

4. 符号链接防护

OpenClaw会调用openVerifiedLocalFile和resolvePinnedWriteTargetWithinRoot显式检查路径中的每一级是否包含符号链接，如果检测到符号链接指向了rootDir之外，操作会立刻被阻断。这样的机制有效防御了Symlink Race攻击，即在文件检查和文件写入的时间间隔内替换符号链接以指向敏感文件。

5. 硬链接防护

OpenClaw会检查文件的硬链接数，如果文件有多个硬链接，操作会被拒绝。这样的机制防御通过创建指向敏感文件的硬链接来绕过权限检查的攻击。

原子写入与校验

文件写入操作采用“写入临时文件->重命名”的原子操作模式，写入完成后，会再次校验目标文件的身份，确保写入的文件是预期的文件且未被替换。

6. 沙箱文件系统桥接

OpenClaw实现了一个桥接层用于在Agent和Docker容器之间安全地进行文件传输、文件操作，桥接层设计了一些安全机制来进一步保障Docker容器的安全性：

在执行任何Shell命令前，预先解析和校验路径的安全性，确保操作的目标路径是合法的、可写的、不会逃逸rootDir；所有的文件操作都会被构建为一组经过校验的Shell命令计划(SandboxFsCommandPlan)，而非直接拼接字符串执行，这样进一步减少了命令注入的风险。

OpenClaw 的文件系统隔离采用了”容器隔离+应用层校验”的双重保险机制。容器提供了操作系统级别的强隔离，应用层的文件操作在代码逻辑层面防御了比较复杂的路径穿越和条件竞争攻击，确保了Agent在拥有执行Shell命令的同时也无法突破文件系统的边界。

OpenClaw风险分析

通过对OpenClaw核心组件的实现原理分析发现，尽管其实现时考虑了诸多的安全缓解措施，但这些安全措施并不成熟、这些安全措施实现时逻辑存在漏洞，这样一个庞大、复杂的AI Agent网关依旧存在安全风险，可以总结分为以下几类：

1. 认证绕过

OpenClaw的权限控制基于token验证、allowlist、api接口鉴权等等，但是由于OpenClaw支持多用户、多channels接入，权限模型非常复杂，在实现一些很细致的权限校验时容易出现逻辑漏洞。攻击者利用这些逻辑漏洞通常可以进行权限提升，比如访问自己原本没有权限访问的api接口、提升token权限等等，认证绕过是非常高危的漏洞，甚至可能导致OpenClaw网关直接被攻陷。

2. 路径穿越

AI Agent在工作时需要读取OpenClaw网关本地文件进行上下文理解、文件操作等，如果这些文件隔离不当、文件路径处理不当，攻击者就能读取或覆盖OpenClaw网关本地关键文件。路径穿越类漏洞一般出现在zip解压缩、符号链接、条件竞争攻击等攻击场景中，OpenClaw虽然在实现时考虑了类似的攻击场景并进行了防御性编码，但从历史漏洞数据来看，在一些细粒度的攻击场景下依然存在路径穿越的逻辑漏洞。

3. 命令执行

命令执行是AI Agent面临的最直接的威胁，因为OpenClaw的Agent被赋予了执行Shell命令的能力，一旦Agent执行了恶意的Shell命令，就可能造成数据丢失、数据泄露或OpenClaw网关直接被接管。我们或许无法假设AI永远不会曲解人类的意图，让AI能在拥有执行Shell命令进行自动化工作的同时保证AI不执行恶意Shell命令，这应该是AI模型和AI Agent亟待解决的问题。我们很高兴可以看到OpenClaw针对Agent的命令执行做了诸多安全防护，但是从历史漏洞分析在细微攻击场景的处理上OpenClaw依然犯了很多错误，比如命令允许列表可以通过命令拼接绕过，一些看似无害命令的特定搭配也会存在风险比如env -S可以用来执行任意拼接的命令，攻击者甚至可以通过URL编码绕过OpenClaw的前端正则、前缀检查。

4. 容器隔离

OpenClaw为了降低命令执行漏洞的风险，默认启用了Docker容器隔离即在Docker中执行Shell命令，但是OpenClaw的Docker隔离由于配置历史上也出现过漏洞。容器隔离模块出现的漏洞不会像命令执行、认证绕过一样直接造成非常严重的后果，但会对安全隔离体系造成破坏，如逃逸Docker在OpenClaw网关宿主机执行命令。虽然容器隔离会出现安全漏洞导致隔离失效，但容器隔离机制本身减小了别的模块出现安全漏洞时对网管宿主机本身的危害、降低了安全影响，无疑是非常优秀的安全机制和安全设计。

5. channels

OpenClaw的channels使用了统一的接口把常用的聊天应用的消息格式统一转化为了Agent能够理解的标准事件，channels是最直接暴露给攻击者的攻击面，攻击者利用channels模块的漏洞与OpenClaw聊天应用账号交互可以越权访问api接口、泄露OpenClaw网关数据、甚至直接接管OpenClaw网关。由于OpenClaw接入了诸多常用聊天应用，这套体系需要非常细化的身份验证、权限控制，针对特定应用的验证处理逻辑还需要安全研究人员和开发人员进一步深入检查。

6. 供应链安全

OpenClaw的AI Agent支持MCP、skills等工具调用，这些工具通过给AI提供描述和api接口，使得AI可以根据需求和工具描述调用工具获取所需的信息。MCP、skills本质就是桥接AI和外部工具的代码脚本，恶意的MCP、skills可以导致OpenClaw网关直接被攻陷。现阶段正确安装MCP、skills需要使用者提高甄别能力，更需要官方提供类似npm、PyPi的三方库市场，从而从源头上解决供应链的安全问题。

总结

OpenClaw作为一款开源、自托管的多渠道AI智能体网关，展现了本地化AI Agent架构的强大潜力。它通过打通多种聊天应用、引入容器隔离以及支持丰富的外部扩展MCP和skills，极大地提升了用户的工作效率和交互体验。然而，正是这种“高权限”与“高自由度”的结合，使其面临着前所未有的安全挑战。

通过对 OpenClaw 核心组件的实现机制及其历史漏洞的深度剖析，我们可以清晰地看到 AI Agent 系统在安全建设上的两面性：

一方面，OpenClaw 在架构设计之初就融入了大量防御性编码思想。例如，在登录认证中采用多模式混合校验，在 Channels 层引入了严格的私聊/群组策略和指令拦截机制，在文件系统层面通过 Docker 容器隔离与应用层路径安全防护构建了纵深防御。

另一方面，安全防御的复杂性往往成为漏洞的温床。多维度的权限模型极易在逻辑校验的细微处产生“木桶效应”，导致越权；而自然语言与底层代码之间的转换鸿沟，使得传统的黑白名单防御在面对花样百出的Shell命令注入、命令拼接时显得捉襟见肘。此外，随着第三方技能市场的繁荣，供应链投毒和间接提示词注入正逐渐成为难以防范的攻击向量。

综上所述，AI Agent 的安全并非一蹴而就，传统的 Web 安全防护手段在此类具有“自主执行能力”的系统中已不再充分。对于 OpenClaw 及类似框架的开发者和企业用户而言， 必须坚持“最小特权原则”，在核心敏感操作上强制引入人工确认机制，并建立严格的插件审查与网络外联白名单制度 。只有在安全治理与功能迭代之间找到平衡，才能真正发挥AI Agent自动化赋能的价值，避免其沦为攻击者渗透内网的“高级跳板”。

往期精彩合集

●当大模型拿起键盘：AI渗透测试实战技巧

●SSRF 防御：从 AOP 到 ProxySelector 的纵深防御

●跨层残差绕过LLM内生安全

●MCP Server 测试

●App 接口安全：被低估的系统安全边界

●联想全球安全实验室受邀补天白帽黑客沙龙，分享 AI 渗透测试实战硬核技巧

长

按

关

注

联想GIC全球安全实验室（中国）

[email protected]

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：联想全球安全实验室 r0 r0《OpenClaw机制与安全风险分析》