OpenClaw 被网页静默接管:本地 AI Agent 为什么比普通应用更危险?一份可以直接照着做的安全检查清单

但 OpenClaw 最近披露的一次漏洞，给出了一个相反的提醒。

安全研究团队 Oasis 发现，用户只要访问恶意网页，网页中的 JavaScript 就可能连接 OpenClaw 运行在本机的 WebSocket 网关，尝试破解网关密码，并把自己注册成受信任 设备。

整个过程不需要安装恶意插件，也不需要用户确认一串危险命令。

一旦接管成功，攻击者面对的不是一个普通聊天窗口，而是一个可能已经连接邮箱、 日历、消息平台、浏览器、文件系统和终端的本地 Agent。

这次漏洞已经在 OpenClaw v2026.2.25 中修复。

但补丁只能修复具体漏洞，不能替你解决更根本的问题：

一个网页，为什么能碰到本地 Agent？

这次漏洞被称为 ClawJacked。

OpenClaw 使用本地 Gateway 协调网页控制台、Agent 和其他连接节点。Gateway 默认 绑定在本机回环地址，看起来没有直接暴露到公网。

问题在于，浏览器里的网页脚本同样可以尝试连接 localhost。

攻击链大致是：

用户打开恶意网页        ↓网页 JavaScript 连接本地 WebSocket Gateway        ↓针对人类设置的弱密码进行高速尝试        ↓攻击者注册为受信任设备        ↓读取配置和日志，枚举节点，调用 Agent 能力

OpenClaw 官方发布说明显示，修复措施包括：

• 对浏览器直连 WebSocket 强制检查来源
• 对来自浏览器和本机回环地址的密码失败进行限流
• 阻止非 Control UI 网页静默自动配对

这几个修复点也解释了漏洞为什么成立：localhost 不是天然可信区，弱密码也挡不住 网页脚本的自动化尝试。

接管 Agent，后果为什么比接管普通应用更严重？

普通应用通常只负责一个功能。

图片编辑器主要访问图片，日历应用主要访问日程，聊天工具主要访问消息。即使其中 一个应用失守，攻击范围通常仍受它原有权限限制。

AI Agent 不一样。

为了替你“完成任务”，它往往被授予一组跨系统能力：

• 浏览网页和操作已登录账号
• 读取、修改或删除本地文件
• 执行 Shell 命令和启动进程
• 读取邮箱、日历和聊天消息
• 保存模型 API Key、OAuth Token 和平台凭证
• 调用远程节点、摄像头或其他设备能力

这些权限单独看都有合理用途，组合起来却会产生完全不同的风险。

攻击者不一定需要亲自攻破邮箱、浏览器和服务器。他只需要控制这个已经获得授权的 Agent，就可能借用 Agent 的身份继续行动。

例如：

读取项目文件→ 找到部署信息→ 读取凭证→ 登录内部服务→ 修改代码或配置→ 通过消息工具继续传播

这就是 Agent 特有的风险放大器：

普通应用与高权限 AI Agent 被接管后的影响范围对比

Agent 的真正风险，不只来自软件漏洞

ClawJacked 属于传统软件漏洞：认证、来源校验和配对机制存在缺陷。

但 Agent 还多了一类普通应用没有的入口：不可信内容也可能变成指令。

网页、邮件、文档、附件和搜索结果，本来只是 Agent 要读取的数据。其中却可以藏入 提示词注入，例如诱导 Agent 忽略原有规则、读取敏感文件或调用外部接口。

OpenClaw 官方安全文档也明确提醒：即使只有你能给 Agent 发消息，Agent 读取的 网页、邮件和文件仍然可能携带恶意指令。

因此，Agent 安全不能只做两件事：

• 不能只靠“它运行在本地”
• 不能只靠 System Prompt 写一句“不要执行危险操作”

提示词属于软约束。真正能限制攻击后果的，是工具白名单、文件范围、沙箱、网络边界 和操作审批。

最小权限配置：先把 Agent 当成新员工

配置 Agent 时，可以先问一个简单问题：

答案通常不会是：个人浏览器、整个 Home 目录、生产服务器和全部账号 Token。

网关只监听本机，并使用随机 Token

OpenClaw 官方推荐大多数场景使用 Token 认证，并保持 Gateway 绑定在回环地址：

