恶意 AI Skills 扩大企业安全风险

Google News 揭示了企业 AI 面临的一项严峻冲突：智能体通过 Skills 获得实用能力，而攻击者也在利用同样的扩展机制。安全厂商 ESET 的最新研究在近 90 万个已分析的 Skills 中发现了超过 3,000 个恶意 Skills。这一发现使原本便利的智能体功能演变为软件供应链问题。

这一担忧不限于某个单一市场或恶意软件活动。AI Skills 可以结合指令、脚本、外部文档以及对敏感系统的访问权限。因此，遭入侵的 Skill 既可能影响智能体的决策，也可能影响其所控制的工具。

企业如今必须在自主性与控制力之间权衡。开放生态系统加速了实验与创新，但其信任信号仍弱于成熟软件包所具备的保障。研究人员已经表明，代码库热度、市场审核和静态扫描都可能同时失效。

Google News 揭示的恶意 AI Skills 情况

重要的变化不在于恶意扩展首次出现，而在于其规模。

ESET 的 2026 年上半年研究涵盖了 2025 年 12 月至 2026 年 5 月期间观察到的威胁活动。该公司表示，其分析了近 90 万个 AI Skills，并发现数以万计的可疑样本。其中超过 3,000 个被归类为恶意。

AI Skill 是一种可复用的软件包，用于告诉智能体如何完成任务、使用工具并处理相关信息。有些 Skills 几乎只包含指令；另一些则将智能体连接到脚本、服务、文件、命令行工具或不断变化的网络资源。

在研究期间，分析对象数量迅速增长。根据基于该研究结果的报道，ESET 在 3 月扫描了约 60,000 个独特 Skills，到 5 月时已接近 90 万个。可疑发现数量在此期间从约 10,000 个增加到超过 25,000 个。

恶意发现数量则从约 600 个上升至超过 3,000 个。这些数字并不能证明每个代码库都有相同的感染率，但确实表明安全团队需要评估的第三方智能体行为正不断增加。

ESET 公开的威胁报告摘要将 Skills 描述为智能体使用的小型功能组件。该公司在其检查的代码库中发现了恶意和可疑实例。

研究人员观察到的能力包括命令执行、代码注入、文件访问、凭据加载、混淆以及外部下载。这些功能本身并不必然恶意；当 Skill 的声明用途无法证明其合理性时，它们才会变得危险。

一个合法的开发者 Skill 可能需要 shell 访问权限来构建应用程序。文档助手可能需要获得读取指定文件的许可。安全问题在于，这些权限是否始终受到限制、可见，并且与经批准的业务用途相关联。

传统恶意软件通常以可执行文件、附件或遭入侵的软件包形式进入环境。恶意 AI Skills 增加了另一种投递方式。有害指令可能隐藏在智能体会视为操作指南的普通语言中。

这种设计使检测更加复杂。一个 Skill 在审查时可能并不包含可识别的恶意二进制文件；相反，它可能引导智能体访问外部页面、在之后获取新指令，或滥用已存在的合法工具。

这则 Google News 条目之所以重要，是因为它将这些分散的发现串联成一则企业风险故事。威胁已不再局限于实验性的个人智能体。Skills 正在进入工程师、营销人员、分析师、设计师和销售团队使用的工作流。

这些用户安装扩展时，未必会将其视为一次软件部署。一个简短的文本文件看起来比应用安装程序危险性低得多。然而，读取该文件的智能体可能已经拥有电子邮件、云存储、源代码或内部知识的访问权限。

表象与权限之间的落差构成了核心矛盾。Skills 往往看起来像文档，但实际上可以像可执行的工作流逻辑一样运作。企业不能将其作为无害提示词来管理。

为什么 AI 智能体安全如今类似于供应链防御

当智能体依赖某项 Skill 在公司系统内执行操作时，该 Skill 就成为企业依赖项。

软件供应链安全会追踪组件的来源、维护者、已部署版本以及更新如何进入生产环境。恶意 AI Skills 需要许多同样的控制措施，但它们还带来了传统软件包扫描并非为理解而设计的行为风险。

一个 Skill 可以在不利用软件漏洞的情况下协调多个受信任工具。它可能指示智能体定位凭据、转换文件并将结果发送到其他地方。单独查看时，每一次工具调用都可能显得合理。

