过去 5 天里，围绕 OpenClaw（曾用名 Clawdbot、Moltbot）的安全风险讨论突然升温：一方面，工信部 NVDB 发布预警提示；另一方面，安全研究与媒体报道把问题进一步拆解到“配置习惯、权限模型、技能生态、提示词注入、凭证泄露”等更细的层面。

这篇文章把近期集中出现的观点和风险点做一次中文复盘：不制造恐慌，但把该补的安全课补上。

1. 这波风险为什么会“集中爆出来”？

OpenClaw 这类 AI 智能体与传统聊天机器人最大的不同，是它不仅“会说”，还会“做”：常见能力包括多渠道收消息（Telegram/Discord 等）、持久记忆、调用外部服务、自动化浏览器、读写本地文件、执行命令等。

能力越强，意味着“信任边界”越复杂：

• 你信任的不只是模型本身，还包括：部署方式、网络暴露面、鉴权策略、日志与记忆的存储方式、技能的质量、第三方集成的权限范围。
• 一旦出现“默认配置不安全”或“用户为了便利做了不当配置”，风险会从单点迅速扩散到系统级。

NVDB 的预警也直接点出：部分实例在默认或不当配置情况下存在较高安全风险，容易引发网络攻击、信息泄露等问题。

2. NVDB 预警在说什么：核心是“公网暴露 + 权限/审计不足”

根据 NVDB 预警转载内容，风险逻辑可以概括为三句话：

1) OpenClaw 具备持续运行、自主决策、调用系统与外部资源的特性；

2) 如果权限控制、审计机制、安全加固不足，可能被“指令诱导、配置缺陷、恶意接管”；

3) 结果可能是越权操作、信息泄露、系统被控。

给到的建议也非常务实：核查公网暴露、权限配置、凭证管理；关闭不必要公网访问；完善身份认证、访问控制、数据加密与安全审计；持续关注官方公告与加固建议。

把它翻译成更工程化的版本：

• 把“能访问的入口”收窄（减少暴露面）
• 把“能做的事情”收紧（最小权限）
• 把“做过什么”记录清楚（可审计）

3. 高发风险点拆解：从“被扫到就进来”到“看一眼文档就中招”

结合近期报道与安全厂商分析，OpenClaw 的风险主要集中在以下几类。

3.1 配置导致的公网“裸奔”与被动接管

不少智能体框架在本机开发时默认仅监听 127.0.0.1，但用户为了远程访问体验，会把监听地址改成 0.0.0.0，或在外层接反向代理、内网穿透。

问题是：

• 一旦外层鉴权不严，扫描器发现端口后可能直接进入控制界面/接口。
• 攻击者不需要“漏洞利用”，只需要“发现暴露”。

奇安信的分析进一步强调了这类“为了好用拆掉防御边界”的典型路径：开放端口、弱鉴权或未鉴权、接口被枚举后触发高权限能力，最终造成敏感数据与系统权限失控。

3.2 认证/信任边界的“本地人陷阱”（反代场景）

如果服务把来自 localhost 的请求当作天然可信，但又无法正确识别反向代理后的真实来源 IP，那么就可能出现：外部流量经过代理转发后“伪装成 127.0.0.1”，从而绕过原本应有的鉴权。

这类问题的可怕之处在于：

• 表面看起来“我加了反代/加了 TLS”，实际上可能把鉴权逻辑打穿。
• 容易被误配置放大，尤其在“教程驱动部署”场景里。

3.3 间接提示词注入（Indirect Prompt Injection）：内容即指令

智能体会读取外部内容（网页、邮件、文档、聊天记录），并把这些内容当作上下文的一部分来决策。

如果外部内容里混入“指令”，而智能体又没有清晰的安全策略（例如：把外部内容当作不可信数据、强制工具调用需要确认、对敏感操作设门槛），就可能出现“内容劫持行为”。

