如果让我重写 OpenClaw，我会从这六个安全问题下手

OpenClaw 是我用过的最强 AI Agent 框架之一。它也是目前最需要在安全架构上动手术的框架之一。这不是矛盾——强大的能力边界，放大了每一个设计缺陷的后果。本文不谈"怎么配置安全"，而是从设计者视角，聊聊如果重写，我会推倒哪些东西重来。

背景：一只强大但被频繁破防的龙虾

OpenClaw 的 GitHub 星标 26 万，4 个月登顶全球开源榜——速度之快，连安全基础设施都没跟上。

2026 年 3 月，GitHub Advisory Database 集中披露了数十个相关安全问题。国家信息安全漏洞库（NVDB）已收录多款高危漏洞。安全审计机构对 ClawHub 技能市场的 2,857 个 Skills 进行审计，发现约 36.82% 存在可利用安全缺陷，341 个被认定为恶意 Skills。

其中几个具体漏洞，让人看完沉默：

• CVE-2026-25253（CVSS 8.8）：Control UI 接受查询字符串中的 gatewayUrl 参数，攻击者构造一条钓鱼链接，用户点击即可将认证 Token 发送至恶意服务器，实现未授权 RCE
• CVE-2026-25157（CVSS 8.1）：特定 API 端点存在命令注入，参数未经过滤直接执行，无需身份校验即可在宿主机执行任意系统命令
• CVE-2026-28363：授权绕过与命令注入——白名单也防不住
• CVE-2026-28468：沙箱浏览器桥接服务器存在逃逸漏洞

这些不是边缘 bug，是架构层面的设计缺陷在代码里的表达。下面我逐一分析，如果重写会怎么做。

问题一：默认无认证——"开箱即用"等于"开箱即危"

现状：OpenClaw 默认将所有来自 localhost 的连接视为可信来源，出厂配置未启用任何身份验证。暴露在网络上的实例可被任何人访问。更危险的是，浏览器里的恶意 JavaScript 同样可以发起本地 WebSocket 连接，绕过"只信任 localhost"的逻辑。

根本问题：把"来源地址"当成"身份凭证"，是安全设计的经典错误。SSRF 攻击、CSWSH（跨站 WebSocket 劫持）都利用的正是这个假设。

如果重写，我会这样做：

• 默认强制认证，没有例外。首次启动必须完成 setup wizard 设置认证凭据，未完成则拒绝所有连接
• WebSocket 握手阶段验证 Origin header，维护一份显式 allowed origins 白名单，localhost 不在默认白名单内——要用要主动加
• 引入短期令牌（Session Token）机制，Gateway Token 绝不直接暴露在 URL 查询参数里。URL 参数是日志、referer、浏览器历史的常见泄露路径
• 对管理操作（重启、修改配置、安装 Skills）单独要求二次验证

问题二：API 密钥明文存储——最危险的"方便"

现状：OpenClaw 默认将 AI 服务、云服务的 API Key 以明文形式存储在本地配置文件中。一旦实例被入侵，攻击者直接读取配置文件就能拿到所有凭据。

根本问题：安全存储被当作"以后再说的功能"，而不是核心基础设施。

如果重写，我会这样做：

• 凭据分级存储：高敏感凭据（AI API Key、OAuth Token）强制使用系统级密钥链（macOS Keychain、Linux Secret Service、Windows Credential Manager），绝不落盘明文
• 配置文件只存引用，不存值：config.json 里存的是 {"apiKey": "keychain://openclaw/anthropic"}，而不是 {"apiKey": "sk-xxxx"}
• 内存中的密钥生命周期管理：用完即清，不在进程内存中长期驻留明文密钥
• 启动时密钥完整性检查：检测到配置文件中有明文密钥格式时，警告并引导迁移，而不是静默接受

问题三：Skills 供应链——12% 的市场毒药

现状：ClawHub 技能市场约 12% 的 Skills 被确认为恶意包，攻击手段包括：安装时执行任意脚本、运行时通过 SDK 读取配置和会话数据、提示词注入劫持 Agent 行为。

根本问题：Skills 的安装和执行权限与 Agent 本体几乎无差别，没有隔离边界，没有权限声明，没有审计机制。

如果重写，我会这样做：

• Skill 权限清单（Manifest）强制声明：每个 Skill 必须显式声明它需要的权限（read:files、exec:shell、access:network、read:config），安装时展示给用户确认，超出声明范围的调用直接拦截
• Skill 运行时沙箱隔离：Skill 运行在独立的 worker 进程中，通过受控 IPC 通信，不能直接访问主进程的内存、配置和凭据
• 安装前静态扫描：官方市场对所有 Skills 进行自动化恶意代码扫描（提示词注入检测、危险 API 调用检测）；本地安装的第三方 Skill 默认进入"隔离沙箱模式"，需要用户手动提升信任级别
• 版本哈希锁定：安装后锁定 Skill 版本哈希，阻止供应链投毒的"更新攻击"