风险会随着智能体权限的提升而增加。仅限于起草文本的助手，其暴露面小于连接到 shell、浏览器、代码库和云账户的助手。企业智能体正越来越接近后一种模式。

这会产生乘数效应。Skill 提供指令，而智能体提供权限、推理和执行能力。攻击者无需将所有能力都构建到恶意扩展中。

OpenClaw 的 ClawHub 市场成为了一个早期案例研究。研究人员记录了以凭据和加密货币资产为目标的恶意 Skills。有些投递了已知恶意软件，另一些则操纵由智能体驱动的交易。

Palo Alto Networks 的 Unit 42 审查了 2026 年 2 月至 5 月期间的市场活动。其供应链分析发现，在推出新的筛查措施后，仍有五个未被拦截的恶意 Skills。

其中两个投递了连接到命令与控制基础设施的 macOS 信息窃取程序。另一个使用膨胀文件来规避扫描器阈值。其他 Skills 则通过针对自主智能体的特定行为实施金融操纵。

Unit 42 向 ClawHub 报告了这五个 Skills。该市场移除了它们，并封禁了相关账户。这一响应降低了即时暴露风险，但没有消除根本的分发问题。

更早的发现已促使 ClawHub 集成 VirusTotal 和 ClawScan。这些服务增加了主动筛查与代码级分析。OpenClaw 还宣布将与 Nvidia 合作开展 Skill 分析和文档工作。

这一过程颇具启示性：市场在恶意活动出现后增加了防御措施，但研究人员仍持续发现规避检测的 Skills。这与浏览器扩展、软件包注册表和移动应用周围长期存在的攻防竞争相似。

智能体 Skills 带来了另一项复杂因素，因为其实际内容可能超出下载的制品本身。本地 Skill 可能会指示智能体读取在线文档，而该外部页面可以在不改变已审查 Skill 的情况下发生变化。

因此，安全团队不能只依赖安装时的判断。安全结果仅描述扫描器在特定时刻观察到的内容，并不保证每一项依赖都会保持不变。

当员工能够直接添加 Skills 时，企业资产清单也变得更难管理。企业可能批准了某个智能体平台，却不知道用户之后安装了哪些社区扩展。这会在官方认可的产品内部形成影子 AI 行为。

这种区别对事件响应至关重要。调查人员需要知道运行了哪个 Skill、它加载了哪些指令、调用了哪些工具，以及访问了哪些信息。普通应用日志可能无法记录这条完整链路。

组织已经为部分系统维护软件物料清单。智能体部署也需要相应记录，涵盖模型、工具、Skills、外部指令来源、权限和版本。没有这张图，响应人员就无法可靠地判断暴露情况。

可搜索的内部记录还可在发现高风险扩展后支持调查。通过工程知识库整理本地技术证据的团队，可以保留审查决策、责任归属和修复背景。

这类记录不能替代运行时安全措施，但有助于确定谁批准了某项依赖以及批准原因。更大的要求仍是持续控制智能体能够读取、调用和传输的内容。

核心权衡在于智能体自主性与企业控制力

Skills 通过减少重复监督来增强智能体能力，也为恶意指令留下了操作空间。

企业智能体能够完成多步骤工作时才具有实用价值。它可能收集需求、检查文件、查询服务、生成制品并交付结果。若每一项细微操作后都要求批准，其大部分价值将被抵消。

授予广泛自主权能够解决可用性问题，却会扩大潜在影响范围。遭入侵的扩展可以复用让智能体高效工作的同一批连接。攻击者会通过智能体获授权的工作流间接继承访问权限。

这并不只是开放平台与封闭平台之间的较量。经过筛选的目录仍可能分发遭入侵的组件。私有 Skill 也可能在其代码库、维护者账户或外部依赖发生变化后变得危险。

开放市场会增加暴露面，因为发布和安装过程可能几乎没有摩擦。它们也让研究、移除和社区审查成为可能。将每个智能体都限制为仅使用内部编写的 Skills 可以降低部分风险，但会带来新的维护负担。

决定性问题在于权限是否遵循最小权限原则。一个落地页 Skill 不应需要对 SSH 密钥或云凭据的不受限访问。一个摘要 Skill 也不应悄然执行下载的 shell 脚本。

