Microsoft Entra 代理 ID 中的授权

代理标识的引入是由组织中 AI 支持的代理的兴起推动的。 传统标识类型（如标准应用注册或用户帐户）不适合自治代理。 AI 代理具有独特的安全问题，因为它们的自主决策、动态学习功能以及可能访问敏感数据可能会引入不可预知的行为。

Microsoft 已创建 Entra Agent ID 以填补此空白。 它基于 Microsoft Entra ID 平台构建，为 AI 代理提供专用的身份验证和授权框架，使他们能够安全地访问服务和 API，同时为管理员提供监视和控制其作的中心方式。 简言之，代理标识允许组织发现、管理和保护租户中运行的 AI 代理，并实施适当的策略，而不是将代理视为完全用户或通用应用。

本文解释了 AI 代理在 Microsoft Entra 代理 ID 中的授权机制，提供了关于角色、权限控制以及管理代理访问的最佳实践的信息。

代理标识授权为何很重要

AI 代理可以快速大规模地执行任务。 Microsoft Entra ID 中的许多高特权功能（例如管理用户或角色的能力）假定由谨慎操作的人工管理员执行。 具有高特权的未训练代理可能会执行影响深远的意外管理任务（例如删除用户或更改安全设置）。

因此，Microsoft Entra ID 限制代理标识能够执行的操作。 例如，Microsoft Entra 阻止代理被授予许多高特权角色或权限。 不允许用户和管理员同意代理的那些强大权限。 此设计可识别代理应以最低权限运行。 通过防止代理接收敏感权限，系统可最大程度地降低 AI 代理可能会升级访问的风险。 允许的角色和权限列表会随着时间推移而变化。

Microsoft代理标识的 Entra 角色分配

从授权的角度来看，代理标识的行为有点像应用程序或具有额外安全措施的用户。 每个代理标识都有一个服务主体或是 Microsoft Entra ID 中的一个用户，并且可以被分配某些 Microsoft Entra 角色。

例如，可以为代理的标识分配Microsoft Entra角色来给它分配管理员权限，但许多高特权目录角色被阻止用于代理。 无法将全局管理员、特权角色管理员或用户管理员等角色分配给代理标识。 只能将特权较低的角色（例如阅读者角色）分配给代理。 无法将任何自定义角色分配给代理标识。 此外，代理标识不能是可分配角色的组的成员。

Microsoft已创建代理 ID 管理员和代理 ID 开发人员角色，用于自行管理和创建代理。

适用于代理的 Microsoft Entra 角色

以下是可以分配给代理身份的 Microsoft Entra 角色列表：

• AI 管理员
• 攻击有效负载作者
• 攻击模拟管理员
• 属性分配读取者
• 属性定义读取者
• 属性日志管理员
• 属性日志读取者
• Azure DevOps 管理员
• Azure 信息保护管理员
• B2C IEF 策略管理员
• 计费管理员
• Cloud App Security 管理员
• 合规性管理员
• 合规性数据管理员
• 客户密码箱访问审批者
• 桌面分析管理员
• 目录读取器
• 目录同步帐户
• Dynamics 365 管理员
• Dynamics 365 Business Central 管理员
• Microsoft Edge 管理员
• Exchange 管理员
• Exchange 收件人管理员
• 扩展目录用户管理员
• 外部 ID 用户流管理员
• 外部 ID 用户流属性管理员
• Fabric 管理员
• 全球阅读器
• 全局安全访问日志读取器
• Insights 管理员
• 见解分析师
• Insights 业务主管
• IoT 设备管理员
• Kaizala 管理员
• 知识管理员
• 知识管理器
• 许可证管理员
• 消息中心隐私读取者
• 消息中心读取者
• Microsoft 365 备份管理员
• Microsoft 365 迁移管理员
• Microsoft Entra 联接设备本地管理员
• Microsoft Graph 数据连接管理员
• Microsoft 硬件保修管理员
• Microsoft 硬件保修专家
• 网络管理员
• Office 应用管理员
• 组织品牌打造管理员
• 组织数据源管理员
• 组织消息审批者
• 组织消息编写者
• 人员管理员
• 放置管理员
• Power Platform 管理员
• 打印机管理员
• 打印机技术人员
• 报告读取者
• 搜索管理员
• 搜索编辑器
• 服务支持管理员
• SharePoint 管理员
• SharePoint Embedded 管理员
• Skype for Business 管理员
• Teams 管理员
• Teams 通信管理员
• Teams 通信支持工程师
• Teams 通信支持专员
• Teams 设备管理员
• Teams 阅读器
• Teams 电话服务管理员
• 租户创建者
• 使用情况摘要报表读取者
• 用户体验成功管理器
• Virtual Visits 管理员
• Viva Glint租户管理员
• Viva Goals 管理员
• Viva Pulse 管理员
• Windows 365 管理员
• Windows 更新部署管理员
• Yammer 管理员

