Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

驗證 AI 代理

將代理部署至 Cloud Run 時，您可以為代理提供身分，讓代理與 API 和其他代理通訊時，能夠安全地進行驗證。

向 Google Cloud API、其他代理程式和工具進行驗證

如果 Cloud Run 工作負載設定為 agent-identity 身分類型，系統會以以下格式提供受系統管理的身分：

principal://agents.global.org-ORGANIZATION_ID.system.id.goog/resources/run/projects/PROJECT_NUMBER/locations/REGION/services/SERVICE_NAME

如果專案不屬於任何組織，格式會使用專案編號：

principal://agents.global.project-PROJECT_NUMBER.system.id.goog/resources/run/projects/PROJECT_NUMBER/locations/REGION/services/SERVICE_NAME

與 API、其他代理程式或工具通訊時，您可以使用這個身分安全地驗證代理程式。 Google Cloud

驗證 Google Cloud API

代理可以透過指派的代理身分，使用從 Cloud Run 中繼資料伺服器擷取的存取權杖，向Google Cloud Vertex AI、Cloud Storage 和其他Google Cloud 產品等 API 進行驗證。

將適當的 IAM 角色授予代理的主體，例如：
- 授予 Vertex AI 存取權：
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="AGENT_PRINCIPAL" \
    --role="roles/aiplatform.user"
```
- 授予其他 Google Cloud API 的存取權：
  
  在目標資源上授予 AGENT_PRINCIPAL 必要角色，例如在 Cloud Storage bucket 上授予 roles/storage.objectViewer。詳情請參閱「使用應用程式預設憑證驗證」。
更改下列內容：
- PROJECT_ID：您的 Google Cloud 專案 ID。
- AGENT_PRINCIPAL：代理程式的身分，例如 principal://agents.global.org-ORGANIZATION_ID.system.id.goog/resources/run/projects/PROJECT_NUMBER/locations/REGION/services/AGENT_NAME。
在代理程式應用程式程式碼中，使用標準的 Google Cloud 用戶端程式庫。用戶端程式庫會自動使用應用程式預設憑證 (ADC)，從中繼資料伺服器擷取短期存取權杖。

或者，您也可以在容器內從中繼資料伺服器手動擷取存取權杖：
```
curl -s -H "Metadata-Flavor: Google" \
"http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"
```

向 Cloud Run 上的其他代理進行驗證

當代理程式需要呼叫 Cloud Run 上代管的其他代理程式 (例如代理程式對代理程式 (A2A))，請使用 JSON Web Token (JWT) 身分符記進行驗證，該符記會由 Cloud Run 的內建 roles/run.invoker IAM 檢查驗證：

在目標 Cloud Run 服務上，將 roles/run.invoker 角色授予呼叫端代理程式的身分：
```
gcloud run services add-iam-policy-binding TARGET_SERVICE_NAME \
    --member="CALLER_AGENT_PRINCIPAL" \
    --role="roles/run.invoker" \
    --region=REGION
