多Agent之间个人访问凭证的安全传递问题

1. 问题背景：多 Agent 下个人访问凭证传递

1.1 场景描述

在现代 AI 应用架构中，一个复杂任务往往需要多个 Agent（智能体）协同完成。例如，一个「旅行规划 Agent」可能需要调用「机票预订 Agent」、「酒店预订 Agent」和「日程管理 Agent」。每个 Agent 需要以用户身份访问对应的第三方服务（航空公司 API、酒店系统、Google Calendar 等），这就要求用户的个人访问凭证（Access Token）能够在多个 Agent 之间安全、可控地传递。

核心挑战可以归纳为一句话：如何在不泄露用户原始凭证的前提下，让下游 Agent 获得恰好满足其任务需要的最小权限，并保留完整的审计链路。

下图展示了安全委托传递的总体架构思路——用户授权 Orchestrator Agent，后者通过 Token Exchange 为每个下游 Agent 获取权限缩减的 Scoped Token：

图 1：安全委托传递架构 — 用户授权 Orchestrator Agent，后者通过 Token Exchange 为每个下游 Agent 获取权限缩减的 Scoped Token。

1.2 直接传递 Token 的安全隐患

最朴素的做法是将同一个 Access Token 直接复制传递给所有下游 Agent，但这种做法存在多重安全问题：
unsafe-direct-token-passing.png

图 2：左侧为不安全的直接传递模式——所有 Agent 共享同一个全权限 Token；右侧为安全的委托模式——每个 Agent 获取独立的权限缩减 Token。

权限过度暴露： 下游 Agent 获得的权限可能远超其实际需要，违反最小权限原则（Principle of Least Privilege）。例如，Calendar Agent 只需 calendar.read 权限，却拿到了包含 mail.send、files.readwrite 的完整 Token。
凭证泄露扩散： Token 在多个服务间明文传递，攻击面随 Agent 数量线性增长。任何一个 Agent 被攻破都会导致用户的全部授权范围泄露。
审计不可区分： 当所有 Agent 使用同一个 Token 访问资源时，资源服务器的日志中无法区分具体是哪个 Agent 执行了哪些操作，安全事件溯源变为不可能。
生命周期失控： 无法对不同 Agent 设置不同的 Token 过期时间。一个需要 5 分钟完成的简单查询任务和一个需要 30 分钟的复杂预订任务，不应该使用相同有效期的 Token。
撤销粒度粗糙： 用户无法选择性地撤销对某个特定 Agent 的授权——要么全部撤销，要么全部保留。

1.3 问题本质：缺少标准化的委托授权机制

上述问题的根源在于：OAuth 2.0 基础框架（RFC 6749）设计时只考虑了「用户 → 应用」的双方模型，并未考虑「用户 → Agent A → Agent B → Agent C」的多级委托场景。我们需要的是一套标准化的 Delegated Authorization（委托授权） 机制，它应具备以下能力：

Agent 身份独立性： 每个 Agent 拥有自己的身份凭证，能够向 Authorization Server 独立证明「我是谁」。
权限逐级缩减（Scope Down）： 每一级委托传递时，Token 的权限范围只能减少不能增加。
委托链可追溯（Delegation Chain）： Token 中记录完整的委托路径，实现端到端审计。
用户同意与控制： 用户明确知晓并同意哪些 Agent 将代表自己行动，且可随时撤销。

接下来，我们将了解现有的 OAuth RFC 协议（ RFC 7523 、RFC 8693），探索已有的委托授权机制，以及分析微软 Entra Agent ID 提供的 OBO（On Behalf Of）能力的实际落地方式。

2. RFC 7523：JWT Bearer Assertion 授权许可

2.1 规范概述

RFC 7523（JSON Web Token Profile for OAuth 2.0 Client Authentication and Authorization Grants）定义了如何使用 JWT 作为 OAuth 2.0 的授权许可（Authorization Grant） 和客户端认证方式。

本章聚焦于 RFC 7523 的 JWT 作为 Authorization Grant 这一核心使用模式——即客户端直接用一个签名的 JWT Assertion 向 Token Endpoint 请求 Access Token。这是理解 Entra Agent ID OBO 流程中 grant_type=urn:ietf:params:oauth:grant- type:jwt-bearer 的基础。

2.2 JWT 作为 Authorization Grant

在此模式下，客户端使用一个签名的 JWT（Bearer Assertion）直接作为授权许可向 Token Endpoint 请求 Access Token。JWT 本身即为授权凭据，无需其它额外的交互授权步骤。

