Microsoft Ignite 2026 的 Agent 安全发布，企业该如何复核？

症状：你看到 Agent 安全功能的演示或发布说明，却不确定它是否适用于自己的生产部署。
最快解法：先核验功能状态和适用范围，再用身份权限、数据路径、网络隔离与日志证据逐项测试；没有可复核证据的控制，不作为生产放行依据。

企业安全负责人，可用本文整理 Agent 安全复核项。
身份与平台管理员，可据此检查访问控制和部署边界。
Agent 开发者，可按步骤准备上线前的测试证据。

最后更新于 2026 年 10 月 5 日；日期核对自 Microsoft Ignite 官方活动页面，控制项核对自微软产品与安全文档。 官方活动页面列出的 Microsoft Ignite 2026 日期为 11 月 17—20 日，因此截至本文更新时活动尚未举行，不能把会后公告当成已确认信息。(Microsoft Ignite 官方活动页面)

先核对发布状态：Microsoft Ignite 2026 Agent 安全能力能否算正式可用？

截至目前，不能据此确认任何一项“由 Microsoft Ignite 2026 发布”的 Agent 安全能力已经正式推出。你可以查微软现有产品文档，但应把它们与 Ignite 现场演示、会前预览或媒体报道分开记录；会前产品资料能说明当前文档描述的控制，不等于活动公告，更不等于你租户中已经启用并验证的配置。

做判定时，可用下表把宣传信息转成发布证据：

例如，微软现有的 Microsoft Entra Agent ID 更新说明可用于核对该产品本身的发布状态，但不能单独证明 Ignite 2026 发布了某项新能力。对照时，记录文档标注的状态、适用产品、所需许可证或配置，以及你在哪个租户、哪个部署中复测过。

怎样确认 Agent 身份和权限符合最小权限？

企业 Agent 权限治理的起点，是让每次资源访问都能对应到一个明确的 Agent 身份或服务主体，并说清谁负责它、它为何需要该权限。不要假定不同托管方式使用同一种身份模型：微软文档分别说明了 Agent 身份与传统应用服务主体等模式，具体可追踪性和授权路径需要按实际类型核对。Agent 身份与服务主体说明也指出，授权可使用应用权限或委派权限两种模式；二者代表的访问情境不同，不能只看权限名称就判断风险。

实际复核时，打开权限清单，对每一项记录对应资源、操作范围、授权主体、业务用途和负责人。检查是否有组织范围过宽的授权、长期不用的权限，或用个人账号、共享凭据掩盖 Agent 实际身份的情况。再把 Agent 的实际工具调用与批准的资源列表对照；无法解释的授权先收紧，无法识别调用主体则不放行。

微软的Agent 身份治理最佳实践可作为检查基线。若你使用的是其他托管方式或自建身份机制，应回到该产品的身份文档和租户记录，单独验证令牌中的主体、权限授予方式与撤销路径，不能把 Entra 的能力直接套用到所有 Agent。

Agent 调用外部工具前，先画清哪些数据边界？

不要只检查 Agent 的提示词或最终回答。先把一次任务拆成输入、检索、工具调用、外部服务处理、输出与留存，标出每个环节传出的数据、接收方、授权方式和保存位置。外部服务的处理条款、保留政策和数据地域如果尚未确认，就把该工具列为上线阻断项，不要用“应该不会留存”代替证据。

对每条数据路径，逐项回答：是否含个人信息、客户内容、凭据或内部文档；发送前是否会脱敏或筛除；外部服务是否保存请求与结果；谁能访问其日志；数据会在哪些地域处理；删除请求如何执行。把无法回答的问题交给相应服务负责人确认，并保存文档或合同条款的版本记录。

在 Microsoft Foundry 场景中，数据、隐私与安全文档描述了服务处理的数据及部分存储和处理边界；使用 Copilot Studio 时，可参照Agent 数据策略文档检查连接器和数据策略执行情况。这些文档只适用于相应产品，不代表其他外部工具已经满足你的组织要求。

