恶意 Skills：AI代理技能市场的产品安全边界与研发应对

本文采用的是基于所列资料的工作性理解，不是行业统一定义。本文所说的“恶意 Skills”，在这些资料的语境中可以先理解为：以插件、技能包、代理扩展或自动化脚本的形式进入 AI 代理体系，并在安装、调用或更新过程中执行未被用户充分理解、却可能带来安全后果的行为。它未必只等于“带病毒的插件”，更适合被看作一个同时涉及供应链、产品权限、审核流程和用户信任界面的问题。

为什么“恶意 Skills”值得单独讨论

从已给资料看，OpenClaw 相关事件不只是在描述单个恶意样本，而是呈现出一个围绕技能市场分发、平台缺陷与令牌风险交织出现的案例[1]。

安天披露的时间线显示：

• 2026年1月27日，首个恶意 Skill polymarket-traiding-bot v1.0.0 发布[1]；
• 2026年1月28日至29日，又出现 reddit-trends、base-agent、bybit-agent 等恶意 Skill[1]；
• 2026年1月30日，OpenClaw 发布补丁，强制移除无身份验证模式，并修复一个允许远程代码执行的 WebSocket 漏洞[1]；
• 2026年1月31日，来源记录攻击者开始集中发布更多恶意 Skills[1]；
• 2026年2月1日，Koi Security 和 OpenSourceMalware 发布报告，披露 ClawHub 上存在恶意技能，并将此次活动命名为“ClawHavoc”；同日，社区还制作了一个基于 AI 自动检查 Skills 安全性的工具 Clawdex[1]；
• 2026年2月2日，Wiz 披露与 Auth Token 泄露有关的问题，来源称攻击者可利用这些 Token 接管 AI 代理[1]。

如果只把这类事件理解为“有人上传了木马”，可能会低估问题。在这些资料的语境中，更贴近产品研发现实的理解是：技能市场可能为危险代码提供了更容易被发现、安装和传播的入口，而代理产品本身的权限、认证和信任设计，又可能放大其后果。

本文的工作性理解：恶意 Skills 可以从四层风险来观察

为了方便产品和研发团队判断，我们的建议是把“恶意 Skills”拆成四层，而不是只看样本是否恶意。这里的四层是分析框架，不是行业标准。

1. 内容层：Skill 本体是否包含恶意逻辑

这是最直观的一层，即 Skill 中本就带有窃取、远程下载、执行命令或外传数据等逻辑。安天报告提到“将窃取的数据发送至 Webhook”[1]，这至少说明在该案例里，风险已经不只是“行为异常”，而是涉及明确的数据外传。

对研发来说，这一层通常对应：

• 安装包内容审查；
• 依赖项审查；
• 静态与动态行为检测；
• 版本差异比对。

2. 分发层：市场上架与发现机制是否放大风险

从时间线看，恶意 Skills 在数日内持续出现，并在后续进入更集中的发布阶段[1]。这提示问题可能不仅在代码，还在上架门槛、账号治理、搜索排序、推荐曝光和下架处置速度。

如果一个技能市场允许新账号快速、批量上架，且用户能够低成本搜索并安装，那么恶意样本就更可能借助产品机制扩散。这里更稳妥的说法是：市场本身也可能成为攻击面的一部分。

3. 权限层：Skill 能拿到哪些系统能力

资料显示，相关事件中既提到 InfoStealer 感染，也提到可接管 AI 代理的 Token 风险[1]。这说明 Skill 的危险程度，不仅由其代码决定，也与产品向其开放了哪些能力有关。

可以考虑把常见能力分成三类：

• 信息读取能力：读本地文件、对话历史、环境变量、浏览器会话等；
• 执行能力：命令执行、脚本运行、下载并启动额外载荷；
• 代理控制能力：使用令牌持续调用代理、代表用户发起操作、访问连接器或外部服务。

同样一个 Skill，在“只能读公开网页”和“可执行本地命令”两种环境下，风险判断通常会明显不同。

4. 信任层：用户为什么会装它