图 3：RFC 7523 JWT Bearer Grant 流程 — Agent 构造签名 JWT Assertion，直接向 Authorization Server 请求 Access Token。

请求格式：

POST /token HTTP/1.1
Host: authorization-server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
&scope=calendar.read

核心参数：

参数	要求	说明
`grant_type`	必须	固定值 `urn:ietf:params:oauth:grant-type:jwt-bearer`
`assertion`	必须	签名的 JWT Bearer Assertion
`scope`	可选	请求的权限范围

工作原理： Authorization Server 收到请求后，验证 JWT 的签名、签发者（iss）、受众（aud）、有效期（exp）等声明，确认 JWT 的合法性后直接颁发 Access Token。

2.3 JWT Assertion 核心声明

JWT Assertion 必须包含以下标准声明，Authorization Server 依此进行验证：

Claim	要求	说明
`iss`	必须	签发者标识，标识 JWT 的签发方
`sub`	必须	主体标识，标识 JWT 所代表的实体（可以是用户或 Agent）
`aud`	必须	目标受众，能够让Authorization Server 识别自身。通常为 Authorization Server 的 Token Endpoint URL
`exp`	必须	过期时间，应设置为较短的有效窗口
`jti`	可选	唯一标识符，建议使用以防止 JWT 重放攻击
`iat`	可选	签发时间
`nbf`	可选	生效时间

2.4 在委托授权场景中的应用

在多 Agent 委托场景中，JWT Bearer Grant 可被用于 Token 交换的核心步骤。例如，在 Microsoft Entra Agent ID 的 OBO 流程中（详见第 5 章），Agent Identity 将上游 Token 作为 assertion 参数提交，配合 requested_token_use=on_behalf_of，请求代表用户行动的委托 Token：

图 4：Agent Identity 使用 T1（client_assertion）和用户 Token Tc（assertion）通过 JWT Bearer Grant + OBO 参数获取权限缩减的委托 Token T2。

在这个场景中，assertion 参数承载的用户 Token 是整个 OBO 流程的核心——它既是 JWT Bearer Grant 的授权凭据，也是用户委托意愿的证明。Authorization Server 验证该 JWT 后，颁发权限受限的新 Token 给 Agent。

2.5 安全特性

签名或 MAC： 根据 RFC 7523 规范，JWT 必须经过数字签名或应用消息认证码（MAC）。在 Agent 委托场景中，由于 JWT 需要在多方之间传递，建议使用 RS256 或 ES256 等非对称签名算法，确保即使 JWT 被截获，攻击者也无法伪造新的 Assertion。
短生命周期： exp 窗口应极短（Authorization Server 可拒绝过期时间不合理的 JWT），最小化 JWT 被截获后的可利用时间。
防重放： jti + 服务端缓存可确保每个 JWT 只能使用一次（RFC 7523 允许 Authorization Server 维护已使用 jti 值的集合）。
受众限定： aud 严格限定为 Token Endpoint URL，防止 JWT 被拿到其他端点使用。

2.6 局限性

RFC 7523 JWT Bearer Grant 作为一种授权许可机制，具有如下局限：

缺少显式的委托语义： 协议本身不区分「代表用户行动」和「以自身身份行动」，委托关系需要通过额外参数（如 requested_token_use）或协议扩展来表达。
无原生委托链记录： 没有标准化的声明来记录「谁委托了谁」的链路信息。
无原生权限缩减参数： 虽然可以通过 scope 参数请求子集权限，但协议不强制「新 Token 权限 ⊆ 原始 Token 权限」的约束。
无委托 vs 模拟区分： 无法在协议层面区分 Delegation（保留双方身份）和 Impersonation（隐藏 Agent 身份）。

这些能力需要 RFC 8693 Token Exchange 来补充。

3. RFC 8693：Token Exchange 与 RFC 7523 的对比分析

3.1 规范概述

RFC 8693（OAuth 2.0 Token Exchange）定义了一套安全令牌服务（STS）协议，允许客户端用一个已有的安全令牌交换另一个安全令牌。与 RFC 7523 的 JWT Bearer Grant 不同，Token Exchange 是一个专为令牌转换和委托场景设计的协议，原生支持委托语义、权限缩减和审计链路。

3.2 核心请求格式

图 5：RFC 8693 Token Exchange — Agent 提交 subject_token（用户 Token）和 actor_token（Agent Token），Authorization Server 返回包含 act 声明的新 Token。

POST /token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<用户的 Access Token>
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&actor_token=<Agent 的 Token>
&actor_token_type=urn:ietf:params:oauth:token-type:access_token
&scope=calendar.read
&resource=https://calendar-api.example.com

核心参数：

