【Agent 身份与安全】Agent 身份谱系：从 API Key 到委托 Token

LLM Agent 调用 Gmail、Slack、内部 API 时，「用谁的权限执行」没有统一答案。四代工程实践从 API Key 到 RFC 8693 Token Exchange，每一代解决一部分问题，也引入新的撤销与审计难题。本文从 IAM 系列 的 OAuth/OIDC 基础出发，聚焦 Agent 作为委托主体的身份表达——不重复 JWT 详解，只补 Agent 场景下的 claim 与坑。

核心问题：资源服务器（Resource Server, RS）收到一次 API 调用时，需要同时回答三个问题——谁在操作（sub）、谁在代理（act）、凭据是否仍有效（exp + 吊销状态）。Gen4 委托模型把这三个问题写进 token 载荷；Gen2 把用户 refresh token 塞给 Agent 则三个问题全部失效。

一、四代身份模型全景

flowchart LR
  G1["Gen1 API Key"] --> G2["Gen2 用户 OAuth Token"]
  G2 --> G3["Gen3 Service Account"]
  G3 --> G4["Gen4 Token Exchange 委托"]

生产目标：Gen4 语义 + Gen3 自动化——用户显式委托 Agent，Agent 运行时以 SA 证明自身（Gen3），经 Token Exchange 换短期用户委托 token（Gen4），RS 审计能回答「用户 U 的 Agent A 在 T 时刻调用了什么」。

1.1 Gen1：API Key 的残留场景

API Key 仍出现在：内部脚本、早期 SaaS 集成、无 OAuth 的 legacy API。对 Agent 而言，Gen1 意味着：

• 归因断裂：日志里只有 api_key_id=ak_xxx，无法关联到具体用户。
• 权限静态：Key 权限在创建时固定，Agent 无法按用户缩小 scope。
• 轮换痛苦：一个 Key 被多个 Agent 实例共享时，轮换影响面大。

Gen1 acceptable 的唯一边界：Agent 只访问无用户上下文的全局资源（如公开天气 API）。一旦涉及用户邮件、文件、订单，必须升级到 Gen2 以上。

1.2 Gen2：用户 Token 直连的反模式

常见反模式：用户在 Web UI 完成 OIDC 授权码 + PKCE 后，前端把 refresh token 写入 Agent 进程的环境变量或本地文件。

Gen2 的正确子集：Agent Gateway 代表用户持有 refresh token（中心化存储、加密、HSM），Agent 进程永不接触 refresh token，只拿 Gateway 签发的短期 delegated access token。

1.3 Gen3：Service Account 的定位

Workload Identity 解决「这个 Pod/进程是谁」——SPIFFE ID、K8s ServiceAccount JWT、云 IAM 角色。Gen3 不回答「代表哪个用户」。

正确组合：

Agent 进程 ──(SA JWT)──> 证明「我是 checkout-agent 工作负载」
         ──(Token Exchange)──> 换发「用户 U 委托的 read:orders scope token」

单独 Gen3：Agent 以 SA 调 API → 审计只有 SA，合规无法通过「用户授权」审查。

1.4 Gen4：委托 Token 的安全属性

RFC 8693 委托 token 应满足：

1. 可验证：RS 用 JWKS 验签，检查 iss、aud、exp。
2. 可归因：载荷含 sub（用户）与 act（Agent）。
3. 可缩小：scope ≤ 用户原授权 scope。
4. 可撤销：用户会话吊销后，新 Exchange 拒绝；已有 token 靠短 TTL + 持续验证。

二、RFC 8693 OAuth 2.0 Token Exchange

RFC 8693（A 级，2018-05 发布）定义 grant_type=urn:ietf:params:oauth:grant-type:token-exchange。它解决的核心问题：已有 token A，如何换发 token B，使 B 的权限 ≤ A，且表达代理关系。

2.1 标准请求参数（RFC 8693 §2.1）

Token Exchange 请求发往 Authorization Server（AS）的 token endpoint，Content-Type 为 application/x-www-form-urlencoded：

subject-only exchange：只有 subject_token，无 actor_token——输出 token 的 sub 来自 subject，无 act claim。用于「换 audience / 缩小 scope」，非 Agent 委托。

actor + subject exchange：同时提交 actor_token 与 subject_token——输出 token 含 act，表达「actor 代表 subject 行动」。Agent 委托的标准形态。

2.2 Token 类型 URN（RFC 8693 §3）

Agent 场景典型组合：

• subject_token = 用户 access token（或 ID token，视 AS 策略）
• subject_token_type = urn:ietf:params:oauth:token-type:access_token
• actor_token = Agent 工作负载 access token（SA 换取）
• actor_token_type = urn:ietf:params:oauth:token-type:access_token