这一原则之所以耳熟能详，是因为它本就广为人知。最小权限数十年来一直指导着身份和应用安全。智能体系统让执行变得更难，因为智能体能够将多项各自获准的操作组合成不安全的序列。

Skills 还运行在语义层面。它们用自然语言描述目标和流程。传统安全控制擅长识别已知代码模式、文件哈希和网络指标。

但当危险行为被表述为看似合理的操作指南时，这些控制措施就不那么有效。某项指令可能要求智能体获取前置条件、验证账户或同步配置。有害意图只有结合上下文才会显现。

OWASP 的智能体 Skills 指南将这一行为层与工具连接层区分开来。工具定义可用操作，而 Skills 将这些操作编排为工作流。

OWASP 将恶意 Skills、供应链入侵、过度权限、不受信任的外部指令、隔离不足和更新漂移列为主要风险。这份清单表明，单一扫描器或单项策略无法覆盖整个问题。

安全架构需要多重边界。市场必须建立来源可追溯性。智能体平台必须执行权限控制。运行时控制措施必须观察操作行为，而组织必须维护资产清单和所有权。

当人工审批围绕有实质风险的操作设置时，仍然很有价值。将普通草稿发送到内部文件夹或许可以自动进行。上传机密文件或更改生产基础设施则应要求更严格的授权。

挑战在于避免无意义的提示。用户经常会批准自己并不了解的请求，尤其是在中断变得频繁时。审批对话框无法弥补过度宽松的默认权限或不可见的依赖项变更。

企业采购方还应区分一项 skill 的实用性与可信度。受欢迎程度反映的是采用情况，而非安全性。大量星标可以形成社会认同，却无法说明外部指令当前的行为。

同样的谨慎也适用于市场徽章。批准或许能确认某项提交已通过审核，但并不能保证链接资源、代码库所有权或下游软件包将保持稳定。

这种权衡将塑造企业采用的方式。封锁所有扩展的安全团队，会把试验活动推向无管理的环境。允许无限制安装的团队，则会形成不断扩张、无法审查的依赖关系图。

可行的折中方案是受治理的自主性。用户可以使用已获批准的能力，而高风险操作仍保持隔离且可观察。skill 获得与其用途相匹配的权限，而不是宿主智能体具备的所有权限。

受治理的自主性还要求具备撤销能力。当一项 skill 变得不安全时，管理员需要找到每一个安装实例、将其禁用、使已暴露的凭据失效，并审查相关活动。仅仅从市场下架并不足够。

静态扫描器正在失去信任竞争

最强烈的警告来自一项看似无害的研究 skill：据称它在通过现有扫描器后，触达了超过 26,000 个智能体。

AIR Security 的研究人员创建了一项名为 brand-landingpage 的 skill。它看似旨在帮助非技术用户使用 Google 的 Stitch 设计工具构建落地页。该 skill 提供了真实功能，因此显得可信。

研究人员将它提交至一个颇受欢迎的开源集合，该集合包含 156 项 skill，并在 GitHub 上获得约 36,000 个星标。数日后，这项贡献获得接纳。随后，AIR 通过面向营销人员、设计师和销售人员的 Instagram 广告推广该 skill。

打包后的 skill 起初并不包含明显的恶意载荷。相反，它引导智能体前往由研究人员控制的域名上的安装文档。该域名最初会将访问者重定向至合法的 Stitch 服务。

AIR 随后更改了外部指令。修订后的页面要求智能体下载并执行脚本。在这项实验中，载荷会收集电子邮件地址，以便通知受影响用户。

研究人员表示，没有智能体受到伤害。他们还表示，这种技术原本可能触及私人对话和已连接的内部系统。这些更广泛的影响是可能结果，而非实验中有记录的损失。

AIR 对这项受控 skill 测试的说明称，来自 Cisco、Nvidia 和 skills.sh 的扫描器都将该提交标记为安全。结果暴露了静态审查的结构性局限。

扫描器可以检查 skill 当前的文件，却仍会错过托管在其他位置的未来内容。外部文档构成一种可变依赖项。其所有者可以在市场和用户建立信任之后更改指令。

这种方法类似于成熟软件生态系统中的延迟恶意更新。区别在于交付方式：攻击者可以修改普通语言，而智能体随后会将其解读为具有权威性的程序性指导。