参数	要求	说明
`grant_type`	必须	固定值 `urn:ietf:params:oauth:grant-type:token-exchange`
`subject_token`	必须	被代表方（用户）的安全令牌
`subject_token_type`	必须	`subject_token` 的类型 URI
`actor_token`	可选	实际执行方（Agent）的安全令牌
`actor_token_type`	条件必须	当 `actor_token` 存在时必须提供
`scope`	可选	目标权限范围，实现 Scope Down
`resource`	可选	目标资源 URI
`audience`	可选	目标受众

3.3 委托（Delegation）vs 模拟（Impersonation）

RFC 8693 定义了两种语义模式，这是它与 RFC 7523 JWT Bearer Grant 的关键区别之一：

图 6：委托模式（Delegation）保留双方身份和完整审计链路（推荐）；模拟模式（Impersonation）隐藏 Agent 身份，审计链路断裂（慎用）。

委托模式（Delegation） ——新 Token 同时标识用户和 Agent，通过 act（actor）声明形成可追溯的委托链：

{
   
  "sub": "user-alice-12345",
  "scope": "calendar.read",
  "act": {
   
    "sub": "travel-agent-001",
    "act": {
   
      "sub": "orchestrator-agent-000"
    }
  }
}

act 声明支持嵌套，完整记录从最上游到最下游的每一级委托关系。资源服务器可以从 Token 中直接提取完整的委托链路，实现端到端审计。

模拟模式（Impersonation） ——新 Token 只包含用户身份，Agent 身份不可见。资源服务器无法区分请求来自用户本人还是 Agent。在多 Agent 场景中应避免使用此模式，因为它完全破坏了审计链路。

3.4 `may_act` 预授权声明

RFC 8693 还定义了 may_act 声明，允许在原始 Token 中提前声明「谁可以代表我」：

{
   
  "sub": "user-alice-12345",
  "may_act": {
   
    "sub": "orchestrator-agent-000",
    "iss": "https://agent-platform.example.com"
  }
}

Authorization Server 在处理 Token Exchange 时检查此声明，只允许预授权的 Agent 进行委托操作。这为多 Agent 场景提供了一种白名单式的委托控制。

3.5 JWT Bearer Grant（RFC 7523）与 Token Exchange（RFC 8693）对比

以下从多个维度对比 RFC 7523 的 JWT Bearer Grant 和 RFC 8693 的 Token Exchange：

维度	RFC 7523 JWT Bearer Grant	RFC 8693 Token Exchange
Grant Type	`urn:ietf:params:oauth:grant-type:jwt-bearer`	`urn:ietf:params:oauth:grant-type:token-exchange`
核心定位	JWT 断言即授权——用一个签名 JWT 直接换取 Access Token	令牌交换——用已有令牌交换新令牌，支持身份和权限转换
输入	单一 `assertion` 参数（一个签名 JWT）	`subject_token` + 可选 `actor_token`（两个令牌）
输出	Access Token	新的安全令牌（可以是 Access Token、Refresh Token 等）
委托语义	无原生支持，需依赖额外参数（如 `requested_token_use`）	原生支持，通过 `act` 声明和嵌套结构表达
权限缩减	可通过 `scope` 参数请求，但无强制约束	通过 `scope` / `resource` / `audience` 原生支持，语义明确
审计链路	无原生支持	通过嵌套 `act` 声明自动记录完整委托链
预授权机制	无	`may_act` 声明
委托 vs 模拟	不区分	明确定义 Delegation 和 Impersonation 两种语义
多级链式传递	不直接支持	通过嵌套 `act` 支持多级链式委托
协议复杂度	较低——单一 JWT 输入	较高——多参数、多语义
标准化委托字段	无 Agent 专用字段	`act` 通用委托字段，无 Agent 专用字段

3.6 两者共同的不足

无论选择哪种协议路径，RFC 7523 或者 RFC 8693 的技术方案在 AI Agent 场景中仍有不足：

无 Agent 专用身份模型： 两个规范都将 Agent 视为普通的 OAuth Client，没有 Agent Identity、Agent Blueprint 等专用概念。
缺少标准化的 Agent 注册： Agent 的能力边界没有标准化的声明方式。
用户同意粒度不足： 用户同意停留在「应用」层面，无法精确到「哪个 Agent 执行什么操作」。
无 Resource Server 触发的委托流程： 缺少从资源服务器端发起授权挑战（Challenge）到完成委托的标准化机制。

这些空白正是 IETF 新草案要填补的。

4. IETF 草案：AI Agent 专用的 OBO 授权扩展

