為在人類使用者、自主工作負載和外部工具之間強制執行信任邊界，而不依賴服務帳戶模擬，代理身分採用三身分委派架構。這個架構會區分並協調環境中的三種不同身分情境：
- 使用者身分：發起端使用者的身分，透過標準 OAuth 2.0 或 OpenID Connect (OIDC) 驗證，並使用 Google Identity 或聯合員工身分識別資訊提供者 (IdP)。
- 代理身分：已部署代理的專屬加密驗證 SPIFFE 身分和自動佈建的 X.509 憑證，代表代理依自身權限執行。
- 委派身分：代理代表發起的人類使用者，使用 Agent Identity 驗證管理工具代理的範圍 3-legged OAuth (3LO) 憑證時，所結合的授權情境。
下圖說明使用者身分、代理身分和委派身分如何在輸入、執行階段和輸出信任邊界之間互動：
在這個架構中，使用者身分會在輸入期間建立呼叫端情境，代理身分會在執行階段邊界內驗證工作負載，而委派身分會在代理代表使用者存取下游服務時，結合這兩項授權。
身分如何跨越信任邊界傳播
當要求跨越這些信任邊界時，平台會評估並傳播每個身分層：
- 用戶端對代理輸入邊界 (使用者身分)：真人使用者會使用 OAuth 2.0 或 OIDC 權杖，向用戶端應用程式驗證身分。流量透過 Agent Gateway 進入時 (在
CLIENT_TO_AGENT輸入模式下)，附加至 Agent Gateway 的授權政策會驗證使用者身分，確認使用者有權叫用目標代理，並將已驗證的使用者情境轉送至執行階段。 - Agent Runtime 和憑證代理 (Agent Identity)：在獨立的執行階段環境中，代理會以自己的 Agent Identity 運作，並使用自動輪替的 24 小時 X.509 憑證。當代理需要下游工具的憑證時，會使用代理身分向 Agent Identity 驗證管理工具進行驗證。
- 自主輸出路徑 (代理身分)：代理自行呼叫 Google Cloud API 或機器對機器端點時，會使用驗證管理員提供的憑證繫結權杖 (由雙向 TLS (mTLS) 和 Demonstrating Proof of Possession (DPoP) 強制執行)、OIDC ID 權杖或 2-legged OAuth (2LO) 憑證進行驗證。IAM 允許和拒絕政策、主體存取邊界 (PAB) 政策，以及情境感知存取權政策，會嚴格根據代理身分評估要求。
- 使用者委派的輸出路徑 (委派身分)：代理代表真人使用者呼叫以使用者為範圍的 Model Context Protocol (MCP) 伺服器或第三方 API 時，驗證管理員會代理經同意的 3LO 使用者權杖，代表委派身分。外送呼叫受代理的輸出政策、委派使用者的權限和同意的 OAuth 範圍控管，稽核記錄會同時記錄代理身分和使用者身分。
身分層比較
下表摘要說明三個身分層如何控管存取權和稽核能力：
| 身分層 | 主體和憑證類型 | 信任邊界和政策強制執行 | 稽核記錄歸因 |
|---|---|---|---|
| 使用者身分 | 使用 OAuth 2.0 或 OIDC 權杖驗證啟動使用者 (Google 帳戶或員工身分主體)。 | 用戶端到代理 (輸入)：Agent Gateway 授權政策會驗證使用者是否能叫用代理並啟動工作階段。 | 將真人使用者身分記錄為叫用代理端點的呼叫者。 |
| 代理身分 | 自主代理工作負載 (代理身分主體) 透過 SPIFFE X.509 憑證 (mTLS 和 DPoP)、OIDC ID 權杖，或驗證管理員提供的 2LO 憑證或 API 金鑰進行驗證。 | 代理到任何位置 (輸出)：IAM 允許、拒絕、主體存取邊界和情境感知存取權政策，會強制規定代理可自行存取哪些 Google Cloud 資源、驗證服務供應商和外部端點。 | 將代理的專屬 SPIFFE 主體記錄為執行身分。 |
| 委派身分 | 代理身分代表同意的人類使用者 (Google 帳戶或員工身分主體)，使用由 Agent Identity 驗證管理工具代理的範圍 3LO 存取權杖。 | 代理到任何位置 (輸出)：強制執行最小權限交集，呼叫必須同時符合代理的輸出管理政策，以及委派使用者的權限和同意的 OAuth 範圍。 | 記錄雙重歸因，同時擷取代理的 SPIFFE 身分和委派的人類使用者。 |
後續步驟
進一步瞭解 Agent Identity。
進一步瞭解如何搭配使用代理身分和 Agent Runtime。
進一步瞭解 Agent Gateway。