受信任的技能就是攻击本身：Copilot Cowork 与智能体供应链
AI 智能体的卖点是它们能替你使用各种工具。一位研究 Microsoft Copilot Cowork 的研究人员找到了一种方法，把这个卖点反过来用于对付用户，而它所走的路径，很大程度上说明了智能体安全的发展方向。
PromptArmor 于 9 月 30 日披露了这一发现。简而言之：一个下载来的“技能”看似只是无害的文档检查工具，却能劫持 Cowork 自身的网络通道，向攻击者的服务器开启一条命令通道，并从 Outlook、SharePoint 和 Teams 中窃取数据。据研究人员所述，微软于 6 月收到报告，并在 8 月完成了修复，因此技术细节是在修复之后而非之前公布的。
四个步骤，其中只有两个与你有关
这场攻击只需要用户做两件再普通不过的事：上传一份文档供审阅，以及调用一个技能。
在演示中，该技能声称能把一份合同与一份提案进行比对并标出不一致之处。它确实做到了，而这正是这类攻击难以察觉的原因。问题出在随技能一起打包的一个脚本上。Cowork 运行在一个本不应访问开放互联网的沙箱中，但它确实维护了一条桥梁，用于处理生成回答所需的请求。恶意脚本利用了可通过这条桥梁访问的文件同步服务，而关键在于，该服务会接受调用方提供的 URL。
这个细节就是整个漏洞利用的核心。一旦脚本能访问攻击者控制的地址，它就开启了一个循环。每隔几秒，它便获取一个包含命令的文件，在 Cowork 内执行该命令，并把结果编码进一个 URL 参数回传给服务器。这是一条双向命令通道，而非单向信标，这意味着攻击者可以根据上一条命令的返回结果下达新指令。
在演示中，研究人员列出了受害者的 Outlook 邮件，并读取了一个邮件会话的内容。根据该报告，同一条访问路径还暴露了 SharePoint 文件、会话历史和插件数据。它能触及多远，取决于相关用户本身能看到什么，这也是此类事件中常见的放大因素：智能体继承用户的权限，因此影响范围就是该账户能够触及的一切。
还有一个细节值得重复，因为它会改变人们对阻止攻击的看法。点击停止控件并没有终止后台进程。可见的那一轮对话可以结束，而脚本仍在持续轮询。用户以为任务已经结束，通道却依然敞开。
技能就是依赖项
这次披露中有意思的地方并不是那个具体的漏洞，它现在已经被修复了。而在于攻击面并非对模型指令的提示注入，而是智能体周边的供应链。
在这类系统中，技能就是一个个微型应用。它们可以打包脚本、参考文档和配置，在 Cowork 的情况下最多可包含二十个附属文件，而且它们往往来自组织外部，从市场下载或同事之间分享。这与当年在 npm 和 PyPI 生态中制造多年麻烦的结构如出一辙：一个不是你写的依赖项，可以执行你未曾读过的代码。智能体技能不过是换了个更友好名字的依赖项。该技能页面上的描述声称所有处理都在本地完成，不会向第三方发送任何内容。而平台自身的检查并未发现这个打包脚本的真实行为。
还有第二起更悄无声息的泄露，指向同一个薄弱点。Glow 的一份报告发现，智能体通过公开的 GitHub 仓库暴露了来自 300 多家组织的 13,000 多张内部图片和截图。没有人打算公开这些文件。它们之所以公之于众，是因为某个智能体把它们写到了公开仓库能够访问到的地方。
这两起事件看似不同，却有着共同的根源。一起是恶意技能有意向外伸手；另一起则是一个行为规矩的智能体把数据写到了它并不知晓是公开的地方。两者都是智能体可触及范围及其输出传播距离这一边界失守。Cowork 的案例展示的是攻击者利用了这一边界；GitHub 的案例展示的则是边界自行失效，无人试图突破它——可以说，这在日常使用中是更常见的结果。
如何解读这样一份安全披露
时间线是大多数读者会跳过的部分，但它值得细看，因为它能告诉你该如何权衡这项发现。PromptArmor 于 6 月底向微软报告了该问题。微软在 7 月要求提供更多信息，8 月初讨论了修复方案，并在 8 月中下旬确认了修复。研究在 9 月底，也就是补丁发布之后才公开，这是标准的负责任披露流程。由此可以得出两点启示。
第一，修复了一个漏洞并不等于修复了一类漏洞。具体的利用路径已经关闭。但使其成为可能的模式——智能体必须访问的受信任集成可被用作任意通道——只要智能体拥有被允许的网络路径，就会显现。同一周还出现了其他指向同一薄弱点的例子，包括有报告称智能体通过公开仓库暴露了数千张内部图片。不同的漏洞，相同的形态。
第二，修复是按微软的时间表到来，而不是你的。任何在企业中使用这些工具的人，都需要知道自己用的是哪个版本，以及更新是否真正落实到了自己身上。博客上的一则补丁说明，并不等同于已经完成补丁的部署。
技能就是依赖项
在听闻这样的故事之后，人的本能是更加信任沙箱。Cowork 的沙箱在阻止直接访问互联网方面尽到了职责，而这次漏洞利用是借助沙箱不得不保持开放的一条路径绕过了边界。这是一种普遍模式：一个没有直接网络工具的智能体，如果它能在一个日后会拉取外部资源的界面上写入内容，或驱动一个这样做的服务，那它仍然不是一个封闭系统。
对于在企业环境中运行智能体的团队而言，实际的应对措施与其说像安全补丁，不如说更像常规的软件治理。弄清楚安装了哪些技能，它们来自哪里。把技能安装纳入 IT 管控，而不是交由各个用户自行处理。像对待任何新的可执行文件那样对待带有网络路径的技能，在运行前先审查。核对安全更新是否确实覆盖了正在使用的版本。
这些都不算新奇。这是过去十年供应链安全迫使软件团队养成的纪律，如今上升了一层。不同之处在于代价。一个被入侵的 npm 包可以在开发者的机器上运行代码。一个被入侵的技能则运行在一个已经能访问你的邮件、文件和聊天记录的智能体内部，而且在你以为自己已经让它停止之后，它仍能继续运行。