Microsoft Graph 权限用于代理身份标识

对于 OAuth2 权限，代理 ID（特别是代理标识蓝图和代理标识蓝图主体）可以使用与其他应用相同的 Microsoft Graph 权限模型。 代理可以请求委托的权限（通过许可代表用户执行）或应用程序权限（管理员授予的仅限应用的权限）。

但是，对于代理，显式阻止了一组高风险Microsoft图形 API 权限。 例如，无法向代理授予以下权限：

代理 ID 仍可根据需要授予较低权限。 例如，如果代理需要代表该用户读取用户的邮箱或 OneDrive 文件，则可以请求诸如 Mail.Read 或 Files.Read 的委托权限，并且用户（或管理员）可以同意。 那些在整个租户的范围内不被视为高特权；它们仅限于该用户的数据。

被阻止的是超出单个用户权限或涉及管理控制的租户范围的特权。 代理在有限范围原则下运行。 代理只能执行常规用户可以同意的内容，或者管理员以受控的作用域方式显式授予的内容。

何时使用 Azure 角色、Microsoft Entra 角色或Microsoft Graph 权限

根据代理需要执行的作，管理员可以以不同的方式授予访问权限，以保持适当的范围。 这包括分配 Azure 角色、Microsoft Entra 身份角色、OAuth 权限授予（包括 Graph 权限）、应用程序角色分配、访问包分配和组成员资格。

Azure 角色

如果代理需要访问 Azure 资源：为这些特定资源分配 Azure 角色。 例如，若要让代理读取 Azure Key Vault，请在该保管库上为其身份提供 Key Vault 阅读者角色。 这会缩小范围（仅该资源或资源组），并使用最小特权。 有关详细信息，请参阅使用 Azure 门户分配 Azure 角色。

Microsoft Entra 角色

如果代理需要执行目录级作：仅当存在合适的较低特权角色时，才使用 Microsoft Entra 角色。 例如，如果代理只需要读取基本目录信息，则可以使用目录读取者类型角色。 如果需要授予代理写权限，请查看可能的影响并选择权限最少的角色。 可能没有未受阻止的适当内置角色。 在这些情况下，您可以选择依赖 Microsoft Graph 权限（了解其限制条件）。 有关详细信息，请参阅分配 Microsoft Entra 角色。

委派的 Microsoft Graph 权限

如果代理人代表用户（以用户为中心的场景）进行操作：使用委派 Microsoft Graph 权限。 此选项需要交互式用户同意，但确保代理不能超过该用户的访问权限。 例如，为 Alice 安排会议的代理将使用委派日历 API 权限。Alice 同意后，代理只能管理 Alice 的日历（就像 Alice 自己可以做到的一样）。 有关详细信息，请参阅 Microsoft标识平台中的权限和同意概述。

Microsoft Graph 应用程序权限

如果代理在租户（服务方案）中自主运行：请谨慎使用 Microsoft Graph 应用程序权限。 仅在这些权限不是高权限的情况下授予所需的特定应用权限。 例如，生成组织结构图的代理可能需要 User.Read.All 应用权限来读取所有用户个人资料，这可能是可接受的（且不在被阻止列表中），而 User.ReadWrite.All 将被拒绝。

始终查看权限的范围：租户范围的读取权限可能适用于某些数据，但不允许代理使用租户范围的写入或控制权限。 管理员必须显式同意代理获得的任何应用权限，因此有机会仔细查看这些请求。 有关详细信息，请参阅 Microsoft标识平台中的权限和同意概述。