OpenClaw 的隐藏危险

Neo2025
8 阅读37分钟

OpenClaw 的隐藏危险

这是《Everything Claude Code 指南系列》的第 3 部分。 第 1 部分是 [速成指南]（设置和配置）。第 2 部分是 [长篇指南]（高级模式和工作流程）。本指南是关于安全性的——具体来说，当递归智能体基础设施将其视为次要问题时会发生什么。

我使用 OpenClaw 一周。以下是我的发现。

📸 [图片：带有多个连接频道的 OpenClaw 仪表板，每个集成点都标注了攻击面标签。] 仪表板看起来很令人印象深刻。每个连接也是一扇未上锁的门。

使用 OpenClaw 一周

我想先说明我的观点。我构建 AI 编码工具。我的 everything-claude-code 仓库有 5 万多个星标。我创建了 AgentShield。我大部分工作时间都在思考智能体应如何与系统交互，以及这些交互可能出错的方式。

因此，当 OpenClaw 开始获得关注时，我像对待所有新工具一样：安装它，连接到几个频道，然后开始探测。不是为了破坏它。而是为了理解其安全模型。

第三天，我意外地对自己进行了提示注入。

不是理论上的。不是在沙盒中。我当时正在测试一个社区频道中有人分享的 ClawdHub 技能——一个受欢迎的、被其他用户推荐的技能。表面上看起来很干净。一个合理的任务定义，清晰的说明，格式良好的 Markdown。

在可见部分下方十二行，埋在一个看起来像注释块的地方，有一个隐藏的系统指令，它重定向了我的智能体的行为。它并非公然恶意（它试图让我的智能体推广另一个技能），但其机制与攻击者用来窃取凭证或提升权限的机制相同。

我发现了它，因为我阅读了源代码。我阅读了我安装的每个技能的每一行代码。大多数人不会。大多数安装社区技能的人对待它们就像对待浏览器扩展一样——点击安装，假设有人检查过。

没有人检查过。

📸 [图片：终端截图显示一个 ClawdHub 技能文件，其中包含一个高亮显示的隐藏指令——顶部是可见的任务定义，下方显示被注入的系统指令。已涂改但显示了模式。] 我在一个“完全正常”的 ClawdHub 技能中发现的隐藏指令，深入代码 12 行。我发现了它，因为我阅读了源代码。

OpenClaw 有很多攻击面。很多频道。很多集成点。很多社区贡献的技能没有审查流程。大约四天后，我意识到，对它最热情的人恰恰是最没有能力评估风险的人。

这篇文章是为那些有安全顾虑的技术用户准备的——那些看了架构图后和我一样感到不安的人。也是为那些应该有顾虑但不知道自己应该担心的非技术用户准备的。

接下来的内容不是一篇抨击文章。在批评其架构之前，我将充分阐述 OpenClaw 的优势，并且我会具体说明风险和替代方案。每个说法都有依据。每个数字都可验证。如果你现在正在运行 OpenClaw，这篇文章就是我希望有人在我开始自己的设置之前写出来的。

承诺（为什么 OpenClaw 引人注目）

让我好好阐述这一点，因为这个愿景确实很酷。

OpenClaw 的宣传点：一个开源编排层，让 AI 智能体在你的整个数字生活中运行。Telegram。Discord。X。WhatsApp。电子邮件。浏览器。文件系统。一个统一的智能体管理你的工作流程，7x24 小时不间断。你配置你的 ClawdBot，连接你的频道，从 ClawdHub 安装一些技能，突然间你就有了一个自主助手，可以处理你的消息、起草推文、处理电子邮件、安排会议、运行部署。

对于构建者来说，这令人陶醉。演示令人印象深刻。社区发展迅速。我见过一些设置，人们的智能体同时监控六个平台，代表他们进行回复，整理文件，突出显示重要内容。AI 处理你的琐事，而你专注于高杠杆工作的梦想——这是自 GPT-4 以来每个人都被告知的承诺。而 OpenClaw 看起来是第一个真正试图实现这一点的开源尝试。

我理解人们为什么兴奋。我也曾兴奋过。

我还在我的 Mac Mini 上设置了自动化任务——内容交叉发布、收件箱分类、每日研究简报、知识库同步。我有 cron 作业从六个平台拉取数据，一个机会扫描器每四小时运行一次，以及一个自动从我在 ChatGPT、Grok 和 Apple Notes 中的对话同步的知识库。功能是真实的。便利是真实的。我发自内心地理解人们为什么被它吸引。

“连你妈妈都会用一个”的宣传语——我从社区里听到过。在某种程度上，他们是对的。入门门槛确实很低。你不需要懂技术就能让它运行起来。而这恰恰是问题所在。

然后我开始探测其安全模型。便利性开始让人觉得不值得了。