问题四：提示注入——Agent 的身份被劫持

现状：OpenClaw 的 Agent 会处理来自网页、邮件、文档、群消息等大量外部来源的内容。这些内容可以携带伪装成普通文本的恶意指令，诱导 Agent 忽略系统规则、泄露凭据、调用未授权工具，甚至将整个会话的控制权转移给攻击者。

根本问题：Agent 对"系统指令"和"外部数据"没有严格的信任层级区分，全部混入同一个上下文窗口。

如果重写，我会这样做：

• 三层上下文信任模型：  
  •    
  • L1 系统层（最高信任）：SOUL.md、系统 Prompt、平台级配置——只有本地文件系统可以写入
  •    
  • L2 用户层（受信任）：直接来自已认证用户的消息
  •    
  • L3 外部数据层（不可信）：网页内容、邮件正文、文档、工具返回结果——这里的任何"指令"都必须被 Agent 忽略
  •  
• 外部内容标记与过滤：所有通过工具抓取的外部内容，在进入上下文前被打上 [EXTERNAL_UNTRUSTED] 标签，系统提示中明确禁止将 L3 内容升级为操作指令
• 可疑模式检测层：对"忽略之前的指令"、"你现在是……"、"system:"等常见注入模式进行语义检测，命中时生成安全告警而不是执行
• 操作确认缓冲区：高风险操作（发送消息、删除文件、调用外部 API）在执行前输出操作摘要，等待用户确认，而不是直接执行

问题五：沙箱的"天花板"——隔离只到进程边界

现状：OpenClaw 的代码执行沙箱在某些场景下可被逃逸（CVE-2026-28468），且沙箱的隔离粒度停留在进程级别，没有系统调用过滤、文件系统命名空间隔离等更深层的保护。

根本问题：沙箱被当作"安全提示"而不是"安全边界"来实现。

如果重写，我会这样做：

• 多层纵深沙箱：  
  •    
  • 第一层：进程隔离（已有）
  •    
  • 第二层：系统调用白名单（seccomp 过滤器），只允许执行任务必需的系统调用
  •    
  • 第三层：文件系统视图隔离（chroot 或 namespace），代码执行只能看到被授权的目录
  •    
  • 第四层：网络命名空间隔离，默认无网络访问，需要网络的任务单独申请
  •  
• 沙箱配置由任务类型决定：不同类型的工具（读文件 vs 执行命令 vs 访问网络）获得不同级别的沙箱，而不是一刀切
• 沙箱逃逸监控：在沙箱外层部署行为监控，检测异常系统调用序列，主动触发告警和自动终止

问题六：审计日志——"出了事说不清"

现状：OpenClaw 默认没有完整的操作审计日志。工具调用记录不完整，无法追溯"是什么输入导致了什么操作"，事故发生后无法还原攻击链路。

根本问题：日志被当作"调试工具"而不是"安全基础设施"来设计。

如果重写，我会这样做：

• 结构化审计日志（JSONL 格式），每条记录包含：时间戳、会话 ID、操作来源（消息 ID + 频道）、工具名称、输入摘要（哈希）、输出结果、执行时长、异常标志
• 审计日志与操作日志严格分离：审计日志只追加不修改，存储在独立路径，Agent 本身无权限删除审计日志
• 异常行为自动标记：高频工具调用、短时间内大量文件操作、往外部发送大体积数据——这些模式自动触发告警，而不是等用户发现
• 会话回放能力：能够基于审计日志重建任意历史会话的操作序列，用于事故分析和安全审计

一张重写路线图

最后想说的

OpenClaw 的问题，本质上是一个快速成长的开源项目的共同困境：功能跑在了安全前面。当一个工具能读写你的文件、控制你的浏览器、代你发消息，它对安全设计的要求，比一个普通 Web 应用高出不止一个数量级。

我说"如果让我重写"，不是因为现在的 OpenClaw 不能用——而是因为我认为这六个问题都有明确的解法，且都应该是默认行为，而不是需要用户自己配置才能开启的选项。

安全最难的不是技术，是把"安全"从"可选项"变成"起跑线"。

参考来源：CVE-2026-25253、CVE-2026-25157、CVE-2026-28363、CVE-2026-28468 漏洞披露；中国信通院 & 腾讯云《AI Agent安全实践指引》（2026年3月）；先知社区 OpenClaw 漏洞静态分析；OWASP LLM Top 10（2025）；工信部 NVDB OpenClaw 安全风险通报。