介紹 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 和用戶端識別碼 資訊，示意如下：
{
"_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 | 失敗：底層依賴的入站存取權杖已無法獲得 |