Microsoft Entra ID 本周发布了两项重要更新：来自 Identiverse 2026 的关于企业环境中 AI 代理蔓延的惊人发现，以及与 SAP 身份系统的深化集成，将 Entra ID Governance 定位为 SAP Identity Management 的战略继任者。这两项公告对在 AI 时代管理身份的 IT 管理员具有重大意义。
AI 代理无处不在：Identiverse 2026 圆桌洞察
在 Identiverse 2026 上，Microsoft Security 举办了一场 Power Breakfast，汇聚了来自 10 个同时进行的圆桌讨论的 150 位身份专业人士。参与者来自金融服务、医疗保健、政府和能源等行业，代表了 AI 采用的各个阶段。调查结果描绘了 AI 代理治理现状的严峻画面。
代理蔓延是当前现实
十个圆桌中有九个将未经管理的代理蔓延描述为当前现实，而非未来风险。从几十个代理开始，在几个月甚至几周内就变成了数万个。一位参与者报告说在演示期间意外发现其企业租户中有 44,000 个代理。没有任何单一审计能够捕获全貌，从业者在最终检查时发现的代理数量远超预期。
影子 AI 和无主代理
十个圆桌中有八个表示，影子 AI 已经存在于其组织中，运行在没有任何单一治理层覆盖的平台上。这些代理仅通过网络日志进行跟踪（如果有的话）。十个圆桌中有九个提出了无主代理问题：代理被创建后绑定到创建者的身份，在该人调岗或离职后很长时间仍在运行——未经审查、权限过大且未被发现。
代理到代理链：最困难的挑战
十个圆桌中有八个将代理到代理链确定为遇到的最困难的安全挑战。多个团队在发现无法在链中维护一致的治理后，回滚了代理到代理部署。正如一位参与者所指出的：“我能控制从 A 点到 B 点，但 B 点需要与 C 点通信，这就是上下文丢失的地方。”
三个可行的起点
Microsoft 概述了组织应对代理蔓延的三个实用步骤：
1. 首先建立清单。 在 Microsoft Entra 管理中心的 Entra ID > 代理 > 代理概览中开始，查看具有身份的代理总数、最近创建的数量、活跃数量和未管理数量。对于在 Microsoft 生态系统之外运行的代理，使用 Agent 365 CLI 和 SDK 或联合身份凭据进行注册。您不需要迁移它们——您需要将它们纳入注册表，使其可见并可以被治理。
2. 为每个代理分配所有者和赞助者。 Microsoft Entra Agent ID 中的每个代理身份都需要一个赞助者（对代理行为负责的人）和一个所有者（负责其技术管理的人）。在创建时在蓝图层分配两者。当有人离开组织时，Microsoft Entra 生命周期工作流可以自动为与该人关联的每个代理触发所有权审查。
3. 严格限定权限并在蓝图级别应用条件访问。 在每个蓝图上使用枚举范围：仅限代理需要的特定委派权限，不多不少。对于代表用户行事的代理，使用代表流程，以便应用用户级访问策略。对于自主代理，使用 narrowly scoped 的客户端凭据流程。在蓝图级别应用条件访问策略——而非逐个代理——以便从该蓝图创建的每个代理实例自动继承策略。
许可注意事项
从 2026 年 7 月开始，包括代理特定条件访问和身份保护在内的代理安全功能需要 Microsoft 365 Agent 或 M365 E7 许可证。组织应确认其租户拥有 Agent 365 合格的许可证，并且所需管理员已分配许可证。应启用 Microsoft Defender 中的 Security for AI Agents 开关，SOC 团队应将 Advanced Hunting 查询从旧版 AIAgentInfo 表更新到新的 AgentInfo 表。
使用 Microsoft Entra 现代 SAP 身份管理
7 月 23 日，Microsoft 发布了关于使用 Microsoft Entra 现代 SAP 身份管理的详细指南，面向从 SAP Identity Management (SAP IDM) 向云原生身份平台过渡的组织。
深化集成能力
在过去两年中，Microsoft Entra 和 SAP 持续深化互操作性。关键更新包括：
- 更灵活的预配模式，在 Microsoft Entra 和 SAP Cloud Identity Services 之间支持更广泛的部署模型
- Microsoft Entra 用户上的自定义扩展属性，用于 SAP 特定场景，使身份数据更易于与 SAP 应用程序需求对齐
- 账户发现，用于识别 SAP Cloud Identity Services 中尚未与 Microsoft Entra 用户关联的账户，减少手动调查并加强治理
- OAuth 2.0 客户端凭据支持，保护 Microsoft Entra 和 SAP Cloud Identity Services 之间的服务到服务通信，取代较旧且较不安全的身份验证方法
- Entra ID Governance 与 SAP Identity Access Governance (IAG) 之间的集成，允许组织通过 Entra 访问包请求和治理 SAP 业务角色以及其他访问权限
SAP IAG 集成的工作方式
当用户通过 Microsoft Entra 请求分配包含 SAP 业务角色的访问包时，请求会自动发送到 SAP Identity Access Governance。SAP IAG 然后在其自己的治理流程中执行审批和额外检查。这种方法将 Entra 中的企业级访问包与 SAP IAG 中可用的业务角色和风险上下文连接起来，创建跨 SAP 和非 SAP 应用程序的统一治理体验。
客户成功：Cenibra
纤维素公司 Cenibra 使用 Microsoft Entra ID Governance 在 80 多个系统（包括 SAP 作为核心平台）中实现了身份管理现代化。该方法帮助减少了手动工作、提高了审计就绪性，并创建了更具可扩展性的访问管理基础——证明了 Entra-SAP 集成对复杂企业环境的实际价值。
SAP 的更广泛 Microsoft 安全上下文
身份为在您的安全环境中保护 SAP 奠定了基础。Microsoft 提供与 NIST 网络安全框架对齐的额外 SAP 感知能力：
- 识别： Microsoft Purview 发现并分类敏感 SAP 数据，包括通过 SAP Datasphere 镜像到 Microsoft Fabric 的数据
- 保护： Microsoft Defender 保护 SAP 应用程序周围的端点、服务器和云资源
- 检测： Microsoft Sentinel 连接 SAP 信号以检测事件，具有 SAP 认证解决方案中的内置分析规则
- 响应： Microsoft Security Copilot 加速调查并指导 SAP 事件的响应
SAP IDM 迁移建议行动
对于评估其 SAP 身份策略的组织，Microsoft 建议采用分阶段方法：
- 执行 SAP 身份景观评估 — 清点哪些 SAP 系统在范围内、SAP IDM 当前管理什么，以及识别为 SAP IDM 提供数据的权威来源
- 设计 Entra-SAP 集成模型 — 将 SAP 身份属性映射到 Entra 扩展属性，规划账户发现和核对，并配置 OAuth 2.0 客户端凭据
- 集成 Entra ID Governance 与 SAP IAG — 在 Entra 中建立触发 SAP IAG 角色分配的访问请求工作流，并定义平台之间的职责划分
- 规划 SAP IDM 迁移和退役 — 从共存开始（Entra 编排，SAP IDM 执行），过渡到渐进式切换（新预配仅通过 Entra + SAP IAG），最后完成退役
- 与更广泛的 Entra 和 AI 安全计划对齐 — 将零信任原则应用于 SAP 访问，将 SAP 集成服务账户作为工作负载身份治理，并将 SAP 用户视为与 AI 代理和 SaaS 应用相同的身份边界的一部分
这对您的组织意味着什么
这两项公告反映了 Microsoft 的更广泛战略：使每个身份——无论是人类、AI 代理还是 SAP 服务账户——成为 Entra 身份结构中一等一的、可治理的实体。对于 IT 管理员来说，信息很明确：管理 AI 代理蔓延和现代 SAP IDM 等遗留 IAM 系统的工具现在已经可用，不采取行动的代价每个月都在增长。
如果您的组织正在部署没有治理的 AI 代理，请立即从 Entra 管理中心中的清单开始。如果您正在运行 SAP IDM，请在 SAP 于 2026 年 11 月弃用 SuccessFactors API 的基本身份验证之前，开始规划到 Entra ID Governance 的迁移路径。
在 https://x.com/kkaminsk 上关注对话，获取 Microsoft Entra ID 更新和身份安全洞察的持续报道。