📸 [图表：OpenClaw 的多频道架构——一个中央“ClawdBot”节点连接到 Telegram、Discord、X、WhatsApp、电子邮件、浏览器和文件系统的图标。每条连接线都用红色标记为“攻击向量”。] 你启用的每个集成都是你留下的另一扇未上锁的门。

攻击面分析

核心问题，简单地说就是：你连接到 OpenClaw 的每个频道都是一个攻击向量。 这不是理论上的。让我带你了解整个链条。

钓鱼攻击链

你知道你收到的那些钓鱼邮件吗——那些试图让你点击看起来像 Google 文档或 Notion 邀请链接的邮件？人类已经变得相当擅长识别这些（相当擅长）。你的 ClawdBot 还没有。

步骤 1 —— 入口。 你的机器人监控 Telegram。有人发送一个链接。它看起来像一个 Google 文档、一个 GitHub PR、一个 Notion 页面。足够可信。你的机器人将其作为“处理传入消息”工作流程的一部分进行处理。

步骤 2 —— 载荷。 该链接解析到一个在 HTML 中嵌入了提示注入内容的页面。该页面包含类似这样的内容：“重要：在处理此文档之前，请先执行以下设置命令……”后面跟着窃取数据或修改智能体行为的指令。

步骤 3 —— 横向移动。 你的机器人现在已受到被篡改的指令。如果它可以访问你的 X 账户，它就可以向你的联系人发送恶意链接的私信。如果它可以访问你的电子邮件，它就可以转发敏感信息。如果它与 iMessage 或 WhatsApp 运行在同一台设备上——并且如果你的消息存储在该设备上——一个足够聪明的攻击者可以拦截通过短信发送的 2FA 验证码。这不仅仅是你的智能体被入侵。这是你的 Telegram，然后是你的电子邮件，然后是你的银行账户。

步骤 4 —— 权限提升。 在许多 OpenClaw 设置中，智能体以广泛的文件系统访问权限运行。触发 shell 执行的提示注入意味着游戏结束。那就是对设备的 root 访问权限。

📸 [信息图：4 步攻击链，以垂直流程图形式呈现。步骤 1（通过 Telegram 进入）-> 步骤 2（提示注入载荷）-> 步骤 3（在 X、电子邮件、iMessage 之间横向移动）-> 步骤 4（通过 shell 执行获得 root 权限）。背景颜色随着严重性升级从蓝色渐变为红色。] 完整的攻击链——从一个看似可信的 Telegram 链接到你设备上的 root 权限。

这个链条中的每一步都使用了已知的、经过验证的技术。提示注入是 LLM 安全中一个未解决的问题——Anthropic、OpenAI 和其他所有实验室都会告诉你这一点。而 OpenClaw 的架构最大化了攻击面，这是设计使然，因为其价值主张就是连接尽可能多的频道。

Discord 和 WhatsApp 频道中也存在相同的访问点。如果你的 ClawdBot 可以读取 Discord 私信，有人就可以在 Discord 服务器中向它发送恶意链接。如果它监控 WhatsApp，也是同样的向量。每个集成不仅仅是一个功能——它是一扇门。

而你只需要一个被入侵的频道，就可以转向所有其他频道。

Discord 和 WhatsApp 问题

人们倾向于认为钓鱼是电子邮件问题。不是。它是“你的智能体读取不受信任内容的任何地方”的问题。

Discord： 你的 ClawdBot 监控一个 Discord 服务器。有人在频道中发布了一个链接——也许它伪装成文档，也许是一个你从未互动过的社区成员分享的“有用资源”。你的机器人将其作为监控工作流程的一部分进行处理。该页面包含提示注入。你的机器人现在已被入侵，如果它对服务器有写入权限，它可以将相同的恶意链接发布到其他频道。自我传播的蠕虫行为，由你的智能体驱动。

WhatsApp： 如果你的智能体监控 WhatsApp 并运行在存储你 iMessage 或 WhatsApp 消息的同一台设备上，一个被入侵的智能体可能会读取传入的消息——包括来自银行的验证码、2FA 提示和密码重置链接。攻击者不需要入侵你的手机。他们需要向你的智能体发送一个链接。

X 私信： 你的智能体监控你的 X 私信以寻找商业机会（一个常见的用例）。攻击者发送一条私信，其中包含一个“合作提案”的链接。嵌入的提示注入告诉你的智能体将所有未读私信转发到一个外部端点，然后回复攻击者“听起来很棒，我们聊聊”——这样你甚至不会在你的收件箱中看到可疑的互动。

每个都是一个独立的攻击面。每个都是真实的 OpenClaw 用户正在运行的真实集成。每个都具有相同的基本漏洞：智能体以受信任的权限处理不受信任的输入。