注意：把一次“调用成功”当成唯一验收结果，会漏掉越权或数据外流。你还要用不应被允许的资源或工具做拒绝测试，并保存拒绝结果。

如何验证网络隔离不是只停留在架构图上？

平台支持某种网络模式，不等于你的 Agent 已经运行在该边界内。按照所选托管方式，核对入口、出站路径、工具与数据资源的连接方式、DNS 和防火墙规则，再从实际运行环境发起连接测试。确认哪些目的地址必须放行、哪些应被拒绝，并检查策略变更后结果是否仍符合预期。

以 Foundry 为例，网络选项文档区分了公共出站、用户自有虚拟网络和托管虚拟网络等部署选择，也说明仅限制入口不等于隔离出站。你应把文档描述的能力与本组织实际的网络配置分开留证：部署模板或架构图说明“计划怎样做”，路由、防火墙配置和实测结果才说明“当前怎样运行”。

对每个允许访问的外部地址，记录用途、负责人和批准依据；对不在清单内的目的地址，尝试调用并确认连接被阻断。若网络测试仍无法确认实际出站边界，先关闭相关工具或暂缓上线，而不是以“平台支持隔离”推定隔离已生效。

用一组正反测试确认日志能否支持审计

Agent 安全复核要确认的不只是日志开关，而是事件是否可查询、内容是否足够、谁有权查看、保留多久，以及能否关联到具体 Agent、操作者和工具。检查日志可能包含的提示词、模型输入输出、工具调用和中间步骤，因为这些记录本身也可能含有客户内容或敏感信息。

微软的Foundry 跟踪数据说明提醒，跟踪记录可能包含用户输入、Agent 与模型交互、工具调用及执行元数据；访问范围和留存受关联的监控资源配置影响。Copilot Studio 的安全与治理文档则说明了该产品相关的审计与治理机制。两者产品机制不同，复核时不要把某个控制台中的日志视图当成全平台审计记录。

用一条正常调用和一条预期应被拒绝的调用做样例，逐一确认：

• 日志能否识别 Agent、操作者或授权主体，以及关联的会话或请求。
• 是否记录工具调用、目标资源、授权结果和失败原因。
• 负责调查的人是否有查询权限，权限是否过宽。
• 留存期限、删除流程和数据访问审批是否符合组织政策。
• 调查人员能否用这些记录重建事件顺序，同时避免日志本身暴露秘密。

如果成功调用有记录而拒绝调用没有可查结果，或日志中无法区分 Agent 与人工用户，就先修复审计链路，再讨论生产放行。

按复核结果决定放行、限制还是暂缓

把结论分成三类，不必虚构风险评分：

• 可补测：控制设计和配置已有依据，只缺一次可重复的测试。指定负责人、测试条件和复核期限；完成后再转为放行评审。
• 需收紧权限：身份可追踪，但授权过宽、数据路径不必要或日志读取范围过大。先撤销或缩小授权，再重跑正反测试。
• 必须暂缓：Agent 身份无法辨认、敏感数据去向不明、预期的网络隔离未验证，或审计记录不足以调查。没有补齐证据之前，不让它接触生产数据或高影响操作。

你的评审记录至少应写明：Agent 名称与托管方式、功能发布状态及依据、身份和权限清单、数据路径与外部服务条款、网络测试结果、日志查询与留存设置、未解决事项及负责人、最终决定和批准人。若你在临时 Mac 环境中复现客户端或网络行为，可先通过 Kvmkit 帮助中心了解环境操作方式；具体服务条款也应纳入采购评估。环境测试结果只能证明该次复现，不能替代 Microsoft 租户中的身份、网络与审计证据。

如果当前方案依赖个人电脑手工操作、临时账号和分散截图，权限边界难复现，执行环境也难保持一致，审计材料还容易留在不受控设备上。对需要短期验证 Mac 客户端兼容性或执行链路的团队，租赁 Kvmkit 的 Mac 可作为独立测试环境选项；但它不能取代 Agent 的身份治理、网络策略或生产日志审计。先完成上述核对，再决定是否需要单独准备这类测试节点。