2026 年 1 月 21 日，微软检测到一起影响 Microsoft 365 Copilot 的严重安全事件：Copilot 的 “工作标签页” 聊天功能错误地读取并摘要用户已发送邮件和草稿文件夹中的内容，即便这些邮件已标记为机密性质并配置了数据丢失防护策略。这一漏洞（CW1226324）暴露了当前企业级 LLM 应用在数据流隔离层面的系统性缺陷，值得安全团队深入审视。
问题本质：提示词上下文的非预期数据泄露
Copilot 的设计逻辑是将用户提问与相关上下文一起打包发送给大语言模型，由模型生成响应。在正常情况下，敏感标签（Sensitivity Label）和 DLP 策略应当阻止特定内容进入提示词上下文。然而，该漏洞的根因在于代码逻辑错误：系统未能正确识别已标记为 “机密” 的邮件内容，导致这些本应被过滤的数据被错误地纳入 Copilot 的检索范围并用于生成摘要。换言之，攻击面并非来自外部入侵，而是 LLM 应用自身的数据治理缺陷 —— 过滤层在应用层失效，使得机密信息以一种看似 “合理” 的方式进入了模型推理流程。
这种泄露机制与传统 API 越权不同：它发生在应用层的数据预处理阶段，传统的网络防火墙或身份验证机制无法检测。从工程视角看，问题出在数据流管道中的 “内容过滤” 环节与 “向量检索” 环节之间的状态同步失效。
数据流隔离的核心工程参数
针对此类 LLM 应用的数据泄露风险，企业应从以下四个工程维度构建防护体系。首先是上下文范围控制参数：限制 LLM 可检索的文档来源目录，将 Sent Items、Drafts 等高风险文件夹明确排除在 Copilot 索引范围之外，并通过配置策略强制执行。其次是标签过滤前置阈值：在数据进入向量数据库前部署预过滤层，检查每条元数据的敏感标签属性，只有当标签标记为 “公开” 或 “内部” 且无加密需求时，才允许进入检索候选集。第三是会话级别数据隔离超时：为每个用户会话设置独立的数据隔离上下文，超时时间建议不超过 30 分钟，会话结束后立即清除临时缓存的敏感数据指针。第四是审计日志粒度：将每次 LLM 调用的输入上下文完整记录，包括被排除的文档 ID、排除原因、敏感标签匹配结果等，确保事后可追溯。
监控告警的关键阈值与回滚策略
除了配置层面的防护，持续监控同样不可或缺。建议设置以下告警阈值：当单次请求中涉及机密标签文档数量超过阈值（如 1 封）时自动阻断请求并告警；当 Copilot 响应中出现与用户最近 7 天内发送的邮件高度匹配的文本片段（相似度超过 85%）时触发数据泄露预警；同时监控 Sent Items 和 Drafts 文件夹的访问日志，异常访问模式应立即触发安全审查。
对于已部署的 Copilot 功能，建议设置紧急回滚机制：一旦检测到类似漏洞利用特征，可通过管理后台一键禁用 Copilot 对邮件箱的访问权限，将功能降级为仅支持文档协作场景。回滚操作应在 5 分钟内完成全 tenant 生效，确保风险控制在窗口期内。
企业部署建议清单
综合此次漏洞的教训，企业在部署任何企业级 LLM 助手时，应遵循以下基线要求：敏感标签与 DLP 策略必须在应用层实现端到端强制执行，而非仅依赖网络层或身份层的控制；所有进入 LLM 上下文的文档必须经过预过滤管道，且过滤规则应与安全团队的标签体系保持实时同步；建立 LLM 专用审计日志体系，记录每次推理的完整输入上下文；制定明确的应急响应流程，包括漏洞披露后的快速回滚能力。
此次微软 Copilot 邮件摘要漏洞为企业敲响了警钟：在追求 AI 生产力提升的同时，必须同步构建与之匹配的数据流隔离工程能力。唯有将安全控制嵌入 AI 应用的数据处理管道，而非仅停留在策略层面，才能真正遏制类似非预期数据泄露的再次发生。
资料来源：BleepingComputer 报道（https://bleepingcomputer.com/news/microsoft/microsoft-says-bug-causes-copilot-to-summarize-confidential-emails/）