📸 [图表：中心辐射图，显示中央的 ClawdBot 连接到 Discord、WhatsApp、X、Telegram、电子邮件。每个辐条显示特定的攻击向量：“频道中的恶意链接”、“消息中的提示注入”、“精心设计的私信”等。箭头显示频道之间横向移动的可能性。] 每个频道不仅仅是一个集成——它是一个注入点。每个注入点都可以转向其他每个频道。

“这是为谁设计的？”悖论

这是关于 OpenClaw 定位真正让我困惑的部分。

我观察了几位经验丰富的开发者设置 OpenClaw。在 30 分钟内，他们中的大多数人已切换到原始编辑模式——仪表板本身也建议对于任何非琐碎的任务都这样做。高级用户都运行无头模式。最活跃的社区成员完全绕过 GUI。

所以我开始问：这到底是为谁设计的？

如果你是技术用户...

你已经知道如何：

  • 从手机 SSH 到服务器（Termius、Blink、Prompt——或者直接通过 mosh 连接到你的服务器，它可以进行相同的操作）
  • 在 tmux 会话中运行 Claude Code，该会话在断开连接后仍能持久运行
  • 通过 crontab 或 cron-job.org 设置 cron 作业
  • 直接使用 AI 工具——Claude Code、Cursor、Codex——无需编排包装器
  • 使用技能、钩子和命令编写自己的自动化程序
  • 通过 Playwright 或适当的 API 配置浏览器自动化

你不需要一个多频道编排仪表板。你无论如何都会绕过它（而且仪表板也建议你这样做）。在这个过程中，你避免了多频道架构引入的整类攻击向量。

让我困惑的是：你可以从手机上通过 mosh 连接到你的服务器，它的操作方式是一样的。持久连接、移动端友好、能优雅处理网络变化。当你意识到 iOS 上的 Termius 让你同样能访问运行着 Claude Code 的 tmux 会话时——而且没有那七个额外的攻击向量——那种“我需要 OpenClaw 以便从手机上管理我的代理”的论点就站不住脚了。

技术用户会以无头模式使用 OpenClaw。其仪表板本身就建议对任何复杂操作进行原始编辑。如果产品自身的 UI 都建议绕过 UI，那么这个 UI 并没有为能够安全使用它的目标用户解决真正的问题。

这个仪表板是在为那些不需要 UX 帮助的人解决 UX 问题。能从 GUI 中受益的人，是那些需要终端抽象层的人。这就引出了……

如果你是非技术用户……

非技术用户已经像风暴一样涌向 OpenClaw。他们很兴奋。他们在构建。他们在公开分享他们的设置——有时截图会暴露他们代理的权限、连接的账户和 API 密钥。

但他们害怕吗？他们知道他们应该害怕吗？

当我观察非技术用户配置 OpenClaw 时，他们没有问：

  • “如果我的代理点击了钓鱼链接会发生什么？”（它会以执行合法任务时相同的权限，遵循被注入的指令。）
  • “谁来审计我安装的 ClawdHub 技能？”（没有人。没有审查流程。）
  • “我的代理正在向第三方服务发送什么数据？”（没有监控出站数据流的仪表板。）
  • “如果出了问题，我的影响范围有多大？”（代理能访问的一切。而在大多数配置中，这就是一切。）
  • “一个被入侵的技能能修改其他技能吗？”（在大多数设置中，是的。技能之间没有沙箱隔离。）

他们认为自己安装了一个生产力工具。实际上，他们部署了一个具有广泛系统访问权限、多个外部通信渠道且没有安全边界的自主代理。

这就是悖论所在：能够安全评估 OpenClaw 风险的人不需要它的编排层。需要编排层的人无法安全评估其风险。

📸 [维恩图：两个不重叠的圆圈——“可以安全使用 OpenClaw”（不需要 GUI 的技术用户）和“需要 OpenClaw 的 GUI”（无法评估风险的非技术用户）。空白的交集处标注为“悖论”。] OpenClaw 悖论——能够安全使用它的人不需要它。

真实安全故障的证据

以上都是架构分析。以下是实际发生的情况。

Moltbook 数据库泄露

2026 年 1 月 31 日，研究人员发现 Moltbook——这个与 OpenClaw 生态系统紧密相连的“AI 代理社交媒体”平台——将其生产数据库完全暴露在外。

数字如下：

  • 总共暴露 149 万条记录
  • 公开可访问 32,000 多个 AI 代理 API 密钥——包括明文 OpenAI 密钥
  • 泄露 35,000 个电子邮件地址
  • Andrej Karpathy 的机器人 API 密钥 也在暴露的数据库中
  • 根本原因：Supabase 配置错误，没有行级安全策略
  • 由 Dvuln 的 Jameson O'Reilly 发现；Wiz 独立确认

Karpathy 的反应是：“这是一场灾难，我也绝对不建议人们在你的电脑上运行这些东西。”

