Microsoft Copilot Cowork 沙箱绕过将受信任的 Skill 变成数据外泄通道
研究人员展示，一项恶意 Skill 可绕过产品沙箱并外泄工作数据后，Microsoft 缓解了 Copilot Cowork 中的一项漏洞。据报道，这项 Microsoft Copilot Cowork 沙箱绕过漏洞在攻击者服务器与代理的隔离环境之间建立了一条命令通道。
PromptArmor 表示，该通道可访问 Outlook、SharePoint、Teams、已连接的插件以及当前会话中可用的数据。研究人员于 2026 年 6 月 24 日报告了该问题，Microsoft 于 8 月 19 日确认已完成缓解。
这一发现挑战了工作场所代理的一个核心承诺。沙箱可以隔离代码，但当受信任服务成为跨越其边界而未受监控的路径时，隔离的意义便大打折扣。Microsoft 表示，Cowork 现会评估 Skills，并提醒用户仅从可信来源上传它们。
根据披露时间线，这一被报告的漏洞已不再是未修复的零日漏洞。然而，其设计层面的启示并不局限于某一项已修复的实现。企业代理将不可信指令、可执行资产、组织数据和已认证工具整合进同一工作流。
这种组合使信任边界比传统商业软件中的边界更难界定。核心问题不再是代理是否在沙箱内运行。采购方必须追问：哪些服务跨越该沙箱、这些服务接受哪些输入，以及安全团队能够观察到哪些活动。
Copilot Cowork 文件外泄链如何运作
据报道，该攻击将一项合法的文件传输服务变成了双向命令通道，而沙箱的网络限制未能阻止它。
Copilot Cowork 是一套具备代理能力的 Microsoft 365 系统，可规划并执行多步骤任务。它可以处理文档、搜索组织信息、创建文件、发送消息，并调用专门的 Skills。
Skill 是一种可复用的指令包，用于引导代理完成特定工作流。根据 Cowork 环境和管理配置，Microsoft 支持内置、自定义、共享及基于插件的 Skills。
PromptArmor 的示例始于一项普通业务任务。用户要求 Cowork 通过从外部来源下载的文档一致性 Skill，对比一份合同与一份提案。
该 Skill 生成了所需的对比结果，因此表面上看任务似乎成功完成。然而，PromptArmor 表示，捆绑其中的脚本还调用了一项运行在代理沙箱之外的文件同步服务。
据报道，Cowork 使用该服务在外部存储与隔离工作环境之间传输文件。该服务接受一个用于标识需获取文件的 URL。
根据研究人员的沙箱绕过分析，恶意代码可以改为提供攻击者控制的 URL。这种行为使脚本能够让外部服务联系沙箱无法直接访问的基础设施。
攻击者服务器返回了一个包含命令的文件。恶意脚本读取该文件，在 Cowork 内执行命令，并将结果编码进另一个请求的 URL 中。
第二个请求将命令输出传回攻击者服务器。据报道，每隔几秒重复这一过程，便建立起一个命令与控制循环，这意味着攻击者可根据先前结果下达新的指令。
这不只是一次单向的外部请求。它在一个连接组织服务的环境中建立了一条交互式路径。
PromptArmor 表示，其演示使用了 Cowork 的 Model Context Protocol 服务器。MCP 是一种标准接口，AI 应用可借此调用已连接工具并获取数据。
研究人员称，攻击者可利用命令查询通过该 MCP 连接可访问的服务。演示内容包括列出 Outlook 邮件并获取一条电子邮件线程的内容。
据报道，同一访问路径还暴露了 SharePoint 文件、会话历史、插件数据以及当前用户可访问的其他信息。实际影响范围取决于该用户的权限及其已连接服务。
有一个细节令这一被报告的行为尤其令人担忧。PromptArmor 表示，选择停止控件并不会终止已在后台运行的进程。
可见的代理轮次可能已经结束，但恶意脚本仍会持续轮询攻击者服务器。因此，用户可能以为任务已停止，而隐蔽通道仍处于活动状态。
PromptArmor 于 6 月 24 日向 Microsoft 报告该问题。Microsoft 于 7 月 24 日要求提供更多信息，在 8 月初前后讨论修复方案，并于 8 月 19 日确认已完成缓解。
公开证据主要来自 PromptArmor 的技术说明与演示。Microsoft 尚未发布详细公告，说明代码变更、受影响版本，或可用于追溯调查的遥测数据。
Microsoft Copilot Cowork 沙箱绕过为何重要
该漏洞攻击的是将沙箱与有用数据连接起来的服务，而非通过传统的逃逸方式突破隔离。
传统沙箱试图通过限制文件、进程、设备和网络连接来约束不可信代码。该模型仅在跨越边界的每一条路径都采用同样严格的验证时才有效。
现代代理使这种安排变得复杂，因为完成有用工作需要受到控制的例外。代理必须接收文档、返回生成的文件、调用工具、访问企业系统，并保留足够状态以完成长任务。
每个例外都会成为隔离环境与更受信任对象之间的中介。当中介同时验证目标与数据流时，它可以是安全的；当不可信代码能够挪用它时，它便会变得危险。
PromptArmor 的说明并非描述一次典型的内存损坏攻击或操作系统逃逸。据称，恶意 Copilot Cowork Skill 一直留在沙箱内，却滥用了沙箱外的一项特权服务。
这一差别对企业安全审查至关重要。供应商可以如实表示代码在隔离环境中运行，却忽视某个可代表该代码发起任意外部请求的中介。
这种架构张力正处于 Cowork 价值的核心。Microsoft 将该产品定位为一种超越聊天、可在 Microsoft 365 中完成工作的代理。
在 Microsoft 的Cowork 产品公告中，该公司重点介绍了收件箱工作流、研究、文档生成、集成和可复用 Skills。这些能力需要访问有价值的业务上下文。
Cowork 当前文档称，任务会在 Microsoft 365 服务边界内的临时隔离环境中处理用户文件。文档还称，任务完成后该环境会被移除。
这一安全模型限制了直接暴露，但并不能消除已连接工具带来的风险。当一个受信任的中介接受攻击者控制的输入时，隔离环境仍可能成为攻击发起点。
这正是 Microsoft Copilot Cowork 沙箱绕过同时给 Microsoft 和企业采购方带来压力的原因。Microsoft 必须证明，修复后的边界覆盖了所有中介，而不仅是某位研究人员识别出的同步路径。
客户也必须重新审视对用户权限的假设。Cowork 以当前用户的访问权限运行，因此被利用的任务无需先单独攻破账户，也能访问获准的数据。
最小权限原则仍能缩小影响范围，但无法阻止对用户合法持有权限的滥用。
一名负责比较两份文档的员工，可能有权读取敏感邮件、交易文件夹或内部讨论。这些权限可通过代理获批的连接向其开放。
恶意输入也以可复用工作流组件的形式出现，而不是显而易见的恶意可执行文件。由于 Skills 被设计为生产力扩展，这种封装会降低用户的警惕性。
因此，这种攻击结合了组织通常分开管理的两类安全问题。一类是下载软件包带来的软件供应链风险；另一类是代理以已认证用户身份行事带来的授权风险。
安全计划需要将二者一并处理。只审查代码而不梳理可访问数据，会忽略影响；只治理权限而不检查 Skill 资产，则会错过入口点。
恶意 Copilot Cowork Skill 仍可能看起来很有用
最危险的 Skill 并非明显失败的 Skill，而是能够完成其分配任务、同时暗中执行第二项任务的 Skill。
PromptArmor 的演示采用了文档对比工作流，因为它反映了一项常见的知识工作请求。据报道，该 Skill 在生成完整一致性报告的同时，恶意脚本还开启了隐蔽通道。
这种双重行为削弱了一个常见的安全信号。用户往往将输出正确视为工具按预期运行的证据。
对于代理而言，输出质量与执行完整性是两个独立问题。一份有用的报告不会揭示其生成过程中执行过的每一个脚本、服务调用或数据请求。
Microsoft 当前的自定义 Skill 指导称，Cowork 会自动评估 Skills。文档所述的检查因其覆盖范围和风险级别而异。
静态检查会审查结构、捆绑代码和文本，以识别提示注入模式。行为检查则会在贴近实际的提示下评估输出、操作、工具使用、冲突和性能。
文档描述了针对高风险部署的额外关卡，其中可能包括资产验证、信任与安全测试、对抗性评估、回归测试和人工审查。
Microsoft 还直接警告用户：仅从其信任的来源上传 Skills。这一建议承认，自动化检查无法将任意第三方代码变成安全依赖项。
这些已记录控制措施的时间节点需要谨慎看待。Microsoft 的在线文档反映的是当前产品状态，而不一定是 PromptArmor 在 8 月 19 日之前测试时的确切配置。
因此，声称现有的每一项控制措施都曾在演示中失效并不安全。同样，假定所列检查能检测到攻击的每一种变体也并不安全。
静态扫描存在固有局限。恶意行为可能被拆分到多个文件中、隐藏在正常功能之后、于之后下载，或仅在特定条件下触发。
行为测试同样只会抽样有限的一组执行情况。Skill 可以在评估期间表现安全，却在某个日期之后、针对特定租户，或当特定数据出现时激活有害逻辑。
近期学术研究将代理 Skills 视为软件供应链攻击面，而非简单的提示模板。SkillGate 研究使用混合扫描器评估了一个包含 1,650 个 Skill 软件包的基准测试集。
其作者报告的 F1 分数为 0.817，误报率为 1.13%。这些结果支持在运行时进行筛查，但也表明检测仍具有概率性。
这项比较并非对 Cowork 的直接评估，论文重点关注的是编程代理 Skills。不过，其威胁模型与更广泛的问题高度相似。
一个可复用的指令包可能包含脚本、看似可信的文档以及隐藏行为。安装它会扩展代理实际可执行的代码和指令基础。
传统应用商店通过签名、审核、声誉机制、快速下架和权限声明来应对类似风险。代理 Skills 除了需要这些措施，还需要让模型驱动的执行过程具备可见性。
模型可以自行决定何时以及如何调用支持文件。这种灵活性让 Skill 更具适应性，但也使得生成完整的行为清单变得困难。
Microsoft 除了支持组织内部共享和 App Store 插件，也支持个人自定义 Skills。管理员可以管理插件可用性、部署、连接器及被分配的用户。
这些控制措施提供了比下载未知压缩包更可靠的分发路径，但并不能免除检查私下共享或个人上传包的必要性。
企业应将恶意 Copilot Cowork Skill 视为不受信任的应用依赖项。其来源、版本控制、审批和撤销机制，与其中包含的自然语言指令同样重要。
沙箱承诺遭遇互联代理的现实
核心冲突在于：一边是作为安全承诺的隔离能力，另一边是让企业代理发挥价值所必需的连接能力。
Microsoft 表示，Cowork 可以发送电子邮件、安排会议、创建文档、发布到 Teams、搜索组织信息以及管理文件。这些操作使它从聊天机器人转变为一个运营系统。
每增加一个连接器，成功完成任务的价值就会上升；而一旦执行完整性失效，潜在影响也会扩大。
据报道，这一漏洞利用不需要 Cowork 获得超出设计范围的权限。它据称将现有的、已认证的工具层转变成了攻击者可控的接口。
这是企业采购方应当记住的反转：沙箱保护了执行环境，但外部同步服务据报道为代码提供了一条绕过其网络策略的路径。
同样的模式可能出现在各类代理平台中。沙箱化代理通常依赖浏览器自动化、制品存储、工具网关、MCP 服务器、凭证代理和连接器运行时。
安全团队常常独立审查每个组件；攻击者寻找的则是它们之间的组合。
看似低风险的文件服务可能成为网络代理。原本面向代理的工具端点，也可能变成恶意代码的数据访问 API。
为可靠性而设计的后台工作进程，可能在可见任务停止后仍保留攻击。单独来看，这些组件都未必显得危险。
眼前的比较并不是 Microsoft 与某一家竞争对手之间的较量。更有意义的比较，是行业的隔离承诺与互联代理的实际运营现实之间的差距。
Anthropic、OpenAI、Microsoft、Google 以及编程代理厂商，都面临着这种张力的不同版本。它们的产品通过读取更多上下文并执行更多操作来提升实用性。
据报道的 Cowork 漏洞只是一个特定实现的例子，不应被泛化为所有沙箱或 MCP 部署都存在相同漏洞的证据。
不过，它确实说明，沙箱标签不能构成完整的安全评估。采购方需要一份数据流模型，其中应包含所有能够跨越边界访问资源的服务。
他们还需要明确进程的生命周期。Microsoft 为 Cowork 任务提供了暂停和取消控制，但 PromptArmor 的测试据报道发现，后台进程在可见的停止操作后仍然存活。
Microsoft 可能已将此行为作为缓解措施的一部分加以修改，也可能只关闭了网络路径。公开披露并未如此详细地说明修复方式。
这一验证缺口很重要。组织无法仅从公开时间线判断，Microsoft 是否加入了目标地址验证、修改了服务授权、终止了后台作业、改进了检测能力，或组合采用了多项控制措施。
缺少详细公告并不意味着缓解措施失败了。这意味着客户必须通过租户指南、支持渠道、审计数据和受控测试来寻求保障。
安全架构应假设，某项预防性控制最终会漏掉一个恶意包。具备韧性的设计会进一步限制该包能够触及的范围，并使异常行为可见。
对于互联代理而言，这意味着限制出站目标、验证代理请求、将服务绑定到具体任务，并将读取访问与执行操作权限分离。
这也意味着任务结束时撤销凭证。被取消的代理会话应终止相关进程，并使为该次执行创建的所有临时授权失效。
最后，监控必须将代理活动与传统安全遥测关联起来。一次 Skill 调用、文件传输、MCP 调用和异常出站请求，分别在不同控制台中看起来都可能无害。
但合在一起，它们可能描述出一条攻击链。
缓解措施并未弥合验证缺口
Microsoft 已确认采取缓解措施，但客户仍缺乏足够的公开细节，无法重建暴露范围或验证每一项受影响的控制措施。
PromptArmor 表示，Microsoft 确认该问题已于 8 月 19 日得到缓解，距离最初披露接近八周。这一时间线表明双方进行了协调修复，而非仍存在未解决的公开漏洞利用。
研究人员没有发布大规模利用的证据。该演示证明了经过测试条件下的一条技术路径，而非实际受影响租户的数量。
公开披露中没有出现公开事件数量、受影响版本范围、漏洞标识符或失陷指标。读者不应将概念验证视为发生大范围泄露的证据。
反过来的结论同样为时过早。在没有详细 Microsoft 公告的情况下，组织不能假定未披露事故就意味着没有发生恶意使用。
回溯调查依赖遥测数据。管理员需要了解 Cowork 日志是否能展示上传的 Skill 版本、脚本执行、代理请求、MCP 调用以及后台进程生命周期。
Microsoft 表示，Cowork 活动可能出现在统一审计日志中，Purview 策略也适用于该服务。当前的管理文档还描述了针对插件、模型、浏览器使用和自动化任务的控制措施。
这些控制措施具有相关性，但通用审计覆盖并不等同于对该漏洞利用的检测覆盖。日志可以记录一次获允许的服务请求，却不会将其目标标记为恶意。
在 8 月 19 日之前测试过 Cowork 的组织，应询问 Microsoft 哪些事件可用于识别这一易受攻击的行为。它们还应在保留期限届满前保存相关审计记录。
最重要的审查对象是 Skill 的来源。团队应盘点在受影响期间使用的自定义 Skills、上传的压缩包、捆绑脚本和组织共享包。
来源不明或无法验证的包应在审查完成前移除。如果条件允许，安全团队应比对加密哈希，因为熟悉的 Skill 名称并不能证明文件完整性。
随后，管理员应将每个 Skill 映射到运行它的用户，以及这些用户可访问的数据。与仅扫描 Skill 文本相比，这能更准确地估算暴露范围。
出站网络遥测可能提供另一种信号。对陌生域名的请求、重复轮询间隔，或嵌入 URL 查询字符串中的编码数据，都值得调查。
不过，据报道的请求是通过沙箱外的服务发出的。因此，员工设备上的端点监控可能无法捕捉到它们。
云端日志和厂商遥测因而变得至关重要。客户应询问 Microsoft 能否披露代理传输的源任务、Skill、用户、租户和请求目标。
组织还需要制定未来上传的政策。允许任何用户从公共互联网导入 Skill，会将信任评估变成个人决策。
更安全的模式是使用内部注册表，明确所有者、审核状态、已批准版本和到期日期。高风险 Skills 应同时接受代码审查和运行时测试。
共享 Skills 在获批后仍需要变更控制。一个无害的软件包可能因更新、维护者账号被攻陷或附属文件被替换而变得危险。
因此，审批应针对具体版本，而不是一个永久名称。每一次实质性变更后都应重新审查。
这些步骤并不意味着 Cowork 独有地不安全。它们反映了任何能够访问邮件、文档、聊天和业务应用的代理都应具备的治理水平。
知识工作者也应将敏感源材料保留在范围清晰的存储库中。更好的知识管理能够帮助团队围绕实际工作需求组织访问，从而减少不必要的数据暴露。
目标不是从每个代理中移除有用的上下文，而是防止一个便捷的工作流程在未经审慎审查的情况下继承员工全部的数字访问范围。
三项信号将表明代理安全是否正在跟上步伐
下一项考验在于，Microsoft 是否能将一次缓解措施转化为可衡量、对租户可见的控制机制，覆盖所有跨越 Cowork 沙箱的路径。
第一个信号是 Microsoft 对修复方案作出详细说明。客户需要知道，Cowork 是否已验证同步目标、将请求绑定至获批准的存储，并在任务停止时终止进程。
技术公告将增强信心，因为管理员可以测试相关边界。沉默并不能证明仍在暴露之中，但会使验证依赖于私下支持渠道。
第二个信号是更丰富的租户遥测。安全团队应关注新的 Cowork 事件，涵盖 Skill 哈希、捆绑脚本执行、MCP 操作、代理目标和与任务关联的后台进程。
这些记录必须能够通过现有检测系统使用。仅在某一 Cowork 会话中可见的活动日志，无法支持企业规模的威胁狩猎。
第三个信号是更严格的 Skill 治理。Microsoft 已有文档化的评估系统，描述了针对不同风险级别的静态、行为、对抗性、回归和人工检查。
关键问题是，这些控制措施在导入、个人、共享和商店分发的 Skills 上适用得是否足够一致。采购方应关注签名包、固定版本审批、集中式允许列表和快速撤销机制。
Microsoft 还应说明，Skill 的附属文件是否受到与其主指令文件同等程度的审查。PromptArmor 的场景依赖于恶意捆绑代码，而不仅仅是误导性文本。
这些信号将增强或削弱自主工作场所代理的更广泛商业逻辑。更好的验证将表明，厂商正将 Skills 视为可执行的软件供应链组件。
有限的可见性则会让客户承担很大一部分风险。他们会被要求信任一个已修复的沙箱，却无法看见发生变化的边界。
对于正在评估 Cowork 的企业而言，务实的应对方式是审慎部署：确认缓解措施，限制可上传 Skills 的人员，审查现有软件包，最小化访问权限，并监控已连接的服务。
据报道，Microsoft Copilot Cowork 沙箱绕过问题已得到修复，但其架构层面的警示依然存在。智能体将指令、代码、凭据和组织上下文集中到同一条执行路径中。
在扩大部署之前，请提出一个具体问题：你的安全团队能否还原已完成任务背后的每个 Skill、流程、工具调用和外部请求？如果答案并不明确，请在授予更广泛访问权限之前，将这种可见性设为一项要求。