草案名称： draft-oauth-ai-agents-on-behalf-of-user最新版本： 02（2025 年 8 月） 状态： Internet-Draft（个人提交，活跃开发中） 讨论列表： OAuth Working Group 邮件列表（oauth@ietf.org） 作者： Thilina Shashimal Senarath, Ayesha Dissanayaka（WSO2）

4.1 草案动机

该草案的核心动机是：现有 OAuth 2.0 标准流程无法充分满足 AI Agent 代表用户行动时的安全委托需求。

具体而言，它回应了三个关键不足：

标准 OAuth 2.0 授权码和客户端凭证流程（RFC 6749）缺少获取用户对特定 Agent 行为的显式同意的机制，也无法将 Agent 作为独立身份参与 Token 交换。
RFC 8693 Token Exchange 主要面向服务端通信和模拟场景，不支持通过前端（Front Channel）从授权端点获取用户对 Agent 的显式同意，也不规定如何获取 subject_token。
缺少 Resource Server 驱动的委托触发机制，无法实现「资源服务器发现缺少委托 → 挑战客户端 → 客户端发起授权 → 获取委托 Token」的完整闭环。

4.2 核心设计：扩展授权码流程

该草案并未定义新的 Grant Type。 它在标准 OAuth 2.0 Authorization Code Grant 基础上引入两个新参数来实现 Agent 委托授权：

参数	使用位置	说明
`requested_actor`	Authorization Endpoint（授权端点）	标识需要获得委托权限的 Agent，由 Client 在发起授权请求时携带
`actor_token`	Token Endpoint（令牌端点）	Agent 的认证令牌，在换取 Access Token 时提交，用于验证 Agent 身份

这种设计的优势在于：复用现有 OAuth 2.0 基础设施，授权服务器只需在现有 Authorization Code 流程上增加对两个新参数的处理即可支持 Agent 委托。

4.3 完整协议流程

图 7：IETF 草案完整流程 — 从 Agent 发起请求、Resource Server 挑战、到用户授权和委托 Token 颁发的完整闭环。

阶段一：资源服务器挑战（Resource Server Challenge）

当 Client 代表 Agent 访问受保护资源时，若缺少有效的委托 Token，资源服务器返回挑战响应：

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token"

或当 Token 权限不足时：

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
  error_description="The access token does not have the required scope(s)",
  required_scope="scope1 scope2"

阶段二：用户授权请求

Client 收到挑战后，将用户重定向到 Authorization Server 的授权端点，携带 requested_actor 参数：

GET /authorize?response_type=code
  &client_id=<client_id>
  &redirect_uri=<redirect_uri>
  &scope=<scope>
  &state=<state>
  &code_challenge=<code_challenge>
  &code_challenge_method=S256
  &requested_actor=<actor_id>
HTTP/1.1

Authorization Server 收到请求后：

验证 requested_actor 是否对应一个已识别的 Actor 身份。
向用户展示同意界面，明确显示发起请求的 Client 应用、请求委托的 Agent（requested_actor）、以及请求的权限范围。
用户同意后，签发绑定了用户、Client 和 Agent 三方信息的 Authorization Code。

阶段三：Token 请求与颁发

Client 获取 Authorization Code 后，向 Token Endpoint 发起请求，使用标准 authorization_code Grant Type 并附加 actor_token：

POST /token HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=<client_id>
&code=<authorization_code>
&code_verifier=<code_verifier>
&redirect_uri=<redirect_uri>
&actor_token=<actor_token>

注意： grant_type 为标准的 authorization_code，而非新定义的 Grant Type。Agent 身份通过 actor_token 参数传入。

Authorization Server 处理步骤：

按标准 OAuth 2.0 Token Endpoint 规范验证请求参数。
验证 actor_token 有效且未过期。
核心校验： 验证 actor_token 的 sub 声明与用户在授权阶段同意的 requested_actor 一致，确保用户同意与 Agent 身份严格绑定。
验证通过后颁发 Access Token。

4.4 Access Token 结构与声明

颁发的 Access Token 应为 JWT 格式（RFC 9068），包含以下声明以记录完整的委托链路：

{
   
  "iss": "https://authorization-server.com/oauth2/token",
  "aud": "resource_server",
  "sub": "user-456",
  "azp": "client-app-id",
  "scope": "read:email write:calendar",
  "exp": 1746009896,
  "iat": 1746006296,
  "jti": "unique-token-id",
  "act": {
   
    "sub": "actor-finance-v1"
  },
  "aut": "APPLICATION_USER"
}

关键声明解读：