2.3 请求示例（格式来自 RFC 8693 §2.1，非厂商响应）

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <client_credentials>

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&subject_token=<user_access_token>
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
&actor_token=<agent_access_token>
&actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
&scope=read%3Amail
&resource=https%3A%2F%2Fapi.example.com%2Fmail
&requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token

AS 验证：subject token 有效、actor token 有效、client 被授权执行 exchange、请求的 scope ⊆ subject 的 scope、resource/audience 在允许列表内。

2.4 响应结构（RFC 8693 §2.2）

成功响应：

{
  "access_token": "eyJhbG...",
  "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "read:mail"
}

access_token 若为 JWT，载荷结构见 §2.5。以上字段名与语义来自 RFC 8693，非虚构 IdP 响应——各 AS 可能在 JWT 内增加私有 claim，部署时必须以 IdP 文档为准。

2.5 JWT 中的 act claim（RFC 8693 §4.1）

换发后的 access token（JWT 形态）可携带 actor 声明：

{
  "iss": "https://idp.example.com",
  "sub": "user-248289761001",
  "aud": "https://api.example.com",
  "scope": "read:mail",
  "exp": 1718400000,
  "iat": 1718396400,
  "act": {
    "sub": "agent-checkout-bot",
    "iss": "https://idp.example.com"
  }
}

语义：

• sub：被代理用户（资源所有者）
• act.sub：代理 Actor（Agent 服务身份）
• act 可嵌套：RFC 8693 允许多层 act 表达委托链（少见，Multi-Agent 场景可能用到）

RS 验证后，审计日志应同时记录 sub 与 act.sub（及 client_id 若存在）。

2.6 may_act claim（RFC 8693 §4.4）

与 act 相对，may_act 出现在 subject token 上，声明「谁被允许代理此 subject」：

{
  "sub": "user-248289761001",
  "may_act": {
    "sub": "agent-checkout-bot",
    "iss": "https://idp.example.com"
  }
}

AS 在 Token Exchange 时检查：请求的 actor_token 主体是否匹配 may_act。用户 consent UI 可写入 may_act 约束——仅允许特定 Agent client 代理。

2.7 Impersonation vs Delegation（RFC 8693 §1.2）

工程判断：若 RS 日志无法区分 Agent 与用户本人，选 Delegation + act。

三、Token Exchange 时序

3.1 标准委托流

sequenceDiagram
  participant User
  participant Agent as Agent Runtime
  participant GW as Agent Gateway
  participant IdP as Authorization Server
  participant API as Resource Server

  User->>Agent: 发起任务 + 已完成 OAuth consent
  Agent->>GW: 请求 delegated token scope=read:mail
  GW->>IdP: 用 SA 换 agent_access_token
  IdP->>GW: agent_access_token
  GW->>IdP: Token Exchange subject=user_token actor=agent_token
  IdP->>GW: delegated_access_token with act claim
  GW->>Agent: 短期 delegated token
  Agent->>API: Bearer delegated_access_token
  API->>API: JWKS 验签 + 检查 act + 写审计

Gateway 集中持有 user refresh token，Agent 只拿分钟级 delegated token——对齐 API Gateway 认证 的 BFF 模式。

3.2 用户首次授权与后续 Exchange

sequenceDiagram
  participant User
  participant Browser
  participant IdP
  participant GW as Agent Gateway

  User->>Browser: 启用 Agent 功能
  Browser->>IdP: OIDC authorize scope=read:mail + offline_access
  IdP->>Browser: authorization code
  Browser->>IdP: code + PKCE verifier
  IdP->>GW: access_token + refresh_token
  Note over GW: refresh_token 仅存 Gateway 加密存储

  loop 每次 Agent 任务
    GW->>IdP: refresh → user_access_token
    GW->>IdP: Token Exchange
    IdP->>GW: delegated token
  end

offline_access scope 使 Gateway 能在用户不在线时代为 refresh——用户必须在 consent 时明确授权 Agent 持续访问，且 consent 记录可审计。

四、与 OIDC / Service Account 的集成

4.1 OIDC ID Token 作为 subject_token？

部分 AS 接受 ID Token 作为 subject_token。ID Token 含 sub、aud（client_id），但通常不含 API scope。Exchange 时 AS 应查用户 consent 记录或 session 以确定可发 scope。

工程建议：优先用 access token 作 subject_token——scope 显式、与 RS 授权一致。

4.2 Service Account 作为 actor_token

Agent 运行在 K8s 时：

1. Pod 用 K8s SA JWT 或 SPIFFE SVID 向 IdP 换 agent_access_token
2. agent_access_token 的 sub = spiffe://cluster/ns/sa/checkout-agent
3. Token Exchange 时 actor_token = 该 agent_access_token
4. 输出 delegated token 的 act.sub = 同上 SPIFFE ID

Workload Identity 证明「进程身份」；Token Exchange 叠加「用户委托」——二者不可互相替代。

4.3 JWT 验证清单（RS 侧）