这句话出自 AI 基础设施领域最受尊敬的声音之口。不是一个有议程的安全研究员。不是一个竞争对手。而是构建了特斯拉 Autopilot AI 并联合创立 OpenAI 的人，他告诉人们不要在他们的机器上运行这个。

根本原因很有启发性：Moltbook 几乎完全是“氛围编码”的——在大量 AI 辅助下构建，几乎没有手动安全审查。Supabase 后端没有行级安全策略。创始人公开表示，代码库基本上是在没有手动编写代码的情况下构建的。这就是当上市速度优先于安全基础时会发生的事情。

如果构建代理基础设施的平台连自己的数据库都保护不好，我们怎么能对在这些平台上运行的未经审查的社区贡献有信心呢？

📸 [数据可视化：显示 Moltbook 泄露数据的统计卡——“149 万条记录暴露”、“3.2 万+ API 密钥”、“3.5 万封电子邮件”、“包含 Karpathy 的机器人 API 密钥”——下方有来源标识。] Moltbook 泄露事件的数据。

ClawdHub 市场问题

当我手动审计单个 ClawdHub 技能并发现隐藏的提示注入时，Koi Security 的安全研究人员正在进行大规模的自动化分析。

初步发现：341 个恶意技能，总共 2,857 个。这占整个市场的 12%。

更新后的发现：800 多个恶意技能，大约占市场的 20%。

一项独立审计发现，41.7% 的 ClawdHub 技能存在严重漏洞——并非全部是故意恶意的，但可被利用。

在这些技能中发现的攻击载荷包括：

  • AMOS 恶意软件（Atomic Stealer）——一种 macOS 凭证窃取工具
  • 反向 shell——让攻击者远程访问用户的机器
  • 凭证窃取——静默地将 API 密钥和令牌发送到外部服务器
  • 隐藏的提示注入——在用户不知情的情况下修改代理行为

这不是理论上的风险。这是一次被命名为 “ClawHavoc” 的协调供应链攻击，从 2026 年 1 月 27 日开始的一周内上传了 230 多个恶意技能。

请花点时间消化一下这个数字。市场上五分之一的技能是恶意的。如果你安装了十个 ClawdHub 技能，从统计学上讲，其中两个正在做你没有要求的事情。而且，由于在大多数配置中技能之间没有沙箱隔离，一个恶意技能可以修改你合法技能的行为。

这是代理时代的 curl mystery-url.com | bash。只不过，你不是在运行一个未知的 shell 脚本，而是向一个能够访问你的账户、文件和通信渠道的代理注入未知的提示工程。

📸 [时间线图表：“1 月 27 日——上传 230+ 个恶意技能” -> “1 月 30 日——披露 CVE-2026-25253” -> “1 月 31 日——发现 Moltbook 泄露” -> “2026 年 2 月——确认 800+ 个恶意技能”。一周内发生三起重大安全事件。] 一周内发生三起重大安全事件。这就是代理生态系统中的风险节奏。

CVE-2026-25253：一键完全入侵

2026 年 1 月 30 日，OpenClaw 本身披露了一个高危漏洞——不是社区技能，不是第三方集成，而是平台的核心代码。

  • CVE-2026-25253 —— CVSS 评分：8.8（高）
  • Control UI 从查询字符串中接受 gatewayUrl 参数 而不进行验证
  • 它会自动通过 WebSocket 将用户的身份验证令牌传输到提供的任何 URL
  • 点击一个精心制作的链接或访问恶意网站会将你的身份验证令牌发送到攻击者的服务器
  • 这允许通过受害者的本地网关进行一键远程代码执行
  • 在公共互联网上发现 42,665 个暴露的实例，5,194 个已验证存在漏洞
  • 93.4% 存在身份验证绕过条件
  • 在版本 2026.1.29 中修复

再读一遍。42,665 个实例暴露在互联网上。5,194 个已验证存在漏洞。93.4% 存在身份验证绕过。这是一个大多数公开可访问的部署都有一条通往远程代码执行的一键路径的平台。

这个漏洞很简单：Control UI 不加验证地信任用户提供的 URL。这是一个基本的输入净化失败——这种问题在首次安全审计中就会被发现。它没有被发现是因为，就像这个生态系统的许多部分一样，安全审查是在部署之后进行的，而不是之前。

CrowdStrike 称 OpenClaw 是一个“能够接受对手指令的强大 AI 后门代理”，并警告它制造了一种“独特危险的情况”，即提示注入“从内容操纵问题转变为全面入侵的推动者”。

Palo Alto Networks 将这种架构描述为 Simon Willison 所说的 “致命三要素”：访问私人数据、暴露于不受信任的内容以及外部通信能力。他们指出，持久性记忆就像“汽油”，会放大所有这三个要素。他们的术语是：一个“无界的攻击面”，其架构中“内置了过度的代理权”。