Claim	说明
`sub`	用户身份——标识委托操作的资源所有者
`azp`	Client 应用身份——标识发起授权流程的客户端应用
`act.sub`	Agent 身份——标识实际执行操作的 Agent
`scope`	授权范围——用户同意的、Agent 可执行的具体操作
`aut`	认证上下文——标识 Token 的授权模式（如 `APPLICATION_USER` 表示应用代表用户）

这套三方声明（sub + azp + act.sub）提供了清晰的审计路径：谁（用户） 授权了 哪个应用（Client） 让 哪个 Agent（Actor） 执行了什么操作。

4.5 与 RFC 7523 / RFC 8693 的关系

能力	RFC 7523 JWT Grant	RFC 8693 Token Exchange	IETF 草案
Agent 身份参与 Token 交换	通过 `assertion` 间接参与	通过 `actor_token` 参与	通过 `actor_token` 参与
委托 Token 颁发	支持（OBO 场景）	原生支持	扩展 Authorization Code 支持
用户显式同意 Agent 委托	不涉及	不涉及（后端流程）	`requested_actor` + 前端同意
委托链审计	无原生支持	`act` 声明	`act` 声明（复用 RFC 8693）
权限缩减	`scope` 参数	`scope` / `resource` 原生支持	`scope` 参数
Resource Server 触发委托	不涉及	不涉及	WWW-Authenticate 挑战机制
标准化程度	RFC 标准	RFC 标准	IETF 草案（制定中）

简而言之： IETF 草案的核心创新在于将 Agent 委托授权嵌入标准 Authorization Code 流程，通过 requested_actor 实现用户对特定 Agent 的显式前端同意，通过 actor_token 实现 Agent 身份在 Token 交换中的参与，并通过 Resource Server Challenge 机制打通了从资源访问失败到委托授权获取的完整闭环。它复用了 RFC 8693 的 act 声明来记录委托链，在现有 OAuth 2.0 基础设施上实现了最小侵入的 Agent 委托扩展。

4.6 安全考量

草案在安全层面强调以下要点：

Actor 认证安全性： 整个流程的安全性严重依赖 Authorization Server 在 Token 请求阶段对 actor_token 的可靠验证。Agent 获取和保护其 Actor Token 的方式至关重要。
PKCE 强制要求： 必须使用 PKCE（RFC 7636）防止授权码拦截攻击，尤其在 Client 可能运行在不安全环境时。
Authorization Code 绑定： Authorization Code 必须同时绑定用户、Client（client_id）和 Agent（requested_actor），并在 Token 请求阶段进行严格校验。
单次使用与短有效期： Authorization Code 必须是一次性的，且有效期应尽可能短。
清晰的用户同意： 同意界面必须清晰展示 Agent 身份和请求的权限范围，确保用户理解自己在授权什么。

5. Microsoft Entra Agent ID：On Behalf Of Token 最佳实践

5.1 产品定位

Microsoft Entra Agent ID 是微软于 2025 年推出的 AI Agent 身份管理平台，将 Entra ID（前身 Azure AD）的企业级身份能力扩展到 AI Agent 领域。它的核心理念是：每个 AI Agent 都应拥有独立的、可管理的身份（Identity），就像企业中的每个员工都有自己的账号一样。

Entra Agent ID 是目前业界最完整的多 Agent 凭证委托的工业级实现。它综合运用了前述章节介绍的 RFC 7523 JWT Bearer Grant 和 RFC 8693 Token Exchange 的委托语义，其架构设计直接回应了第 1 章提出的所有安全挑战——Agent 身份独立性、权限逐级缩减、委托链可追溯和用户同意控制。

5.2 核心概念

Entra Agent ID 的身份体系由以下核心概念构成：

图 8：Entra Agent ID 核心概念模型 — Agent Identity Blueprint 作为模板生成多个 Agent Identity 实例，Agent User 为需要用户对象的场景提供兼容性。

Agent Blueprint（Agent 蓝图）

Agent Blueprint 是创建和管理多个 Agent Identity 的模板与管理结构，是 Agent Identity 的父级对象。一个 Blueprint 可以实例化多个 Agent Identity，每个实例拥有独立的权限配置。这意味着：相同逻辑的 Agent（如「日历管理 Agent」）可以为不同租户或不同场景创建多个实例。Agent Blueprint 没有密码，不使用人类的认证方式（如短信、Passkey、Authenticator 应用）。它使用软件系统可用的凭据类型进行认证，包括：托管身份（Managed Identity，推荐用于 Azure 上运行的 Agent）、联合身份凭据（FIC，用于 Kubernetes 或其他云平台）、证书/加密密钥，以及客户端密钥（Client Secret）。