近期报道引用的研究给出了一个非常具象的链路：攻击载荷藏在文档中，诱导智能体创建新的聊天渠道（例如接入某个机器人），随后攻击者就能在新渠道里持续下发指令，最终演变成读文件、外传数据、执行恶意载荷等远程控制。

3.4 技能生态风险：恶意技能与“凭证明文流转”

如果技能市场允许任何人上传，而技能的说明/示例又鼓励用户把 API Key、密码、甚至支付信息“作为提示词输入”，风险会立刻变成系统性的：

• 机密信息可能进入模型上下文窗口，被第三方模型提供商处理
• 机密信息可能落到日志、记忆、对话历史里，被二次读取
• 恶意技能可能在执行链路里植入后门/数据外传

这一点在近期关于 ClawHub 生态的扫描与讨论中被反复提及：部分技能存在泄露敏感凭证的缺陷，甚至出现引导收集信用卡信息的高风险模式。

4. 受影响的“最小集合”：哪些人最该紧张？

不是所有 OpenClaw 用户都处在同一风险等级。按优先级，最需要立刻自查的是：

• 把网关/控制端口暴露到公网（含 0.0.0.0 监听、端口转发、内网穿透、云服务器直出）
• 与企业邮箱、IM、网盘、日历等生产力系统做了深度集成（权限大、数据敏感）
• 安装/运行来源不明技能，或习惯把 Key/Token 直接粘贴进对话
• 缺少“高危操作二次确认”的自动化流程（删除/下载执行/批量外传等）

一句话：你让它能访问什么、能执行什么、能记住什么，你就要对这些能力的“攻击面”负责。

5. 立刻能做的加固清单（不需要等官方更新）

以下建议来自 NVDB 预警中的方向，并结合智能体常见工程实践整理成可执行清单：

1) 网络暴露面

• 默认只监听本机（127.0.0.1）；如必须远程访问，优先用 VPN/零信任接入
• 禁止直接公网暴露控制面；必要时做 IP allowlist、强鉴权、强 TLS

2) 认证与权限

• 为控制面启用强 Token/强密码；禁用“默认口令/空口令”
• 明确区分：运行时身份（谁在发指令）与执行权限（它能做什么）

3) 记忆与日志

• 把“机密”从对话与记忆里隔离出去：Key/密码走专用密钥管理，不走提示词
• 缩短日志保留周期；对敏感字段做脱敏/屏蔽

4) 工具调用与高危操作

• 为删除文件、执行命令、网络外传等行为设置强制确认
• 对外部内容（网页/邮件/文档）引入“反提示词注入”策略：视为不可信输入

5) 技能与供应链

• 只安装可信来源技能；上线前做代码审计/静态扫描
• 给技能最小权限；隔离运行环境（容器/沙箱）

结语：AI 智能体不是“软件”，更像“可编排的权限集合”

OpenClaw 这波争议，本质上不是“开源不好”或“智能体必然危险”，而是：当一个系统同时拥有持续在线、多渠道入口、系统级权限、外部集成与可扩展技能时，它的安全模型必须从一开始就按“高权限控制平面”来设计和运维。

对个人用户来说，最现实的做法是：别让控制面上公网、别把机密当提示词、别让智能体无确认地执行高危操作。

对团队/企业来说，最关键的做法是：把它纳入资产与权限管理体系，做准入、做审计、做最小权限和隔离。

参考来源（近 5 天内传播较广的几篇）：

• 工信部 NVDB 预警转载（安全内参）：https://www.secrss.com/articles/87654
• 工信部 NVDB 预警转载（腾讯新闻，2 月 5 日）：https://news.qq.com/rain/a/20260205A05LH000
• 奇安信：对 Clawdbot（OpenClaw）风险的拆解（含公网暴露、反代信任等）：https://www.qianxin.com/news/detail?news_id=14490
• 新浪财经转载：聚焦提示词注入、恶意技能/凭证泄露等生态问题：https://t.cj.sina.com.cn/articles/view/1686203097/64816ad902701a96u