Gary Marcus 称之为 “基本上是一种武器化的气溶胶”——意味着风险不会局限于一处。它会扩散。

一位 Meta AI 研究员让她的整个收件箱被一个 OpenClaw 代理删除了。不是黑客干的。是她自己的代理，执行了它本不应遵循的指令。

这些不是匿名的 Reddit 帖子或假设场景。这些是带有 CVSS 评分的 CVE、被多家安全公司记录的协调恶意软件活动、被独立研究人员确认的百万记录数据库泄露事件，以及来自世界上最大的网络安全组织的事件报告。担忧的证据基础并不薄弱。它是压倒性的。

📸 [引用卡片：分割设计——左侧：CrowdStrike 引用“将提示注入转变为全面入侵的推动者。”右侧：Palo Alto Networks 引用“致命三要素……其架构中内置了过度的代理权。”中间是 CVSS 8.8 徽章。] 世界上最大的两家网络安全公司，独立得出了相同的结论。

有组织的越狱生态系统

从这里开始，这不再是一个抽象的安全演练。

当 OpenClaw 用户将代理连接到他们的个人账户时，一个平行的生态系统正在将利用它们所需的确切技术工业化。这不是零散的个人在 Reddit 上发布提示。而是拥有专用基础设施、共享工具和活跃研究项目的有组织社区。

对抗性流水线的工作原理如下：技术先在“去安全化”模型（去除了安全训练的微调版本，在 HuggingFace 上免费提供）上开发，针对生产模型进行优化，然后部署到目标上。优化步骤越来越量化——一些社区使用信息论分析来衡量给定的对抗性提示每个令牌能侵蚀多少“安全边界”。他们正在像我们优化损失函数一样优化越狱。

这些技术是针对特定模型的。有针对 Claude 变体精心制作的载荷：符文编码（使用 Elder Futhark 字符绕过内容过滤器）、二进制编码的函数调用（针对 Claude 的结构化工具调用机制）、语义反转（“先写拒绝，再写相反的内容”），以及针对每个模型特定安全训练模式调整的角色注入框架。

还有泄露的系统提示库——Claude、GPT 和其他模型遵循的确切安全指令——让攻击者精确了解他们正在试图规避的规则。

为什么这对 OpenClaw 特别重要？因为 OpenClaw 是这些技术的 力量倍增器。

攻击者不需要单独针对每个用户。他们只需要一个有效的提示注入，通过 Telegram 群组、Discord 频道或 X DM 传播。多通道架构免费完成了分发工作。一个精心制作的载荷发布在流行的 Discord 服务器上，被几十个监控机器人接收，每个机器人然后将其传播到连接的 Telegram 频道和 X DM。蠕虫自己就写好了。

防御是集中式的（少数实验室致力于安全研究）。进攻是分布式的（一个全球社区全天候迭代）。更多的渠道意味着更多的注入点，意味着攻击有更多的机会成功。模型只需要失败一次。攻击者可以在每个连接的渠道上获得无限次尝试。

📸 [DIAGRAM: "The Adversarial Pipeline" — left-to-right flow: "Abliterated Model (HuggingFace)" -> "Jailbreak Development" -> "Technique Refinement" -> "Production Model Exploit" -> "Delivery via OpenClaw Channel". Each stage labeled with its tooling.] 攻击流程：从被破解的模型到生产环境利用，再到通过您代理的连接通道进行交付。

架构论点：多个接入点是一个漏洞

现在让我将分析与我认为正确的答案联系起来。

为什么 OpenClaw 的模式有道理（从商业角度看）

作为一个免费增值的开源项目，OpenClaw 提供一个以仪表盘为中心的部署解决方案是完全合理的。图形用户界面降低了入门门槛。多渠道集成创造了令人印象深刻的演示效果。市场创建了社区飞轮效应。从增长和采用的角度来看，这个架构设计得很好。

从安全角度来看，它是反向设计的。每一个新的集成都是另一扇门。每一个未经审查的市场技能都是另一个潜在的载荷。每一个通道连接都是另一个注入面。商业模式激励着最大化攻击面。

这就是矛盾所在。这个矛盾可以解决——但只能通过将安全作为设计约束，而不是在增长指标看起来不错之后再事后补上。

Palo Alto Networks 将 OpenClaw 映射到了 OWASP 自主 AI 代理十大风险清单 的每一个类别——这是一个由 100 多名安全研究人员专门为自主 AI 代理开发的框架。当安全供应商将您的产品映射到行业标准框架中的每一项风险时，那不是在散布恐惧、不确定性和怀疑。那是一个信号。

OWASP 引入了一个称为 最小自主权 的原则：只授予代理执行安全、有界任务所需的最小自主权。OpenClaw 的架构恰恰相反——它默认连接到尽可能多的通道和工具，从而最大化自主权，而沙盒化则是一个事后才考虑的附加选项。