当 Blueprint 被添加到租户时，会创建一个对应的 Blueprint Principal 对象，管理该 Blueprint 在特定租户中的存在。

Agent Identity（Agent 身份）

Agent Identity 是 AI Agent 用于向各种系统进行身份认证的主要账号。它在 Microsoft Entra ID 中拥有唯一标识符——Object ID 和 App ID（两者始终相同），可可靠地用于认证和授权决策。它的认证方式来源于 Agent Blueprint，Agent Blueprint 完成自身身份认证后，获取到一个 AccessToken，这个 AccessToken 又会作为 Agent Identity 的 Client Assertion，完成 Agent Identity 的身份认证。

Agent User（Agent 用户）

对于需要与强依赖用户对象的系统交互的场景，平台提供 Agent User 作为替代身份类型。Agent User 是租户中的用户对象，拥有 UPN、Manager、Photo 等用户属性，使 AI Agent 能够接入那些对用户对象有硬性依赖的系统（如 Exchange 邮箱）。每个 Agent Identity 可以（意味着可选），并且只能和一个 Agent User 做一一绑定。

Agent Registry（Agent 注册表）

Agent Registry 是一个集中式元数据仓库，维护组织内所有已注册 Agent 的信息，作为服务发现机制，允许系统基于 Agent 的能力、角色等属性进行查找和交互。

5.3 Agent 运行模式

根据官方文档，Entra Agent ID 支持两种主要运行模式（Operation Pattern），对应三种工作流程：

两种运行模式

模式	说明	Token 类型
交互式 Agent（Interactive）	Agent 登录用户并响应用户指令执行操作，代表已登录用户行动，使用用户的委托权限	User Token
自主式 Agent（Autonomous）	Agent 使用自身身份执行操作，不依赖人类用户身份，在后台自主决策	Agent Token 或 Agent User Token

三种工作流程

图9：交互式模式（Agent OBO Flow）与自主式模式（Autonomous App Flow + Agent User Flow）对应的三种工作流程。

重要限制： 所有 Agent 实体都是机密客户端（Confidential Client），不支持交互式登录流程（/authorize 端点），所有认证必须通过编程方式的 Token 交换完成。不支持 Redirect URI。

5.4 Agent OBO 流程详解

Agent OBO 是 Entra Agent ID 实现用户委托的核心能力。与传统 OBO 不同，它涉及 Agent Blueprint 和 Agent Identity 两层实体的协作，通过 Federated Identity Credential（FIC）实现安全的 Token 交换。在协议层面，该流程使用第 2 章介绍的 RFC 7523 JWT Bearer Grant 作为核心授权许可机制。

图10：Agent OBO 两阶段流程 — 阶段一：Blueprint 通过托管身份获取交换 Token T1；阶段二：Agent Identity 使用 T1 和用户 Token Tc 执行 OBO 交换获取资源 Token T2。

关键步骤说明：

步骤 1-3 — 用户授权： 用户通过 Client App 认证后获得用户 Token（Tc），Client 将 Tc 转发给 Agent Identity Blueprint。

步骤 4-5 — Blueprint 获取交换 Token： Blueprint 使用自身的客户端凭证（推荐使用托管身份 Managed Identity 作为 FIC）向 Entra ID 请求交换 Token T1。请求中通过 fmi_path 指定目标 Agent Identity。

步骤 6-8 — Agent Identity 执行 OBO： Agent Identity 使用 T1（作为 client_assertion）和用户 Token Tc（作为 assertion），通过 grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer 配合 requested_token_use=on_behalf_of 参数，向 Entra ID 发起 OBO 请求。这正是 RFC 7523 JWT Bearer Grant 在委托场景中的典型应用。

步骤 8 — 服务端验证： Entra ID 执行多层验证——T1 的受众（aud）必须匹配 Blueprint 的 Client ID，Tc 的受众也必须匹配 Blueprint 的 Client ID，同时检查用户同意状态和权限约束。

步骤 9-10 — 颁发并使用资源 Token： 验证通过后，Entra ID 颁发针对目标资源的 Access Token，其权限范围被约束为 Agent Identity 被授予的委托权限。

5.5 Agent Token 专有声明（Claims）

Entra Agent ID 颁发的 Token 在标准 OAuth 2.0 Access Token 声明基础上，引入了多个专有声明以标识 Agent 实体类型及其关系。以下为官方定义的核心声明：

