介绍 Agent ID Guard 如何通过 RFC 8693 令牌交换机制实现身份链路的完整传递与调用链审计，确保每次下游 API 调用均可追溯到自然人。
背景
合规和安全审计的核心诉求是回答：究竟是谁、通过哪些路径、在什么时间、对什么数据做了什么操作？
在 Agent 链路里，这件事要比传统应用复杂得多——一次"我帮我自己查请假"可能涉及 1 个用户、1 个客户端、1 个 Agent、N 个下游服务、M 次 Token Exchange。
场景与痛点
合规要求示例：
财务系统要求所有数据访问必须可追溯到自然人。
安全团队要求"任何一次下游 API 调用，都能回答：是哪个前端入口、哪个 Agent 实例、哪条上游令牌触发的。"
监管要求 90 天内对越权访问可定位、可举证。
如果只看下游访问日志的"用户 = 小王"，并不足以满足上述要求——还需要知道这次"小王"的请求是经由哪个 Agent、哪个客户端发起的。
解决方案：基于 RFC 8693 的令牌交换（sub 透传 + _idaas_imp 链路 + 交换计数）
阿里云 Agent ID Guard 在出站访问令牌中保留并扩展了三类字段：
字段 | 含义 | 用途 |
| 与入站访问令牌一致的用户唯一标识 | 后端做行级权限、审计；保证身份不丢失 |
| 当前持有令牌的客户端，等于发起 Token Exchange 的 Agent 的 app id | 后端可识别"是哪个 Agent 在调我" |
| 上游来源信息，含上游令牌的 jti 与 client_id | 反向追踪：本次出站访问令牌是基于哪张入站访问令牌、由哪个上游客户端而来 |
| 交换深度计数，每经一次 Token Exchange +1 | 限制无限委派；可在 Agent ID Guard 侧对深度做策略性拒绝 |
审计溯源介绍
出站访问令牌中包含了入站访问令牌的令牌 ID 和客户端 ID 信息，示意如下：
{
"_idaas_imp": {
"jti": "ATTU…(原入站访问令牌的 jti)…",
"client_id": "app_nfiiybmikzo2fnmabpectnxxxx"
}
}通过这两个字段，结合 Agent ID Guard 的审计日志，可以串联出完整链路：
这条链路无须客户、Agent、下游服务自己拼接，Agent ID Guard 在颁发令牌时已经把"上游证据"写进了下游令牌。
不可冒用：为什么 Agent 不能伪造别人的身份
Agent 即便完全自由地决定"我要去调下游服务"，也不能凭空捏造 sub：
出站访问令牌的签发只能通过 RFC 8693 Token Exchange，且必须提交一张合法的入站访问令牌作为主体令牌。
Agent ID Guard 颁发出站访问令牌时，代表身份的 sub强制取自主体令牌的 sub，并由 Agent ID Guard 用自己的私钥签名，并且所申请下游服务权限与 sub 之前必须存在合法的授权关系。
Agent 的 Client Secret / 私钥仅用于"证明我是 Agent"，不能用来直接签发用户令牌。
下游服务用 Agent ID Guard 的 JWKS 公钥校验 iss、aud、签名后即可信任 sub，无须信任 Agent 自身。
验证效果
验证项 | 预期结果 |
解码出站访问令牌，检查 | 与登录用户一致 |
解码出站访问令牌，检查 | 与发起调用的客户端 app id 一致 |
解码出站访问令牌，检查 | 单次链路通常为 1；多级 Agent 转发时可观测到递增 |
修改 Agent 的代码、伪造 sub 后尝试自行签发"出站访问令牌" | 下游 JWKS 校验签名失败，请求被拒 |
撤销客户端 → Agent 的入站授权后，再尝试 Token Exchange | 失败：底层依赖的入站访问令牌已无法获得 |