恶意 Skills 往往不一定依赖复杂漏洞传播，也可能依赖名称伪装、功能借势和用户对市场的默认信任。从已披露的名称看，攻击者使用了交易、热点、平台工具等看似合理的功能命名[1]。这类命名可能让用户误以为它只是一个普通效率插件。

因此，恶意 Skills 的产品问题还包括：

• 展示页是否充分揭示开发者身份；
• 是否显示权限摘要；
• 是否展示安全审查状态；
• 更新时是否提醒新增权限；
• 用户是否能看懂“安装后将获得什么能力”。

从 OpenClaw 事件出发，可以怎样理解这类风险链路

以下内容更适合作为基于案例整理出的观察框架，而不是对所有技能市场都成立的普遍规律。

第一段：低门槛进入市场

首个恶意 Skill 在1月27日出现，随后几天持续新增，1月31日进入集中发布阶段[1]。这至少说明，在该案例中，攻击者在确认市场可被利用后，可能会继续测试命名方式、分发路径和审核空档，再扩大投放。

第二段：借产品缺陷放大后果

1月30日 OpenClaw 通过补丁强制移除无身份验证模式，并修复 WebSocket RCE 漏洞[1]。这提示一个研发判断：技能生态风险和宿主平台漏洞未必彼此独立。

在这些资料的语境中，可以这样理解：如果恶意 Skill 运行在认证薄弱、调用边界不清或远程执行可达的环境中，其危害可能被进一步放大。

第三段：利用账户或令牌维持后续控制

2月2日的披露提到，因未配置 RLS，Auth Token 和真实用户邮箱发生泄露，来源称攻击者可利用这些 Token 接管 AI 代理[1]。这说明即使恶意 Skill 的初始载荷并不复杂，只要后续能够获取令牌或凭据，也可能从“单次安装风险”升级为“后续持续风险”。

第四段：在社区修复前持续变种

资料还提到，恶意活动仍通过变种持续进行[1]。对产品团队而言，这意味着处置不能只理解为“删掉几个已知样本”就结束。只要上架、命名、审核和权限模型没有明显改进，攻击者就可能换壳重来。

对 AI 产品团队的可执行判断：不要只做“内容审核”

我们的建议是：把恶意 Skills 当成一个“上架前—安装时—运行中—更新后”的全链路治理问题，而不是单点审核问题。

一、上架前：把“可批量投毒”变得更难

可以考虑的产品与研发措施包括：

1. 开发者身份与发布约束

如果同一批攻击者能够在短时间发布大量 Skills[1]，说明发布约束在该案例中可能不足。可以考虑：

• 新开发者冷启动期限制上架数量；
• 首次发布需完成更高等级身份校验；
• 对相似描述、相似代码结构、相似依赖树进行聚类审查；
• 对异常高频发布行为自动进入人工复核。

2. 风险导向的自动审查

Clawdex 被描述为一个基于 AI 自动检查 Skills 安全性的工具[1]。这至少提供了一个方向：AI 可以作为预审助手，但不宜被当成最终判定者。

更稳妥的做法可以是将其用于：

• 提取权限声明与实际代码行为的不一致；
• 标出网络外联、Webhook、下载执行、系统命令调用等高风险片段；
• 生成给审核人员看的风险摘要。

二、安装时：把用户真正会关心的信息讲清楚

很多风险不是用户“不同意”，而是用户并不清楚自己同意了什么。因此安装页设计非常关键。

1. 不展示技术术语堆砌，展示能力摘要

相比只写“需要系统访问权限”，更可执行的方式是直接告诉用户：

• 可读取哪些数据；
• 可调用哪些外部服务；
• 是否能执行本地命令；
• 是否会持续运行；
• 是否在更新后自动获得新增权限。

2. 权限变更最好再次确认

资料中出现了多个版本化的恶意 Skill 名称[1]。这提示产品在设计上可以把版本升级视为新的信任决策，而不是默认继承旧授权，尤其是在新增高风险能力时。

三、运行中：默认最小权限，而不是默认全能

这是最影响真实风险的一步。

1. Skill 沙箱化

可以考虑把 Skill 运行能力分层：

• 纯信息型：只允许读取公开网络内容；
• 工具型：允许调用受控 API，但不能访问本地系统；
• 高权限型：需要额外审批，才可访问文件系统、环境变量或命令执行。

