Agent Identity 會根據 SPIFFE 標準，為每個代理提供經過嚴格驗證的加密身分。透過代理程式身分，代理程式可以安全地向 MCP 伺服器、雲端資源、端點和其他代理程式進行驗證，代表自己或使用者執行動作。代理身分會使用代理自己的憑證和代理身分驗證管理員。您可以使用驗證管理工具建立及管理驗證供應商，這些供應商是專用設定，用於取得、管理及保護 API 金鑰、OAuth 用戶端 ID、OAuth 用戶端密鑰和委派的 OAuth 終端使用者權杖。
與服務帳戶不同，代理程式身分預設不會由多個工作負載共用，且無法模擬，也不允許開發人員產生長期有效的服務帳戶金鑰。為 Google Cloud產生的存取權杖會以加密方式繫結至代理程式專屬的 X.509 憑證，防止權杖遭竊。
將代理身分與代理閘道和 Gemini Enterprise 搭配使用時，授權管理員會加密使用者憑證 (例如 Gemini Enterprise 連接器佈建的憑證)，並在閘道解密，確保代理永遠無法存取原始憑證。
下列服務支援代理程式身分：
- Gemini Enterprise Agent Platform Runtime (Agent Runtime)
- Gemini Enterprise (預先發布版)
驗證模式
如要使用各種工具和服務進行驗證，Agent Identity 支援多種驗證模型。代理程式使用的模型取決於目標資源提供的驗證方法，以及代理程式是自行授權還是代表使用者。
| 權限 | 驗證方式 | 目標資源 | 應用實例和解決方案 |
|---|---|---|---|
| 使用者委派的授權 | OAuth 2.0 (三足式) (預先發布版) | 外部工具和服務 | 當代理程式代表特定使用者執行動作時 (例如存取使用者的 Jira 工作或 GitHub 存放區)。您可以在代理程式身分驗證管理員中設定三足式 OAuth 驗證供應商，管理使用者同意聲明和權杖。詳情請參閱「使用三足式 OAuth 搭配驗證管理工具進行驗證」。 |
| 代理商的自有授權 | 雲端身分 (代理程式身分) | Google Cloud 服務 | 當 Google Cloud 上代管的代理程式需要使用自己的身分存取其他 Google Cloud 服務時，詳情請參閱使用專員身分驗證。 |
| OAuth 2.0 (雙足式) (預覽版) | 外部工具和服務 | 建議用於與支援 OAuth 的外部服務進行機器對機器驗證。您可以在 Agent Identity 驗證管理工具中設定雙足式 OAuth 驗證供應商，處理用戶端憑證和存取權杖。詳情請參閱「使用雙向 OAuth 搭配驗證管理工具進行驗證」。 | |
| API 金鑰 (預先發布版) | 外部工具和服務 | 需要加密編譯金鑰或密碼才能驗證的外部服務。您可以在 Agent Identity 驗證管理工具中設定 API 金鑰驗證提供者，安全地儲存及管理金鑰。詳情請參閱「使用驗證管理工具，透過 API 金鑰進行驗證」。 | |
| HTTP 基本驗證 | 外部工具和服務 | 使用純文字密碼。我們不建議使用這個方法。您可以儲存密碼，方式與儲存 API 金鑰類似。詳情請參閱「使用 API 金鑰和驗證管理工具進行驗證」。 |
核心元件
代理程式身分包含多個重要元件，共同提供安全驗證和授權。
以 SPIFFE 為基礎的身分
系統會根據 SPIFFE 標準，為每個代理指派專屬身分字串或 SPIFFE ID。這個身分經過嚴格認證，與代理程式的生命週期相關聯，並直接對應至代理程式的資源 URI。
身分證件須符合以下格式：
spiffe://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH例如：
spiffe://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent
在 IAM 允許政策中使用代理程式身分時，主體 ID 格式如下：
principal://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH範例：
- Agent Platform Agent Engine：
principal://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent - Gemini Enterprise：
principal://agents.global.org-123456789012.system.id.goog/resources/discoveryengine/projects/9876543210/locations/global/collections/default_collection/engines/my-test-agent
這些 ID 使用下列項目：
TRUST_DOMAIN：貴機構的信任網域 (例如agents.global.org-123456789012.system.id.goog)。SERVICE： Google Cloud 服務的簡稱 (例如aiplatform或discoveryengine)。RESOURCE_PATH：代管代理程式的資源完整路徑。
由於代理程式本身就是主體，因此您可以直接將權限授予這個 ID，控管代理程式可存取的資源。
代理憑證
代理憑證會提供代理身分的加密證明。系統支援 X.509 憑證和 Google Cloud 存取權杖。系統會在代理程式上自動佈建及管理 X.509 憑證，以支援更強大的驗證機制。
代理身分驗證管理員
代理程式身分驗證管理員是憑證保險箱，可協助保護憑證。代理程式可使用 API 金鑰或 OAuth 用戶端 ID 和密鑰進行驗證，也可以透過 OAuth 委派，使用使用者存取權杖代表使用者驗證。在驗證管理員中，您可以設定驗證提供者，定義特定第三方應用程式的驗證類型和憑證。
代理程式身分驗證管理員的存取權由 IAM 管理，代理程式會使用自己的代理程式 SPIFFE ID 向驗證管理員進行驗證。所有使用者存取事件也都會歸因於代理程式的 SPIFFE ID，方便進行管理。
代理程式身分驗證管理員會自動取得 OAuth 憑證，例如開啟對話方塊，讓使用者登入及同意授權。此外，這項功能還可讓您查看使用者存取權，並撤銷存取權，確保使用者委派的權限受到更完善的控管。
安全性與管理
代理程式身分完全整合了 Google 的政策系統，例如 IAM、主體存取權界線 (PAB) 和 VPC Service Controls，可強化安全性和管理功能。此外，這項功能也整合了稽核記錄，確保責任歸屬，並在代理程式以自身身分或代表使用者執行動作時，提供清楚的稽核記錄。
- 情境感知存取權：根據預設，Google 管理的情境感知存取權政策有助於保護代理程式身分憑證。除了 Agent Gateway 之外，這項政策還會驗證代理程式的存取權杖，強制執行可證明的擁有權證明 (DPoP)。這項政策也會強制使用 mTLS 存取代理閘道。確保憑證繫結權杖只能在預期的受信任執行階段環境中使用。
- 身分與存取權管理整合：支援標準身分與存取權管理允許政策和拒絕政策。
- 主體存取邊界 (PAB)：無論其他權限為何，PAB 都會限制代理程式可存取的資源。
- VPC Service Controls：支援在輸入和輸出規則中使用代理身分 (搶先版)，允許存取受 service perimeter 保護的資源。
代理身分的運作方式
代理程式身分會透過工作流程驗證及授權代理程式動作，有助於提升安全性：
- 指派身分：部署代理程式時， Google Cloud會為代理程式指派專屬 SPIFFE 身分和 X.509 憑證。每個 X.509 憑證的效期為 24 小時，且系統會自動更新憑證，確保安全無虞。 Google Cloud
- 取得憑證：代理程式取得憑證的方法取決於要存取的內容。以下列舉幾個例子：
- 存取 Google Cloud 服務：代理程式會要求繫結的存取權杖。這個權杖會以密碼編譯方式繫結至代理程式的專屬 X.509 憑證，防止權杖遭竊。詳情請參閱「安全性與控管」。
- 存取外部工具：代理會使用代理身分驗證管理員，從驗證提供者擷取必要憑證 (例如 API 金鑰或 OAuth 權杖)。授權管理員同時支援使用者委派的授權和代理程式本身的授權。
代理身分的好處
與標準服務帳戶相比，代理身分可提升安全性。
- 嚴密隔離：與服務帳戶不同，根據預設，代理程式身分不會由多個工作負載共用，且無法模擬，也不允許開發人員產生長期有效的服務帳戶金鑰。
- 憑證安全：預設的情境感知存取權政策會讓繫結的權杖無法重播，有助於防範權杖遭竊和帳戶入侵。將代理程式身分與代理程式閘道和 Gemini Enterprise 搭配使用時，授權管理員會加密使用者憑證 (例如 Gemini Enterprise 連接器佈建的憑證)，並在閘道解密，確保代理程式永遠無法存取原始憑證。
- 最小權限做法：提供每個代理程式的身分，而非共用的服務帳戶，以避免代理程式擁有過多權限。
- 減少摩擦：自動執行複雜的 OAuth 流程，並管理 API 金鑰，簡化工具整合作業。
- 提升可觀測性：提供清楚的稽核記錄。如果服務專員代表使用者採取行動，記錄會顯示服務專員和使用者的身分。
限制
- Cloud Storage 舊版 bucket 角色：您無法將舊版 bucket 角色 (例如
storage.legacyBucketReader) 授予代理程式身分。
後續步驟
- 使用代理程式身分建立代理程式
- 使用代理程式本身的授權進行驗證
- 使用授權管理工具，透過三足式 OAuth 進行驗證
- 使用雙足式 OAuth 和驗證管理員進行驗證
- 使用驗證管理工具，透過 API 金鑰進行驗證
- 管理代理程式身分驗證提供者
- 排解代理身分驗證管理員問題
- SPIFFE 概念