静态分析仍有价值。它可以识别已知恶意代码、混淆命令、可疑 URL、过度权限和危险的软件包依赖项。错误在于将一次干净的扫描视为持久的信任决策。

行为测试增加了另一层防护。沙箱可以在受限的智能体环境中运行 skill，并观察其尝试进行的文件访问、下载、命令和网络通信。这种方法可以暴露隐藏在看似合理文本背后的行为。

但沙箱也有局限。攻击者可以延迟激活、对环境信号作出反应，或向已知分析系统提供无害指令。测试同样无法预见 skill 与企业内部工具之间的每一种交互。

因此，安装后的持续监控至关重要。安全系统需要在 skill 联系新域名、请求更广泛的数据、改变执行模式或调用超出预期用途的工具时加以检测。

内容固定可以减少外部指令漂移。企业可以保留经过审查的文档版本，或要求下载组件提供加密哈希。智能体不应自动信任可变 URL 之后提供的任何内容。

网络控制提供了另一道检查点。不需要互联网访问的 skill 不应获得该权限。其他 skill 则可以被限制为仅访问获批准的域名、方法和目的地。

运行时可见性必须超越网络流量。防御人员需要一条追踪链，连接用户请求、所选 skill、检索到的指令、模型决策、工具调用以及由此产生的数据流动。否则，每项操作都会失去其行为语境。

AIR 实验并未证明每项热门 skill 都不安全。它表明，常见的信任信号可能会围绕一个错误结论达成一致。声誉、市场接纳和扫描都支持了同一个经过恶意设计的工件。

这正是企业领导者应保留的怀疑视角。安全供应商正在推出 AI 专用扫描器，但没有任何扫描器能为可变工作流提供永久保证。应根据实时规避测试和透明的失败率来评估产品主张。

Google News 的报道可以提升认知，但认知并不能建立技术控制。采购方需要证据表明，智能体平台能够在 skill 通过审核后仍约束其操作。预防和遏制必须协同运作。

谁正承受不断扩大的风险压力

智能体平台、安全供应商和企业采购方如今共同承担着一项任何一方都无法单独治理的依赖关系责任。

市场运营方承受着最直接的压力。他们必须在社区快速增长与发布者验证、工件审查、更新控制和事件响应之间取得平衡。更高的提交摩擦可能减缓增长，但薄弱的控制会损害信任。

智能体平台开发者控制执行环境。他们决定 skill 是以宿主权限运行、在容器中运行，还是通过受限工具运行。他们的架构决定了恶意指令能够触及多远。

安全供应商面临不同的考验。他们需要识别通过代码、自然语言、可变网站和合法管理工具表达的有害行为。现有的端点与网络信号依然有价值，但语义上下文变得不可或缺。

企业安全团队无法将整个问题外包出去。他们决定哪些平台进入组织，以及这些平台获得哪些连接权限。他们还决定员工能否在未经审查的情况下安装社区 skill。

开发人员仍是高风险群体，因为编程智能体通常拥有 shell 和代码库访问权限。恶意 skill 可能瞄准源代码、软件包凭据、签名密钥、云令牌或部署配置。

非技术用户面临的是不同的暴露面。营销或销售 skill 可以访问电子邮件、客户记录、品牌资产、会议笔记和内容系统。其友好的界面可能掩盖底层智能体所拥有的权限。

因此，采购团队需要提出超越模型准确率的问题。他们应询问平台如何发现已安装的 skill、记录版本、处理外部指令以及隔离用户环境。

他们还需要了解撤销机制。管理员能否在所有端点禁用一项 skill？他们能否识别在其安装期间哪些凭据可被访问？

合规团队会关心证据。如果智能体通过未经批准的 skill 传输客户信息，组织必须重建事件经过。通用聊天机器人记录可能无法解释每一次下游工具调用。

事件响应人员面临类似需求。他们需要不可篡改的日志和可靠的时间线。他们还需要知道，被移除的 skill 是否在其他位置建立了持久化机制，例如定时进程或被修改的配置。

Unit 42 的发现说明了这一问题。研究人员观察到与恶意市场活动相关的持久化机制。移除可见的条目，并不会自动中和每一个已部署的载荷或命令通道。

在确认发生恶意安装后，企业应将智能体凭据视为可能已暴露。这意味着撤销相关令牌、审查身份验证活动、检查被修改的文件，并分析出站连接。