{  gateway: {    mode: "local",    bind: "loopback",    port: 18789,    auth: {      mode: "token",      token: "使用足够长的随机Token"    }  }}

不要把 gateway.bind 改成 LAN 或公网地址后，仍然沿用弱密码。确实需要远程访问 时，应同时配置 TLS、认证、防火墙和明确的来源限制。

给 Agent 单独的浏览器资料

不要让 Agent 直接控制你日常使用、已经登录全部账号的浏览器 Profile。

更稳妥的方式是：

• 使用 Agent 专用浏览器 Profile
• 只登录任务需要的账号
• 不保存支付、密码管理器和管理后台会话
• 不需要浏览器时，直接关闭 browser 工具

文件权限从“无”或“只读”开始

OpenClaw 支持为不同 Agent 配置独立沙箱和工具策略。

处理外部网页、邮件和公开群消息的 Agent，可以先使用只读工作区：

{  agents: {    list: [      {        id: "reader",        workspace: "~/.openclaw/workspace-reader",        sandbox: {          mode: "all",          scope: "agent",          workspaceAccess: "ro"        },        tools: {          allow: ["read"],          deny: ["write", "edit", "apply_patch", "exec", "process", "browser"]        }      }    ]  }}

不要把整个 Home 目录作为工作区。SSH Key、云平台配置、浏览器数据和 OpenClaw 自身凭证都可能位于其中。

凭证按任务拆分，不复用管理员账号

给 Agent 创建独立账号和独立 Token，并限制权限范围：

• 邮箱只开放特定标签或专用邮箱
• GitHub 使用细粒度 Token，只授权目标仓库
• 云平台使用短期凭证，不使用根账号密钥
• 数据库优先只读账号
• 生产操作保留人工确认

任务结束后，及时撤销临时凭证。

让“读取”和“执行”分开

最危险的组合，是同一个 Agent 同时读取不可信内容，又拥有 Shell、文件写入和外发 能力。

更稳妥的设计是：

由 Gateway 防护、只读 Agent、人工审批和受限执行 Agent 组成的最小权限架构

一份可以直接照着做的安全检查清单

部署或升级本地 Agent 后，至少检查下面这些项目：

• [ ] OpenClaw 已升级到 v2026.2.25 或更高版本
• [ ] Gateway 默认绑定 loopback，没有直接暴露公网
• [ ] 使用足够长的随机 Token，而不是人类常用密码
• [ ] 没有启用 dangerouslyDisableDeviceAuth 等危险调试选项
• [ ] Agent 使用独立浏览器 Profile
• [ ] 不需要的 browser、exec、process 和写文件工具已关闭
• [ ] 工作区没有指向整个 Home 目录
• [ ] 处理外部内容的 Agent 已启用沙箱和只读权限
• [ ] API Key、OAuth Token 和生产凭证已按任务拆分
• [ ] 高风险操作需要人工审批
• [ ] 第三方 Skill 和插件已经审查来源及代码
• [ ] 日志和会话文件没有向其他本机用户开放读取
• [ ] 已执行 OpenClaw 官方安全审计

openclaw security auditopenclaw security audit --deep

修改配置、安装 Skill、开放远程访问或增加工具权限后，都应该重新运行审计。

不要把便利当成安全边界

OpenClaw 团队在收到报告后快速修复了 ClawJacked，这一点值得肯定。

对开发者来说，这次事件更重要的价值，是把一个容易忽略的事实摆到了台面上：

AI Agent 不是更聪明的聊天软件，而是一个拥有账号、权限、记忆和执行能力的数字 操作者。

你不能只问它“能不能完成任务”，还要问：

• 它能看到什么？
• 它能修改什么？
• 它能把数据发到哪里？
• 它被接管后，攻击者还能继续走多远？

我的建议不是停止使用本地 Agent，而是从低权限环境开始：专用账号、专用浏览器、 专用工作区、默认只读、按需开放工具。

OpenClaw 的具体漏洞已经修复，但 Agent 的权限组合风险不会随着一次升级自动消失。

本地部署值得尝试，前提是你把它当成一个需要隔离、审计和持续治理的执行主体，而 不是一个装完就能放心托管全部数字生活的普通应用。

你现在给 AI Agent 开放了哪些权限？欢迎在评论区对照清单检查一次。

关注「AI开源风向标」，获取持续更新的 AI 与开源开发工具清单。