Claim	说明
`idtyp`	主体的实体类型：`user`（用户委托和 Agent User 场景）或 `app`（自主操作场景）
`azp` / `appid`	Authorized Party / Actor —— Agent Identity 的 Application ID，用于客户端归因和审计日志
`oid`	主体的 Object ID：用户委托场景为用户 OID，自主场景为 Agent Identity 的 Service Principal OID，Agent User 场景为 Agent User OID
`scp`	委托权限（Delegated Permissions），仅在用户委托和 Agent User 场景中存在；自主场景为空或 `/`
`xms_idrel`	主体与资源租户之间的身份关系（如 `7` = Service Principal，`1` = Member User）
`xms_act_fct`	Actor Facets —— 描述 Token 中执行方（actor）的特征。多值声明（空格分隔的整数），包含值 `11` 时表示 AgentIdentity
`xms_sub_fct`	Subject Facets —— 描述 Token 中主体（subject）的特征。多值声明，包含 `11` = AgentIdentity，`13` = AgentIDUser
`xms_tnt_fct`	Tenant Facets —— 描述租户特征。多值声明
`xms_par_app_azp`	Agent Identity 的父级应用（即 Agent Identity Blueprint）的 Application ID

下图展示了三种场景下 Token 声明的差异：

图11：三种场景下 Token 声明的差异 — OBO 场景（idtyp=user）、自主操作场景（idtyp=app）、Agent User 场景（idtyp=user, xms_sub_fct=13）。

Agent 代表用户操作时的 Token 示例：

{
   
  "aud": "https://resource-api.example.com",
  "iss": "https://sts.windows.net/{tenant-id}/",
  "sub": "user-object-id",
  "oid": "user-object-id",
  "tid": "{tenant-id}",
  "idtyp": "user",
  "azp": "agent-identity-app-id",
  "scp": "calendar.read calendar.write",
  "xms_idrel": "1",
  "xms_act_fct": "11",
  "xms_par_app_azp": "agent-blueprint-app-id",
  "exp": 1753421385,
  "iat": 1753392285
}

其中 xms_act_fct 包含 11 标明执行操作的是一个 Agent Identity（实际 Token 中该声明为多值格式，可能包含额外的 facet 值），xms_par_app_azp 记录了该 Agent Identity 所属的 Blueprint，资源服务器可据此进行审计追踪。与 RFC 8693 的通用 act 声明相比，Entra 选择了微软生态专有的 xms_* 声明来实现类似的委托链审计能力。

5.6 权限继承与治理能力

权限继承（Permission Inheritance）： Agent Identity 可以从父级 Blueprint 继承委托权限（需启用 InheritDelegatedPermissions 属性）。此继承机制减少了多实例场景下的同意复杂度——Agent Identity 可直接使用已授予父级应用的权限。继承功能专用于 FIC impersonation 场景，且仅在租户边界内有效。

企业级治理：

Conditional Access： 管理员可为 Agent 设置条件访问策略，例如对所有同类型 Agent（基于同一 Blueprint）应用统一的安全策略。
Audit Log： 所有 Agent Token 获取和资源访问记录写入 Entra ID 审计日志，azp 标识请求方 Agent，oid 标识资源访问主体，xms_act_fct 和 xms_sub_fct 支持区分 Agent 操作与人类用户操作。
Consent Framework： 用户可查看和撤销对任意 Agent 的授权。管理员可为组织批量管理 Agent 的权限同意。
批量管理： 管理员可通过 Blueprint 级别的操作（如禁用、撤销权限、删除）一次性影响所有同类型 Agent 实例。

管理角色分离：

角色	职责
Owner（所有者）	Agent 的技术管理员，负责操作和配置
Sponsor（赞助者）	Agent 的业务责任人，负责生命周期决策，无需技术管理权限
Manager（经理）	被指定为 Agent User 的招聘经理（Hiring Manager）或运营负责人，可为其管理的 Agent User 请求访问包

5.7 小结：Entra Agent ID 的协议定位

Entra Agent ID 的价值在于将前述章节介绍的标准协议能力整合为一个完整的工业级产品：

标准协议能力	Entra 中的对应实现
RFC 7523 JWT Bearer Grant	OBO 流程中 `grant_type=jwt-bearer` + `requested_token_use=on_behalf_of`
RFC 8693 委托语义	通过 `xms_act_fct`、`xms_sub_fct`、`xms_par_app_azp` 等专有声明实现委托链审计
IETF 草案 Agent 注册	Agent Registry 集中式元数据仓库
IETF 草案用户同意	Consent Framework 支持用户级和管理员级同意管理

同时，Entra 还在标准协议之上增加了企业治理层——Agent Blueprint / Identity 双层模型、Conditional Access、ID Governance、管理角色分离（Owner / Sponsor / Manager），这些是纯协议规范所不覆盖但企业落地不可或缺的能力。

