微软撤回Copilot域名黑名单

上线一周即回滚，已有权限也会被收回

微软已经撤回 Microsoft 365 Copilot 的“域名排除”（Domain Exclusion）功能，企业 IT 管理员刚拿到手的网页来源过滤能力随之消失。

据微软最新公告及 8 月 5 日曝光的消息，这项功能于 2026 年 7 月 29 日开始推出，但上线仅一周便被回滚。微软不仅停止向更多租户推送该功能，已经获得相关能力的管理员也将失去配置权限，而不是保留现有设置继续使用。

**域名排除是允许管理员阻止 Copilot 引用指定外部网站的来源控制机制。**按照原定方案，管理员可以通过 PowerShell 脚本配置最多 1000 个域名，限制 Microsoft 365 Copilot 在检索网络信息、组织答案和生成引用时使用这些来源。

微软目前没有解释具体撤回原因，只表示正在“积极评估下一步”，并将在适当时候分享更多信息。这个表态意味着 Domain Exclusion 更像是暂时回炉，而非永久取消，但微软也没有承诺重新上线的时间、交付形式或替代方案。

这次回滚值得关注，并不是因为企业少了一个普通设置项，而是因为它暴露出 Microsoft 365 Copilot 在“能否访问网页”和“可以信任哪些网页”之间仍有明显的管理缺口。

域名排除控制的不是企业数据，而是外部来源

域名排除解决的是 Copilot 的网络信息来源问题，而不是 SharePoint、OneDrive、Teams 或 Outlook 中的内部权限问题。

Microsoft 365 Copilot 的回答通常可能结合两类信息：一类来自组织内部的 Microsoft Graph 和用户有权访问的工作数据，另一类来自公开网络搜索或网页内容。Domain Exclusion 针对的是后者，作用类似于在企业级 AI 搜索入口前设置一张“禁止引用的网站清单”。

这个区别很重要。撤回功能不等于 Copilot 突然越过现有 Microsoft 365 权限读取企业文件，也不意味着管理员完全失去了 Copilot 的启停、用户分配和合规管理能力；它意味着管理员无法再通过这项新功能，精确阻止 Copilot 使用某些外部域名作为答案依据。

| 控制对象 | Domain Exclusion 原计划能力 | 回滚后的状态 | 是否影响内部文件权限 | |---|---|---|---| | 外部网页域名 | 最多排除 1000 个域名 | 功能停止推送，已有权限被收回 | 否 | | Copilot 应用访问 | 不属于该功能范围 | 仍可通过 Microsoft 365 管理中心控制 | 否 | | 用户或群组范围 | 不负责许可证和应用分配 | 现有租户级、用户级及群组级控制仍可用 | 否 | | 提示与回答记录 | 不负责保存和审计 | 仍可结合 Microsoft Purview 管理 | 否 | | SharePoint、OneDrive 权限 | 不修改原始访问控制 | 继续沿用 Microsoft 365 权限体系 | 否 |

企业真正失去的是一层“回答来源治理”。如果一家金融机构认为某些投资论坛不适合作为研究材料，医疗企业不希望 Copilot 引用缺乏审核的健康网站，或者法务团队要求屏蔽一批未经授权的法规聚合站，Domain Exclusion 原本可以提供统一的租户级限制。

没有这层控制，员工仍可能在答案中看到这些公开来源，只能依赖 Copilot 自身的搜索排序、安全分类器和引用机制进行筛选。对于普通用户，这可能只是答案质量问题；对于受监管企业，它可能进一步变成审计、声誉和决策责任问题。

1000 个黑名单名额，看起来不少，实际上很快不够用

微软采用的是排除列表，也就是典型的黑名单模型，而企业管理员的主要质疑恰恰集中在这种设计上。

**黑名单是默认允许所有来源，仅阻止已知风险对象的控制策略。**管理员必须先发现一个网站存在低质量内容、恶意提示注入、版权风险或合规问题，再把它加入排除列表。这是一种追赶式治理：风险域名不断出现，管理团队则不断补名单。

**白名单是默认拒绝未知来源，仅允许经过审核对象的控制策略。**对于网站数量有限、来源标准明确的企业场景，白名单通常更符合“最小权限”原则，因为管理员只需要维护可信来源，而不是试图列举整个互联网中不可信的部分。

两种方案的差异不只是操作习惯，而是完全不同的风险假设。

