Microsoft Entra 智能体 ID引入了一种管理模型，将技术管理与业务责任分开，确保操作控制和监督没有过度权限。 本文档介绍 Microsoft Entra 代理 ID 标识类型的管理关系。 本指南适用于 代理标识、 代理标识蓝图、 代理标识蓝图主体和 代理用户帐户。 本文介绍所有者、赞助商和经理，以及他们在维护安全运营方面的重要性。
代理 ID 中可用的管理关系包括：
- 所有者：负责代理标识蓝图和代理标识的操作管理的技术管理员，包括设置、配置和凭据管理。
- 发起人：业务代表负责代理的目的和生命周期决策，包括访问评审和代理保留，而无需技术管理访问权限。 每个代理标识和代理标识蓝图至少需要一个赞助商。
- 经理：负责组织层次结构中代理的用户，可以为其下属代理请求访问包。
必须为每个代理 ID 对象配置这些管理关系，并且独立于Microsoft Entra Role Based 访问控制 （RBAC） 角色（如代理 ID 管理员）授予的管理权限。
所有者
所有者通常充当代理的技术管理员，处理运营和配置方面。 可以将单个用户（包括来宾用户）和服务主体分配为所有者。 群组不能作为所有者。 作为所有者的服务主体能够自动管理代理身份。 所有代理标识对象的所有者都是可选的。
所有者责任
所有者可以修改发起人无法的属性，例如身份验证属性。 所有者还可以添加或更新代理标识的其他所有者和发起人。 与发起人一样，他们可以禁用和删除不再需要的代理标识。 与发起人不同，所有者可以重新启用禁用的代理标识、还原软删除标识或硬删除标识。
所有者访问和许可
所有者具有针对其分配的代理标识蓝图或代理标识的管理权限。 他们可以编辑设置、管理凭据、更改配置并分配更多所有者。
代理标识蓝图或代理标识蓝图主体的所有者还可以使用委派权限从该蓝图创建代理标识，而无需代理 ID 管理员或代理 ID 开发人员角色。 必须向调用应用程序授予以下委派权限之一：AgentIdentity.Create.All或AgentIdentity.ReadWrite.AllAgentIdentity.ReadWrite.ManagedBy。
所有者典型角色
所有者通常是具有技术知识的开发人员或 IT 专业人员，用于管理应用程序标识。 它们可能是关键代理的代理创建者、技术应用程序所有者或 IT 管理员。 可以为多个所有者分配备份覆盖范围。
当其他一些管理服务需要修改或删除特定代理标识而不进行用户干预时，还可以将服务主体设置为所有者。
赞助商
发起人为代理提供业务责任，在不具有技术管理访问权限的情况下做出生命周期决策。 他们了解代理的业务用途，并且可以确定代理是仍然需要还是需要访问权限。 代理标识蓝图和代理标识需要赞助商，以确保每个代理都有指定的业务所有者。
当身为发起人的员工调岗或离职时，应保留其发起人关系，以确保能够顺利交接。 可以将用户（包括来宾用户）和组分配为赞助商。 当一个组被分配任务时，该组的所有成员都有权拥护代理 ID 对象。 并非所有组类型都被支持作为赞助商。 允许以下组类型：
- 动态成员组（安全或 Microsoft 365）
- 分配成员组 (Microsoft 365)
不允许将以下组类型用作赞助商：
- 可分配角色的组（安全组或Microsoft 365组）
- 分配成员组（安全）
发起人责任
发起人根据业务需求对代理生命周期做出决策，包括续订、延期或删除。 他们代表代理请求访问包，并为访问请求提供业务理由。 在安全事件期间，发起人可能会确定代理行为是预期的，还是授权适当的响应，包括暂停或权限调整。
发起人访问权限
赞助商遵循最低权限原则，具有有限的管理权限。 它们无法修改代理蓝图或代理标识上的应用程序设置。 访问仅限于非破坏性生命周期操作：禁用代理标识、修改标识的发起人或软删除。
赞助方无法重新启用或恢复代理蓝图或身份。 如果发起人错误地禁用或删除资源，他们应联系资源所有者或管理员来恢复资源。
赞助典型角色
赞助商通常是业务所有者、产品经理、团队主管或了解代理用途的利益干系人。 对于未发布的代理程序，开发者通常充当赞助商。 对于已发布的代理，赞助商通常来自使用该代理的团队。
智能体标识赞助人与智能体用户帐户赞助人
在Microsoft代理 ID 中，代理的标识、蓝图和蓝图主体可能都有与之关联的赞助商。 此外，代理还可以创建 代理的用户帐户 ，以便访问面向用户的服务。 虽然 Entra 用户具有赞助关系，但用户帐户发起人与代理标识、蓝图或蓝图主体的发起人之间存在差异。
用户上的赞助关联关系主要适用于B2B 访客的赞助人。 他们无权对其发起的用户进行任何更改，但他们可以代表用户请求访问权限，并可能参与审批流。 相比之下，智能体标识、蓝图和蓝图主体的赞助人直接管理这些标识的权限有限，并且还可以在生命周期工作流中请求访问或给予批准。
当智能体同时由智能体标识对象和智能体用户帐户表示时，我们建议将智能体标识赞助人维护为负责智能体的主要用户或组。
如果关联用户帐户所需的访问权限或授权与其代理身份不同，则每个对象的赞助者都可以代表其所赞助的身份请求访问包。 如果需要在代理的用户帐户上设置发起人，则应在两个对象上将同一用户或组设置为发起人，以确保他们可以根据需要为代理标识和代理的用户帐户请求适当的访问权限。
| 代理用户帐户赞助商 | 代理身份、蓝图、蓝图主赞助人 | |
|---|---|---|
| 允许的类型 | 用户（包括访客）、组（任意） | 用户（包括来宾）、选定组（动态成员身份、Microsoft 365）。 不支持可分配角色的组。 |
| 限制 | 最多 5 个赞助商 | 最多 100 个赞助商，不超过 5 个组 |
| 授权 | 没有直接权限修改受赞助用户 | 删除或禁用代理标识并修改其发起人 |
| Required | 不是必需 | 创建智能体标识和智能体蓝图时必需 |
Managers
经理是负责组织层次结构中代理标识的个人用户。 对于在用户方案中处于活动状态的代理，请考虑在代理的用户帐户上设置经理。 经理可以为其代理的用户账户请求访问套餐，并会在 Microsoft Entra 管理中心看到负责向他们汇报的代理。 经理没有权限修改或删除代理；这些操作需要由所有者、发起人或管理员执行。
要求和约束
管理模型强制执行特定的要求和约束，以确保有效的监督和问责。
创建要求
创建代理标识或代理蓝图时，需要发起人。 智能体标识蓝图主体在创建时不受赞助人要求限制。 所有者和经理始终是可选的。
分配策略
对于应用程序与用户上下文都存在的委托创建请求，如果未显式指定发起方，则调用用户将自动成为发起人。 但是，如果在创建过程中指定了一个或多个其他发起人，则不会自动添加呼叫用户。 在创建过程中，具有代理 ID 管理员角色的用户不会自动成为发起人。 这样可以避免让管理员无意中承担对各个代理的直接责任，导致负担过重。
对于仅限应用的创建请求，创建服务必须将一个或多个用户或 支持组 设置为发起人。