```
更改下列內容：
- TARGET_SERVICE_NAME：目的地 Cloud Run 代理程式服務的名稱。
- CALLER_AGENT_PRINCIPAL：呼叫代理程式的身分。
- REGION：目標服務的 Google Cloud 區域。

權杖驗證選項

Cloud Run 支援兩種身分識別權杖驗證方法：

未繫結的權杖：中繼資料伺服器產生的標準目標對象繫結身分權杖。這是服務對服務和代理程式對代理程式驗證的預設機制。
繫結權杖：使用 mTLS 在權杖和工作負載的憑證之間提供密碼編譯繫結。如要使用繫結權杖，呼叫用戶端會在要求中提供其葉節點憑證鏈結。

擷取未繫結的 ID 權杖

在呼叫代理程式容器中，以目標服務的網址做為目標對象，擷取身分識別權杖：
```
TOKEN=$(curl -s -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=TARGET_SERVICE_URL")
```
將 TARGET_SERVICE_URL 換成目的地 Cloud Run 服務的網址，例如 https://target-agent-1234567890.us-central1.run.app。
在 Authorization 標頭中加入權杖，然後將要求傳送至目標服務：
```
curl -H "Authorization: Bearer $TOKEN" \
  TARGET_SERVICE_URL/endpoint
```

擷取繫結的 ID 權杖 (mTLS)

在呼叫代理程式容器中，讀取葉子憑證鏈，並使用 POST 要求向中繼資料伺服器要求繫結權杖：

CERT_PATH="/var/run/secrets/workload-spiffe-credentials/certificates.pem"
JSON_PAYLOAD=$(jq -n --arg certs "$(cat $CERT_PATH)" '{"certificate_chain": $certs}')

TOKEN=$(curl -s -X POST \
    -H "Metadata-Flavor: Google" \
    -H "Content-Type: application/json" \
    -d "$JSON_PAYLOAD" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=TARGET_SERVICE_MTLS_URL")

呼叫目標服務的雙向 TLS 端點，並在 TLS 握手期間提供工作負載憑證：

KEY_PATH="/var/run/secrets/workload-spiffe-credentials/private_key.pem"

curl --cert $CERT_PATH \
    --key $KEY_PATH \
    -H "Authorization: Bearer $TOKEN" \
  TARGET_SERVICE_MTLS_URL/endpoint

Python 範例

如果您編寫以 Python 為基礎的代理程式碼，標準 Google Cloud 用戶端程式庫預設會在有憑證時，自動要求繫結權杖。如需手動發出 HTTP 要求：

import os
import requests
import google.auth
from google.auth.transport.requests import Request
from google.oauth2 import id_token

# Target agent's mTLS URL
target_mtls_url = "TARGET_SERVICE_MTLS_URL"

# 1. Fetch the ID token.
# google-auth automatically requests a bound ID token via POST because
# the platform configures the workload certificate environment variables.
auth_req = Request()
token = id_token.fetch_id_token(auth_req, target_mtls_url)

# 2. Make the HTTP call over mTLS, presenting the workload certificates.
cert_path = "/var/run/secrets/workload-spiffe-credentials/certificates.pem"
key_path = "/var/run/secrets/workload-spiffe-credentials/private_key.pem"

response = requests.get(
    target_mtls_url,
    headers={"Authorization": f"Bearer {token}"},
    cert=(cert_path, key_path)
)
print(response.text)

將 TARGET_SERVICE_MTLS_URL 換成目的地 Cloud Run 服務的 mTLS 網址，例如 https://target-agent-12345.us-central1.mtls.run.app。

向 Cloud Run 上的 MCP 伺服器進行驗證

如要連線至 Cloud Run 上代管的 MCP 伺服器或工具，請使用 --functional-type=mcp-server 識別碼，在 Agent Registry 中自動註冊 MCP 伺服器。

如果 MCP 伺服器只供在 Cloud Run 上執行的其他代理程式存取，請使用內建的 IAM 呼叫端檢查。讓服務專員使用標準執行呼叫器政策，以原生方式進行通訊：

gcloud run services add-iam-policy-binding MCP_SERVICE_NAME \
    --member="CALLING_AGENT_PRINCIPAL" \
    --role="roles/run.invoker" \
    --region=REGION

更改下列內容：

MCP_SERVICE_NAME：代管 MCP 伺服器的目的地 Cloud Run 服務名稱。
CALLING_AGENT_PRINCIPAL：呼叫 MCP 伺服器的代理主體身分。例如：serviceAccount:my-agent@my-project.iam.。
REGION：部署 MCP 伺服器的 Google Cloud 區域。

授予 run.invoker 角色後，通話代理程式即可如「權杖驗證選項」一節所述，擷取身分權杖。

如要瞭解如何使用 IAP 保護 MCP 伺服器，以供 CLI 和程式輔助 SDK 存取，請參閱「驗證 MCP 伺服器」。

代表使用者進行驗證

當代理代表使用者存取外部工具和服務時，可以使用已佈建的代理身分，管理與 MCP 伺服器和外部端點的驗證。

如要安全處理複雜的授權工作流程，例如三足式 OAuth (3LO) 同意聲明、雙足式 OAuth (2LO) 和 API 金鑰，請設定 Agent Identity Auth Manager。

如需將這些驗證管理員繫結至工具組的操作說明，請參閱「驗證工具和資源」。