风险并非在所有部署中均匀分布。使用合成数据的隔离研究智能体带来的后果有限。连接到生产系统的自主智能体则会带来大得多的控制问题。

这一差异应指导政策制定。组织可以根据可访问数据、可用工具、自主性、网络覆盖范围和业务影响对智能体与 skill 进行分类。风险更高的组合应接受更严格的审查和监控。

压力也延伸至 AI 治理项目。许多项目关注模型选择、隐私条款、输出准确性和可接受使用方式。恶意 AI skill 引入的运营依赖关系，更像应用安全问题而非模型治理问题。

治理委员会需要技术所有权，而不只是书面原则。必须有人负责批准 skill 来源、维护资产清单、设定权限边界，并在可信依赖项发生变化时作出响应。

成功的方法不会依赖单一部门。平台工程可以执行部署控制，安全团队可以监控行为，而业务所有者则定义可接受的任务和数据访问范围。

如果缺乏这种协调，组织将形成两条都不令人满意的路径。获批准的智能体会因限制过多而无法发挥作用，而员工则会安装控制较少的替代方案。这两种结果都会削弱企业监督。

三个信号将显示防御是否正在追赶

下一阶段将通过市场控制、企业运行时证据和独立检测测试来衡量。

第一个信号是，主要 skill 注册中心是否采用可验证的来源追溯和不可变版本管理。市场应识别发布者、保留经过审查的工件，并公开每一次变更。外部指令同样需要资产清单和完整性控制。

如果注册中心广泛实施这些措施，攻击者在替换可信内容时将面临更多阻力。这将强化这样一种观点：开放的 skill 生态系统可以在不放弃社区贡献的前提下走向成熟。

如果注册中心继续依赖受欢迎程度和一次性扫描，当前的风险评估就会更具说服力。随着有价值的 skill 积累用户，应预期会出现更多延迟载荷和依赖项接管。

第二个信号是，企业级智能体平台是否提供可强制执行的、技能级别的权限控制。管理员需要为文件、工具、凭据、命令和网络目标设置边界。这些边界必须随技能在每一次部署中一并生效。

清晰的运行时追踪同样重要。安全分析师应能够将某项操作与触发该操作的技能及外部指令关联起来。日志应能抵御本地篡改，并支持组织范围内的检索。

如果平台能够提供这些控制措施，恶意技能就更容易被遏制。它或许仍会进入环境，但其触及无关资产的能力将受到压缩。这将削弱最严重的企业级风险场景。

如果平台将每个技能都暴露给智能体的全部权限，风险就仍会集中在终端侧。一个被忽视的扩展程序可能继承对许多无关系统的访问权。

第三个信号是，是否针对可变且延迟触发的攻击进行独立测试。扫描器评估应涵盖外部指令变更、受信任域名重定向、休眠载荷、代码仓库接管，以及以不安全顺序使用的合法工具。

这项26,000-agent experiment提供了这样一种测试。未来的评估需要可重复的方法、透明的样本，以及能够区分可疑行为与已确认恶意软件的披露机制。

独立工具之间检测结果的一致性，将表明市场正在形成共享的安全基线。若分歧很大，则说明各供应商对恶意行为的定义仍不一致。

组织不应等待完美的标准。他们现在就可以开始盘点已安装的技能，并将每项技能映射至对应的负责人、来源、版本、权限和外部依赖项。

他们可以隔离高权限智能体、限制网络访问，并要求对敏感操作进行审批。他们还可以在依赖项发生变化时重新扫描技能，而不只是在用户首次安装时进行扫描。

团队应将被移除或新近被标记的技能视为事件触发因素。响应流程应检查凭据、持久化机制、数据访问以及对外通信。删除本地技能只是第一步。

Google News 对恶意 AI 技能的关注，应引出一个实际问题：你的组织能否说明每个企业智能体被允许执行哪些操作？如果答案并不完整，应从那些连接到代码、云系统、客户数据和内部通信的智能体开始。梳理它们的技能，限制不必要的权限，并保留调查其操作所需的证据。AI 智能体安全并不取决于找到一款完美的扫描器，而在于将可信分发、有限权限、持续观察和快速撤销结合起来，防止一个看似有用的扩展程序演变为企业安全事件。