RS 收到 delegated JWT 时，除 JWKS 标准检查 外：

五、OBO 与 RFC 8693 的对照

Microsoft Entra ID、Azure AD 的 On-Behalf-Of (OBO) 流语义接近 Token Exchange，但非严格 RFC 8693：

跨云集成：抽象 Agent Gateway，对内统一 delegated token 格式，对外适配各 IdP OBO/Exchange 实现。勿假设 payload 字段名跨云一致。

Keycloak（截至 2026-06 官方文档）：支持 Token Exchange，需配置 token-exchange 权限与 Fine-Grain Admin Permissions。actor client 需被授权对 target client 执行 exchange。

六、Scope 缩小与 Resource Indicator

RFC 8693 §2.1：scope 参数请求的 scope 不得超过 subject token 已有 scope。Agent 任务级授权示例：

RFC 8707 Resource Indicators：resource 参数绑定 token 的 aud，防止 delegated token 被用于其他 API。Agent 调邮件 API 时 resource=https://mail-api.example.com。

七、威胁模型

与 零信任持续验证 联动：CAEP session-revoked 事件到达后，Gateway 停止 Exchange 并通知 Agent 终止（见 第 08 篇）。

八、工程坑点清单

1. 把用户 refresh token 塞给 Agent 进程——见 §1.2。
2. scope 不缩小——Token Exchange 应显式传 scope=。
3. 无 act 仍称委托——仅转发 user bearer token 不是 Gen4。
4. actor 与 subject 同一 client_id——部分 IdP 要求分离 OAuth client，否则 audit log 混淆。
5. 忽略 may_act 约束——用户仅授权特定 Agent 时 AS 须校验。
6. delegated token TTL 过长——建议 ≤ 15 分钟；长任务用 refresh Exchange 续期而非长 TTL。
7. RS 不解析 act——合规审计失败。
8. 跨 region 缓存 JWKS 过期——Agent 高峰时验签失败；需 JWKS 刷新策略。

九、迁移路径：Gen2 → Gen4

flowchart TD
  S["现状: Agent 持 user refresh token"] --> A["Step1: 引入 Agent Gateway"]
  A --> B["Step2: refresh token 迁入 Gateway 加密存储"]
  B --> C["Step3: Agent 改拿 Gateway 签发的 opaque/ JWT session token"]
  C --> D["Step4: IdP 开启 Token Exchange"]
  D --> E["Step5: Gateway 用 Exchange 换 delegated token 转发 API"]
  E --> F["Step6: RS 启用 act 审计 + 策略引擎"]

与 身份系统迁移 相同原则：分阶段、可观测、可回滚。

十、决策矩阵：选哪一代？

十一、与后续篇章的衔接

• 细粒度 scope：第 03 篇 Scope 与 UMA 在 Gen4 之上讨论资源级 consent。
• 工具授权：第 04 篇 Function Calling 在 token scope 之下再加 tool 参数策略。
• MCP：第 06 篇 把 Exchange 落到 Host/Server 认证。
• 撤销：第 08 篇 处理 Exchange 后的持续验证。
• 审计：第 09 篇 定义 sub/act 如何进日志。

十二、边界

• 不展开完整 OAuth 2.1 + PKCE 教程
• 不做法务合规认定
• CAEP 推送撤销详见第 08 篇；截至 2026-06 CAEP 仍为 OpenID 草案
• 不编造 Keycloak/Auth0/Entra 的实际 token payload——以各 IdP 官方文档为准

十三、RFC 8693 错误响应语义

Token Exchange 失败时 AS 返回 OAuth 2.0 标准 error（RFC 8693 §2.2.2，A 级）：

Gateway 应对 invalid_grant 区分：user session 失效（通知用户 re-auth）vs agent token 失效（轮换 SA）。

十四、嵌套委托与 act 链

RFC 8693 允许多层 act——编排 Agent 再调 worker Agent 时，JWT 可能含嵌套 act。审计须 flatten 整条链；策略可限制链深度 ≤ 2。

十五、Token Exchange 与 Client Credentials 的区别

Agent 读用户数据必须后者。

十六、Consent 与 SCIM 删除

用户账号删除时 Delegation Store cascade revoke——见 SCIM 供给。

十七、总结表：Gen1–Gen4

上一篇：系列索引

下一篇：细粒度 Scope 与 UMA

参考资料

1. IETF RFC 8693, OAuth 2.0 Token Exchange, Section 2–4, 2018
2. IETF RFC 8707, Resource Indicators for OAuth 2.0, 2020
3. IETF RFC 7519, JSON Web Token (JWT)
4. OpenID Connect Core 1.0, Section 2 ID Token
5. Keycloak Documentation, Token Exchange（阅读日期 2026-06）
6. Microsoft Learn, Microsoft identity platform and the OAuth 2.0 On-Behalf-Of flow（B 级，语义对照用）