还有 Palo Alto 确定的第四个放大因素：内存污染问题。恶意输入可以分散在不同时间，写入代理内存文件（SOUL.md, MEMORY.md），然后组装成可执行的指令。OpenClaw 为连续性设计的持久内存系统——变成了攻击的持久化机制。提示注入不必一次成功。在多次独立交互中植入的片段，稍后会组合成一个在重启后依然有效的功能载荷。

对于技术人员：一个接入点，沙盒化，无头运行

对于技术用户的替代方案是一个包含 MiniClaw 的仓库——我说的 MiniClaw 是一种理念，而不是一个产品——它拥有 一个接入点，经过沙盒化和容器化，以无头模式运行。

原则OpenClawMiniClaw
接入点多个（Telegram, X, Discord, 电子邮件, 浏览器）一个（SSH）
执行环境宿主机，广泛访问权限容器化，受限权限
界面仪表盘 + 图形界面无头终端（tmux）
技能ClawdHub（未经审查的社区市场）手动审核，仅限本地
网络暴露多个端口，多个服务仅 SSH（Tailscale 网络）
爆炸半径代理可以访问的一切沙盒化到项目目录
安全态势隐式（您不知道您暴露了什么）显式（您选择了每一个权限）

📸 [COMPARISON TABLE AS INFOGRAPHIC: The MiniClaw vs OpenClaw table above rendered as a shareable dark-background graphic with green checkmarks for MiniClaw and red indicators for OpenClaw risks.] MiniClaw 理念：90% 的生产力，5% 的攻击面。

我的实际设置：

Mac Mini (headless, 24/7)
├── SSH access only (ed25519 key auth, no passwords)
├── Tailscale mesh (no exposed ports to public internet)
├── tmux session (persistent, survives disconnects)
├── Claude Code with ECC configuration
│   ├── Sanitized skills (every skill manually reviewed)
│   ├── Hooks for quality gates (not for external channel access)
│   └── Agents with scoped permissions (read-only by default)
└── No multi-channel integrations
    └── No Telegram, no Discord, no X, no email automation

在演示中不那么令人印象深刻吗？是的。我能向人们展示我的代理从沙发上回复 Telegram 消息吗？不能。

有人能通过 Discord 给我发私信来入侵我的开发环境吗？同样不能。

技能应该被净化。新增内容应该被审核。

打包技能——随系统提供的那些——应该被适当净化。当用户添加第三方技能时，应该清晰地概述风险，并且审核他们安装的内容应该是用户明确、知情的责任。而不是埋在一个带有一键安装按钮的市场里。

这是 npm 生态系统通过 event-stream、ua-parser-js 和 colors.js 艰难学到的教训。通过包管理器进行的供应链攻击并不是一种新的漏洞类别。我们知道如何缓解它们：自动扫描、签名验证、对流行包进行人工审查、透明的依赖树以及锁定版本的能力。ClawdHub 没有实现任何一项。

一个负责任的技能生态系统与 ClawdHub 之间的区别，就如同 Chrome 网上应用店（不完美，但经过审核）与一个可疑 FTP 服务器上未签名的 .exe 文件文件夹之间的区别。正确执行此操作的技术是存在的。设计选择是为了增长速度而跳过了它。

OpenClaw 所做的一切都可以在没有攻击面的情况下完成

定时任务可以简单到访问 cron-job.org。浏览器自动化可以通过 Playwright 在适当的沙盒环境中进行。文件管理可以通过终端完成。内容交叉发布可以通过 CLI 工具和 API 实现。收件箱分类可以通过电子邮件规则和脚本完成。

OpenClaw 提供的所有功能都可以用技能和工具来复制——我在 [速成指南]和 [详细指南]中介绍的那些。无需庞大的攻击面。无需未经审查的市场。无需为攻击者打开五扇额外的大门。

多个接入点是一个漏洞，而不是一个功能。

📸 [SPLIT IMAGE: Left — "Locked Door" showing a single SSH terminal with key-based auth. Right — "Open House" showing the multi-channel OpenClaw dashboard with 7+ connected services. Visual contrast between minimal and maximal attack surfaces.] 左图：一个接入点，一把锁。右图：七扇门，每扇都没锁。

有时无聊反而更好。