| 维度 | 域名黑名单 | 域名白名单 | |---|---|---| | 默认策略 | 未列出的来源均可使用 | 未列出的来源均不可使用 | | 管理目标 | 持续发现并封禁坏来源 | 审核并维护可信来源 | | 对开放网络的兼容性 | 高 | 低 | | 对强合规行业的适配度 | 一般 | 较高 | | 面对新注册恶意域名 | 容易漏过 | 默认拦截 | | 维护压力 | 随风险来源增加而增长 | 随可信来源数量增加而增长 | | 对答案覆盖面的影响 | 较小 | 可能明显缩窄 |

1000 个域名的上限对于小型组织可能够用，但对全球化企业、安全团队和拥有大量子品牌的集团并不宽裕。垃圾内容站点、镜像站、聚合站和临时域名可以快速更换，单纯封禁顶级域名也可能误伤同一平台上的正常内容。

黑名单还会遇到域名粒度问题。管理员究竟是在排除整个主域名、某个子域名，还是具体路径？如果只支持域名，控制可能过于粗糙；如果允许复杂通配符，配置、测试和审计成本又会迅速上升。微软此前公开信息只强调最多配置 1000 个排除域名，并没有给出足够清晰的策略继承、冲突处理和命中日志能力。

因此，管理员反对的未必是“屏蔽网站”本身，而是微软交付了一套更接近消费级内容过滤的黑名单，却把持续追踪外部风险的运营成本留给企业客户。

回滚的真正问题，是微软没有同步给出替代控制

微软快速听取反馈并撤回设计不成熟的功能，本身不算坏事，但直接收回已交付权限并留下能力真空，并不是理想的企业软件发布方式。

企业功能和个人产品功能的最大区别，是管理员会围绕它建立流程。即便 Domain Exclusion 只上线一周，也可能已经有组织完成测试、编写 PowerShell 配置、整理风险域名，甚至把它写入 Copilot 上线检查表。现在权限被收回，这些工作无法继续落地。

微软如果只是认为黑名单不够好，更合理的做法应该是保留现有功能并标记为预览，同时增加白名单、策略分组、审计日志和模拟模式，而不是让管理员重新回到“要么允许联网来源，要么从更高层面限制 Copilot”的粗粒度选择。

**模拟模式是只记录策略可能拦截的请求、但暂时不真正阻止内容的部署方式。**这种能力在企业安全产品中很常见，可以帮助管理员评估某条规则会影响多少用户和回答，再决定是否正式启用。对 AI 来源过滤来说，模拟模式尤其重要，因为过严的规则可能让 Copilot 无法找到足够材料，过松的规则又起不到治理效果。

更完整的企业级方案至少应该包含以下能力：

• 支持黑名单与白名单两种策略，并允许按业务部门选择；
• 支持主域名、子域名和必要的通配规则，同时明确匹配优先级；
• 提供策略命中日志，记录哪个回答跳过了哪个来源；
• 提供模拟模式，先评估规则对答案覆盖率的影响；
• 支持按用户、群组、地区和 Copilot 使用场景分配策略；
• 区分“禁止检索”“禁止引用”和“允许读取但降低排序权重”；
• 对被拦截来源给出可审计原因，而不是只让用户看到搜索结果减少；
• 提供可扩展的数量上限，避免大型组织被固定的 1000 条规则卡住。

其中，“禁止检索”和“禁止引用”也不是一回事。前者意味着 Copilot 不应抓取或处理该来源，后者可能只是不在最终答案中展示或依赖该来源。如果微软没有把这些语义讲清楚，企业很难判断控制能否满足版权、隐私和监管要求。

现有安全机制不能完全替代来源过滤

Microsoft 365 Copilot 现有的隐私与安全能力仍然有效，但它们与域名排除解决的不是同一层问题。

微软官方文档显示，Microsoft 365 Copilot 会使用相关分类器缓解越狱攻击和跨提示注入攻击，也提供受保护材料检测。不过，微软同时提醒，这些检测与缓解措施并不一定覆盖所有 Copilot 场景。分类器更像机场安检，用于识别高风险输入；域名策略则更像企业差旅名单，决定员工原则上可以从哪些目的地获取信息。

**跨提示注入攻击是攻击者把恶意指令隐藏在网页或文档中，诱导 AI 忽略原有规则或执行非预期行为的攻击方式。**当 Copilot 检索外部网页时，来源是否可信会直接影响这类风险。模型侧分类器可以降低风险，但无法替代管理员基于行业和组织规则作出的来源判断。

微软也允许管理员通过 Microsoft 365 管理中心的集成应用入口，按租户、用户或群组控制 Copilot 应用访问；通过 Microsoft Purview，管理员还可以管理 Copilot 交互内容的搜索、保留和合规策略。这些能力分别解决“谁能使用”和“使用后如何审计”，却不能细化到“Copilot 可以引用哪些网站”。