2. 凭据隔离

2月2日披露中，Auth Token 泄露可导致代理被接管[1]。这类问题提示，不宜让 Skill 直接长期持有高价值令牌。可以考虑：

• 短时令牌；
• 单 Skill 独立令牌；
• 细粒度作用域；
• 用户可见的令牌撤销界面；
• 异常调用自动吊销。

3. 出网与外传监控

既然报告提到数据被发送至 Webhook[1]，那么对 Skill 的网络行为进行出网限制和告警，就是值得考虑的设计方向。尤其是：

• 首次访问陌生域名；
• 向即时 Webhook 地址发送数据；
• 大量打包上传本地文本或配置内容；
• 在用户未触发任务时持续联网。

四、更新后：建立可追溯的审计链路

这里需要特别说明：以下内容属于借鉴性产品启发，并不是 OpenClaw 事件本身已经证明的事实结论。

给定资料中的 GitHub 项目 academic-research-skills 提到“每笔引用都带三层 anchor”，并在后续版本增加一道审计 pass，用于判断引用来源是否真的支撑 claim，不满足时会被 hard gate 拦下[3]。该项目讨论的是学术研究技能中的引用一致性，而不是恶意代码检测；但在产品方法上，它提供了一个可借鉴思路：

对 Skills 的审核，不一定只做‘过不过’，也可以考虑做‘每个关键声明能否被追溯验证’。

把这个思路迁移到技能市场，我们的建议是可以考虑建立：

• 权限声明锚点：声明的每项能力都能映射到代码位置；
• 依赖锚点：高风险依赖来自何处、何时加入；
• 行为锚点：网络请求、文件访问、命令执行的触发路径；
• 更新差异审计：新版本新增了哪些能力与外联目标。

这样做的价值，不在于保证绝对安全，而在于尽量降低“说一套、做一套”的空间。

我们的建议：把“恶意 Skills”当成产品体系问题，而不是只交给安全团队

如果团队正在做 AI 应用、代理平台、插件市场或小程序式工具集成，本文建议从以下顺序推进：

1. 先定义风险分级

不要把所有 Skills 一视同仁。至少区分：

• 只读型；
• 外联型；
• 执行型；
• 代理控制型。

不同级别对应不同上架门槛、默认权限和复核机制。

2. 再定义信任升级路径

不是“开发者注册后即可做所有事”，而是：

• 新开发者只能发低权限 Skill；
• 通过一段时间的审查记录后，才能申请更高权限类别；
• 高权限 Skill 需要更强身份校验与更细审计。

3. 最后补齐处置闭环

资料显示，社区后续手动删除了相关 Skills，并修复了多个安全问题[1]。这提示处置闭环至少可以覆盖：

• 快速冻结上架账号；
• 批量下架关联版本；
• 通知已安装用户；
• 强制撤销相关令牌；
• 提供安装影响自查工具；
• 对同类名称、同类依赖、同类行为进行回扫。

一个实用判断：什么样的 Skills 市场更容易出问题

本文的工作性理解是，如果一个平台同时具备以下特征，就应提高警惕：

• 发布门槛低；
• 用户安装链路短；
• 权限提示弱；
• Skill 可接触本地环境或高价值令牌；
• 更新默认继承旧授权；
• 缺少持续审计和快速下架能力。

这不是对所有平台风险结果的确定性判断，而更像一个排查清单。反过来说，真正降低风险的，不只是“更强的杀毒”，也包括让恶意 Skill 在每一个关键节点都更难得手。

结语

基于现有资料，恶意 Skills 更适合被理解为一种AI 代理生态中的复合型供应链与产品权限风险，而不只是单纯的插件木马问题。OpenClaw 相关披露显示，在该案例中，技能市场分发、认证机制、宿主漏洞和令牌管理问题是相互交织出现的[1]。

对做 AI 应用、网站、小程序和垂直数字化产品的团队来说，更有价值的动作不是只问“要不要上技能市场”，而是先问：我们的技能分发、权限模型、审计链路和应急下架能力，是否足以承受恶意 Skills 的出现。