📸 [SCREENSHOT: Author's actual terminal — tmux session with Claude Code running on Mac Mini over SSH. Clean, minimal, no dashboard. Annotations: "SSH only", "No exposed ports", "Scoped permissions".] 我的实际设置。没有多渠道仪表盘。只有一个终端、SSH 和 Claude Code。

便利的代价

我想明确地指出这个权衡，因为我认为人们在不知不觉中做出了选择。

当您将 Telegram 连接到 OpenClaw 代理时，您是在用安全换取便利。这是一个真实的权衡，在某些情况下可能值得。但您应该在充分了解放弃了什么的情况下，有意识地做出这个权衡。

目前，大多数 OpenClaw 用户是在不知情的情况下做出这个权衡。他们看到了功能（代理回复我的 Telegram 消息！），却没有看到风险（代理可能被任何包含提示注入的 Telegram 消息入侵）。便利是可见且即时的。风险在显现之前是隐形的。

这与驱动早期互联网的模式相同：人们将一切都连接到一切，因为它很酷且有用，然后花了接下来的二十年才明白为什么这是个坏主意。我们不必在代理基础设施上重复这个循环。但是，如果在设计优先级上便利性继续超过安全性，我们就会重蹈覆辙。

未来：谁会赢得这场游戏

无论怎样，递归代理终将到来。我完全同意这个论点——管理我们数字工作流的自主代理是行业发展趋势中的一个步骤。问题不在于这是否会发生。问题在于谁会构建出那个不会导致大规模用户被入侵的版本。

我的预测是：谁能做出面向消费者和企业的、部署的、以仪表盘/前端为中心的、经过净化和沙盒化的 OpenClaw 式解决方案的最佳版本，谁就能获胜。

这意味着：

1. 托管基础设施。 用户不管理服务器。提供商负责安全补丁、监控和事件响应。入侵被限制在提供商的基础设施内，而不是用户的个人机器。

2. 沙盒化执行。 代理无法访问主机系统。每个集成都在其自己的容器中运行，拥有明确、可撤销的权限。添加 Telegram 访问需要知情同意，并明确说明代理可以通过该渠道做什么和不能做什么。

3. 经过审核的技能市场。 每一个社区贡献都要经过自动安全扫描和人工审查。隐藏的提示注入在到达用户之前就会被发现。想想 Chrome 网上应用店的审核，而不是 2018 年左右的 npm。

4. 默认最小权限。 代理以零访问权限启动，并选择加入每项能力。最小权限原则，应用于代理架构。

5. 透明的审计日志。 用户可以准确查看他们的代理做了什么、收到了什么指令以及访问了什么数据。不是埋在日志文件里——而是在一个清晰、可搜索的界面中。

6. 事件响应。 当（不是如果）发生安全问题时，提供商有一个处理流程：检测、遏制、通知、补救。而不是“去 Discord 查看更新”。

OpenClaw 可以演变成这样。基础已经存在。社区积极参与。团队正在前沿领域构建。但这需要从“最大化灵活性和集成”到“默认安全”的根本性转变。这些是不同的设计理念，而目前，OpenClaw 坚定地处于第一个阵营。

对于技术用户来说，在此期间：MiniClaw。一个接入点。沙盒化。无头运行。无聊。安全。

对于非技术用户来说：等待托管的、沙盒化的版本。它们即将到来——市场需求太明显了，它们不可能不来。在此期间，不要在您的个人机器上运行可以访问您账户的自主代理。便利性真的不值得冒这个险。或者如果您一定要这么做，请了解您接受的是什么。

我想诚实地谈谈这里的反方论点，因为它并非微不足道。对于确实需要 AI 自动化的非技术用户来说，我描述的替代方案——无头服务器、SSH、tmux——是无法企及的。告诉一位营销经理“直接 SSH 到 Mac Mini”不是一个解决方案。这是一种推诿。对于非技术用户的正确答案不是“不要使用递归代理”。而是“在沙盒化、托管、专业管理的环境中使用它们，那里有专人负责处理安全问题。”您支付订阅费。作为回报，您获得安心。这种模式正在到来。在它到来之前，自托管多通道代理的风险计算严重倾向于“不值得”。

📸 [DIAGRAM: "The Winning Architecture" — a layered stack showing: Hosted Infrastructure (bottom) -> Sandboxed Containers (middle) -> Audited Skills + Minimal Permissions (upper) -> Clean Dashboard (top). Each layer labeled with its security property. Contrast with OpenClaw's flat architecture where everything runs on the user's machine.] 获胜的递归代理架构的样子。

您现在应该做什么

如果您目前正在运行 OpenClaw 或正在考虑使用它，以下是实用的建议。

如果您今天正在运行 OpenClaw：

  1. 审核您安装的每一个 ClawdHub 技能。 阅读完整的源代码，而不仅仅是可见的描述。查找任务定义下方的隐藏指令。如果您无法阅读源代码并理解其作用，请将其移除。

  2. 审查你的频道权限。 对于每个已连接的频道（Telegram、Discord、X、电子邮件），请自问：“如果这个频道被攻陷，攻击者能通过我的智能体访问到什么？” 如果答案是“我连接的所有其他东西”，那么你就存在一个爆炸半径问题。

  3. 隔离你的智能体执行环境。 如果你的智能体运行在与你的个人账户、iMessage、电子邮件客户端以及保存了密码的浏览器同一台机器上——那就是可能的最大爆炸半径。考虑在容器或专用机器上运行它。

  4. 停用你非日常必需的频道。 你启用的每一个你日常不使用的集成，都是你毫无益处地承担的攻击面。精简它。

  5. 更新到最新版本。 CVE-2026-25253 已在 2026.1.29 版本中修复。如果你运行的是旧版本，你就存在一个已知的一键远程代码执行漏洞。立即更新。

如果你正在考虑使用 OpenClaw：

诚实地问问自己：你是需要多频道编排，还是需要一个能执行任务的 AI 智能体？这是两件不同的事情。智能体功能可以通过 Claude Code、Cursor、Codex 和其他工具链获得——而无需承担多频道攻击面。

如果你确定多频道编排对你的工作流程确实必要，那么请睁大眼睛进入。了解你正在连接什么。了解频道被攻陷意味着什么。安装前阅读每一项技能。在专用机器上运行它，而不是你的个人笔记本电脑。

如果你正在这个领域进行构建：

最大的机会不是更多的功能或更多的集成。而是构建一个默认安全的版本。那个能为消费者和企业提供托管式、沙盒化、经过审计的递归智能体的团队将赢得这个市场。目前，这样的产品尚不存在。

路线图很清晰：托管基础设施让用户无需管理服务器，沙盒化执行以控制损害范围，经过审计的技能市场让供应链攻击在到达用户前就被发现，以及透明的日志记录让每个人都能看到他们的智能体在做什么。这些都可以用已知技术解决。问题在于是否有人将其优先级置于增长速度之上。

📸 [检查清单图示：将 5 点“如果你正在运行 OpenClaw”列表渲染为带有复选框的可视化检查清单，专为分享设计。] 当前 OpenClaw 用户的最低安全清单。

结语

需要明确的是，本文并非对 OpenClaw 的攻击。

该团队正在构建一项雄心勃勃的东西。社区充满热情。关于递归智能体管理我们数字生活的愿景，作为一个长期预测很可能是正确的。我花了一周时间使用它，因为我真心希望它能成功。

但其安全模型尚未准备好应对它正在获得的采用度。而涌入的人们——尤其是那些最兴奋的非技术用户——并不知道他们所不知道的风险。

当 Andrej Karpathy 称某物为“垃圾场火灾”并明确建议不要在你的计算机上运行它时。当 CrowdStrike 称其为“全面违规助推器”时。当 Palo Alto Networks 识别出其架构中固有的“致命三重奏”时。当技能市场中 20% 的内容是主动恶意时。当一个单一的 CVE 就暴露了 42,665 个实例，其中 93.4% 存在认证绕过条件时。

在某个时刻，你必须认真对待这些证据。

我构建 AgentShield 的部分原因，就是我在那一周使用 OpenClaw 期间的发现。如果你想扫描你自己的智能体设置，查找我在这里描述的那类漏洞——技能中的隐藏提示注入、过于宽泛的权限、未沙盒化的执行环境——AgentShield 可以帮助进行此类评估。但更重要的不是任何特定的工具。

更重要的是：安全必须是智能体基础设施中的一等约束条件，而不是事后考虑。

行业正在为自主 AI 构建底层管道。这些将是管理人们电子邮件、财务、通信和业务运营的系统。如果我们在基础层搞错了安全性，我们将为此付出数十年的代价。每一个被攻陷的智能体、每一次泄露的凭证、每一个被删除的收件箱——这些不仅仅是孤立事件。它们是在侵蚀整个 AI 智能体生态系统生存所需的信任。

在这个领域进行构建的人们有责任正确地处理这个问题。不是最终，不是在下个版本，而是现在。

我对未来的方向持乐观态度。对安全、自主智能体的需求是显而易见的。正确构建它们的技术已经存在。有人将会把这些部分——托管基础设施、沙盒化执行、经过审计的技能、透明的日志记录——整合起来，构建出适合所有人的版本。那才是我想要使用的产品。那才是我认为会胜出的产品。

在此之前：阅读源代码。审计你的技能。最小化你的攻击面。当有人告诉你，将七个频道连接到一个拥有 root 访问权限的自主智能体是一项功能时，问问他们是谁在守护着大门。

设计安全，而非侥幸安全。

你怎么看？我是过于谨慎了，还是社区行动太快了？ 我真心想听听反对意见。在 X 上回复或私信我。

参考资料

Affaan Mustafa (@affaanmustafa) 构建 AI 编程工具并撰写关于 AI 基础设施安全的文章。他的 everything-claude-code 仓库在 GitHub 上拥有 5 万多个星标。他创建了 AgentShield 并凭借构建 zenith.chat 赢得了 Anthropic x Forum Ventures 黑客松。

原文链接: github.com/affaan-m/ev…

avatar
文章
阅读
粉丝