| 管理能力 | 解决的问题 | 能否替代域名过滤 | |---|---|---| | Copilot 应用访问控制 | 哪些用户或群组可以使用 Copilot | 不能，粒度过粗 | | Microsoft 365 原有权限 | 用户可以访问哪些内部文件 | 不能，不管理公开网页 | | Microsoft Purview | 交互记录、保留、搜索与合规 | 不能，主要是事后治理 | | 安全分类器 | 识别越狱和提示注入风险 | 不能，属于模型侧风险缓解 | | 网页引用 | 告诉用户答案参考了哪些来源 | 不能，透明度不等于预防 | | Domain Exclusion | 阻止指定外部域名成为信息来源 | 本次已被撤回 |

管理员现在可以做的，是重新检查 Copilot 的网络访问场景、加强用户培训、监控回答引用，并在高风险工作流中要求人工核验来源。但这些措施都需要更多人工参与，无法等价替代租户级来源策略。

对微软而言，这是一次典型的企业 AI 产品管理失误

微软的问题不是做了黑名单，而是把黑名单当作足够完整的企业来源治理方案推出，又在一周后突然收回。

从产品判断看，黑名单适合开放式搜索，因为它可以保留网络覆盖面；白名单适合监管严格、知识来源明确的组织，因为它可以把不确定性压到最低。Microsoft 365 Copilot 面向的客户横跨普通公司、政府、金融、医疗和教育机构，只提供其中一种模式，本来就难以满足全部需求。

微软可能还面临另一个现实难题：白名单会显著削弱 Copilot 的搜索体验。如果管理员只批准几十个网站，用户可能频繁得到“缺少足够信息”的答案，随后把问题归咎于 Copilot 能力不足。黑名单则更容易维持回答覆盖率，也更符合搜索产品默认开放的逻辑。这可能解释微软最初为何选择排除列表，但不能解释其为何没有准备更灵活的策略层。

此次回滚也说明，企业 AI 的竞争正在从模型能力转向控制面。模型能否写邮件、总结会议和生成演示文稿已经不是唯一标准，管理员更关心权限边界、来源可信度、审计记录、策略分配和故障责任。谁能提供更细粒度且可验证的控制，谁才更容易进入高合规组织的核心工作流。

管理员现在应该做什么

企业不应假设已配置的排除规则会继续生效，而应把 Domain Exclusion 视为当前不可用功能。

第一，管理员应确认租户中是否曾获得该功能，并记录已经整理的域名列表、业务理由和责任部门。即使微软未来改为白名单或混合策略，这批数据仍可以作为来源风险库使用。

第二，安全团队应区分内部数据权限与外部网页来源风险，避免把本次回滚误解为 Microsoft 365 权限模型失效。现有 SharePoint、OneDrive、Teams 和 Outlook 权限仍应继续审计，尤其要处理历史遗留的过度共享问题。

第三，高风险部门应建立人工引用核验规则。法务、财务、医疗和战略研究人员不能因为回答带有链接，就默认链接内容可靠；“可追溯”只代表用户能看到来源，不代表来源已经通过企业审核。

第四，采购和治理团队应向微软明确提出白名单、策略日志和按群组分配等需求。微软表示正在评估下一步，企业客户现在的反馈很可能直接影响重新设计后的功能形态。

结论：撤回可以理解，控制真空不能长期存在

微软撤回 Domain Exclusion 的决定短期内避免了一套维护成本高、上限仅 1000 个域名的黑名单机制被固化，但也让 Microsoft 365 Copilot 暂时失去了关键的网页来源治理能力。

对大多数普通企业，影响可能只是少了一个过滤低质量网站的工具；对金融、医疗、政府和法律行业，影响则是管理员无法用统一策略定义 Copilot 可以信任的外部信息边界。这不是模型回答好不好看的问题，而是企业能否对 AI 的证据链负责。

更合理的下一步不是简单恢复原功能，而是同时提供黑名单、白名单、模拟模式、命中日志和分组策略。微软若只把同一套 1000 域名排除列表重新上线，这次回滚就只是延期；只有把来源治理做成真正的企业控制面，这一周的产品反复才算有价值。

参考来源

• IT之家：上线仅 1 周，微软撤回 M365 Copilot 的“AI 引用黑名单”功能——整理了 Domain Exclusion 的上线时间、1000 个域名上限、回滚范围及管理员对白名单模式的反馈。