6. 总结

本文从一个实际问题出发——多个 AI Agent 协同工作时如何安全传递用户的个人访问凭证——逐层解析了行业标准和最佳实践。

核心结论如下：

不要直接传递 Token。 在多 Agent 架构中，直接复制传递用户的 Access Token 会导致权限暴露、审计失效和撤销困难。正确的做法是通过 Token Exchange 或 OBO 流程为每个 Agent 获取权限缩减的委托 Token。

RFC 7523 JWT Bearer Grant 和 RFC 8693 Token Exchange 是两种互补的授权许可机制。 RFC 7523 提供了简洁的 JWT 断言换 Token 能力，是 OBO 流程的协议基础；RFC 8693 提供了原生的委托语义（act 声明）、权限缩减和模式区分（委托 vs 模拟），是更完备的令牌交换协议。两者可独立使用，也可组合使用。

IETF 草案（draft-oauth-ai-agents-on-behalf-of-user）提出了一种轻量级的 Agent 委托扩展。 它不定义新的 Grant Type，而是在标准 Authorization Code 流程上增加 requested_actor（授权端点）和 actor_token（令牌端点）两个参数，实现用户对 Agent 的显式前端同意和 Agent 身份在 Token 交换中的参与。同时引入 Resource Server Challenge 机制，打通了委托授权的完整闭环。

Microsoft Entra Agent ID 是当前已知的工业实现之一。 它的 Agent Blueprint / Identity 双层模型、基于 FIC 的 OBO 流程、专有 Token 声明（xms_act_fct、xms_sub_fct、xms_par_app_azp）和企业治理能力（Conditional Access、ID Governance、管理角色分离）为行业树立了标杆。

落地方案的关键要素： 无论使用哪个 Agent 编排平台，实现安全的多 Agent 凭证传递都需要：Agent 身份注册（让每个 Agent 有独立可验证的身份）、Token Exchange / OBO 机制（实现权限缩减的委托 Token 颁发）、以及基于 act 声明的审计链路（记录完整的用户 → Client → Agent 操作路径）。

7. 参考资料

7.1 RFC 标准

7.2 IETF 草案

draft-oauth-ai-agents-on-behalf-of-user-02 — OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents

探索云世界

热门

云计算

大数据

云原生

人工智能

数据库

开发与运维

活动广场

任务中心

训练营

直播

乘风者计划

下载

镜像站

技术资料

多Agent之间个人访问凭证的安全传递问题

多Agent之间个人访问凭证的安全传递问题

目录

1. 问题背景：多 Agent 下个人访问凭证传递

1.1 场景描述

1.2 直接传递 Token 的安全隐患

1.3 问题本质：缺少标准化的委托授权机制

2. RFC 7523：JWT Bearer Assertion 授权许可

2.1 规范概述

2.2 JWT 作为 Authorization Grant

2.3 JWT Assertion 核心声明

2.4 在委托授权场景中的应用

2.5 安全特性

2.6 局限性

3. RFC 8693：Token Exchange 与 RFC 7523 的对比分析

3.1 规范概述

3.2 核心请求格式

3.3 委托（Delegation）vs 模拟（Impersonation）

3.4 may_act 预授权声明

3.5 JWT Bearer Grant（RFC 7523）与 Token Exchange（RFC 8693）对比

3.6 两者共同的不足

4. IETF 草案：AI Agent 专用的 OBO 授权扩展

4.1 草案动机

4.2 核心设计：扩展授权码流程

4.3 完整协议流程

阶段一：资源服务器挑战（Resource Server Challenge）

阶段二：用户授权请求

阶段三：Token 请求与颁发

4.4 Access Token 结构与声明

4.5 与 RFC 7523 / RFC 8693 的关系

4.6 安全考量

5. Microsoft Entra Agent ID：On Behalf Of Token 最佳实践

5.1 产品定位

5.2 核心概念

Agent Blueprint（Agent 蓝图）

Agent Identity（Agent 身份）

Agent User（Agent 用户）

Agent Registry（Agent 注册表）

5.3 Agent 运行模式

两种运行模式

三种工作流程

5.4 Agent OBO 流程详解

5.5 Agent Token 专有声明（Claims）

5.6 权限继承与治理能力

5.7 小结：Entra Agent ID 的协议定位

6. 总结

7. 参考资料

7.1 RFC 标准

7.2 IETF 草案

7.3 Microsoft Entra Agent ID

7.4 行业文章

热门文章

最新文章

相关电子书

3.4 `may_act` 预授权声明