G-gen の佐々木です。当記事では、Google Cloud にデプロイした AI エージェントに固有のアイデンティティを付与する Agent Identity の仕組みと、Agent Identity を用いた認証方式について解説します。

概要

Agent Identity とは

Agent Identity は、Google Cloud 上で動作する AI エージェントに SPIFFE 標準に基づく安全なアイデンティティを付与する仕組みです。これにより、エージェントは MCP サーバー、Google Cloud リソース、外部 API、他のエージェントに対して、自身の権限で安全に認証できます。

参考 : Agent Identity overview
参考 : SPIFFE

2026年5月現在、Agent Identity を使用した認証に対応しているエージェント実行基盤は以下の2つです。

Agent Runtime（旧称 Vertex AI Agent Engine）
Gemini Enterprise App

サービスアカウントとの違い

従来、エージェントの実行環境にはサービスアカウントを利用するのが一般的でしたが、この方式ではサービスアカウントが本来意図しない用途で使用される可能性があります。Agent Identity はこの問題を解決するもので、サービスアカウントとは以下の点で異なります。

項目	サービスアカウント	Agent Identity
複数ワークロードでの共有	可能複数のエージェントで同じサービスアカウントを使い回すこともできてしまう	不可エージェント単位で ID が発行される
権限借用（impersonation）	可能別のプリンシパルにサービスアカウントの借用（なりすまし）を許可することもできてしまう	不可エージェント自身以外は ID を使用できない
長期キーの手動生成	可能サービスアカウントキーはデフォルトで有効期限がなく、漏洩した場合は無効化しない限り悪用され続けてしまう	不可
トークンのバインド	なしアクセストークンを入手した第三者がそのまま使用できてしまう	ありトークンが X.509 証明書と紐付き、意図された実行環境以外では使用できない

Agent Identity の基本

SPIFFE 形式の識別子

Agent Identity に対応した環境にエージェントをデプロイすると、エージェントに固有の SPIFFE ID が自動で割り当てられます。Agent Identity が付与する ID は SPIFFE ID と呼ばれ、書式は以下のとおりです。

spiffe://<トラストドメイン>/resources/<サービス名>/<リソースパス>

IAM ポリシーで SPIFFE ID を参照する際は、プレフィックスとして spiffe:// ではなく principal:// もしくは principalSet:// を使用します。

対象	識別子
単一エージェント（Agent Runtime）	`principal://agents.global.org-<組織ID>.system.id.goog/resources/aiplatform/projects/<プロジェクト番号>/locations/<ロケーション>/reasoningEngines/<エンジンID>`
単一エージェント（Gemini Enterprise）	`principal://agents.global.org-<組織ID>.system.id.goog/resources/discoveryengine/projects/<プロジェクト番号>/locations/global/collections/default_collection/engines/<アプリID>`
プロジェクト内の全エージェント	`principalSet://agents.global.org-<組織ID>.system.id.goog/attribute.platformContainer/aiplatform/projects/<プロジェクト番号>`
組織内の全エージェント	`principalSet://agents.global.org-<組織ID>.system.id.goog/*`

エージェント認証情報

Agent Identity を有効化したエージェントには、24時間有効な X.509 証明書が自動でプロビジョニングされます。エージェントはこの証明書を使用して Google Cloud アクセストークンを取得します。

デフォルトで Context-Aware Access ポリシーが適用され、DPoP（Demonstrable Proof of Possession）と mTLS の使用が強制されます。これによりアクセストークンが X.509 証明書にバインドされ、エージェントの実行環境以外では使用できない仕組みになっています。

参考 : RFC 9449: OAuth 2.0 Demonstrating Proof-of-Possession (DPoP)

セキュリティとガバナンス

Agent Identity では、Google Cloud の各種セキュリティ関連サービスとの統合により、認証情報の保護とアクセス制御のための多層的な仕組みが提供されています。

機構	内容
Context-Aware Access	デフォルトで Google マネージドのポリシーが適用され、DPoP と mTLS により証明書にバインドされたトークンを保護する（前述）
IAM ポリシー	Allow ポリシー / Deny ポリシーによる標準的なアクセス制御をエージェントの ID に適用できる
プリンシパルアクセス境界ポリシー	他の IAM 権限付与にかかわらず、エージェントがアクセスできるリソースの範囲を制限できる
VPC Service Controls（プレビュー）	サービス境界の Ingress / Egress ルールでエージェントの ID を条件に指定できる

認証方式

サポートされる認証方式

エージェントが「何に対して」「どの権限で」認証するかによって、選択する方式が変わります。Agent Identity でサポートされる方式は以下のとおりです。

方式	権限タイプ	認証対象	主な用途
クラウドベースの ID	エージェント自身	Google Cloud	Google Cloud の他サービスへアクセスする
3-legged OAuth（プレビュー）	ユーザー委任	外部ツール・サービス	ユーザーの同意を得て、その代理で Jira や GitHub などにアクセスする
2-legged OAuth（プレビュー）	エージェント自身	外部ツール・サービス	ユーザー同意なしにエージェント自身の資格情報で認証する
API キー（プレビュー）	エージェント自身	外部ツール・サービス	API キーで認証する外部サービスにアクセスする
HTTP Basic Auth	エージェント自身	外部ツール・サービス	非推奨（平文パスワード）

5つの方式はいずれもエージェントに付与された SPIFFE ID を前提としますが、その使われ方が異なります。

Google Cloud へのアクセス（クラウドベースの ID）では、Agent Identity が発行する SPIFFE ID と X.509 証明書そのものが資格情報となり、エージェントの SPIFFE ID に IAM ロールを付与するだけで利用できます。一方、外部ツールへの 3-legged OAuth・2-legged OAuth・API キーの3つの方式では、Agent Identity を起点に、後述する認証マネージャーに保管された外部サービス用の認証情報を取り出して使います。

認証マネージャー

Agent Identity 認証マネージャーは、外部サービスへの認証情報（API キー、OAuth クライアント ID / シークレット、エンドユーザー OAuth トークン）を Google マネージドのボールトに保管し、エージェントの実行時に自動で注入する仕組みです。エージェント開発者がコード内に秘匿情報をハードコードしたり、自前で安全に保管したりする必要がなくなります。

ボールトに保管された認証情報はすべてエージェントの SPIFFE ID に帰属する形で管理されるため、どのエージェントがどの認証情報を使用したかを IAM ポリシーと監査ログの両方で追跡できます。

認証プロバイダー

認証プロバイダーは、認証マネージャーが管理する認証情報を登録するためのリソースで、認証先のサービスごとに作成します。

認証マネージャーによってエージェントが外部サービスにアクセスする際の流れは以下のとおりです。

エージェントの SPIFFE ID と認証先のサービスの情報を元に、対応する認証プロバイダーが特定される
認証プロバイダーに紐付く認証情報がボールトから取り出される
エージェントに認証情報が注入される
エージェントが注入された認証情報を使用して外部サービスにアクセスする

認証プロバイダーは認証方式ごとに以下の3種類があり、いずれもプロジェクト内、ロケーション単位で管理されます。

種類	認証対象の例	ユーザー同意	特徴
3-legged OAuth 認証プロバイダー	Jira、GitHub などの外部 SaaS	必須	ユーザーの代理でアクセスする。認証マネージャーが同意画面へのリダイレクトとトークン保管を仲介する
2-legged OAuth 認証プロバイダー	ServiceNow、Salesforce など	不要	エージェント自身のアイデンティティでクライアント認証情報を交換する
API キー認証プロバイダー	Google Maps API など	—	API キーを Google マネージドのボールトに保管し、コードへのハードコードを避けられる

作成した認証プロバイダーをエージェントから使用するには、エージェントの SPIFFE ID に IAM Connector User（roles/iamconnectors.user）ロールを付与します。

その他、具体的な登録手順やエージェントからの使用方法は、以下の公式ドキュメントを参照してください。

参考 : Authenticate using 3-legged OAuth with auth manager
参考 : Authenticate using 2-legged OAuth with auth manager
参考 : Authenticate using API key with auth manager
参考 : Manage Agent Identity auth providers

Agent Identity の設定例

ここでは、最も基本的なクラウドベースの ID で Google Cloud のサービスにアクセスする方式（認証マネージャー / 認証プロバイダーの登録が不要な方式）の例を示します。

Agent Identity を有効化するには、エージェントをデプロイする際に、config.identity_type として AGENT_IDENTITY を指定します。Agent Runtime の場合は、client.agent_engines.create() を使用する際に config に以下を含めます。

import vertexai
from vertexai import types
from vertexai.agent_engines import AdkApp
  
client = vertexai.Client(
    project="PROJECT_ID",
    location="LOCATION",
    http_options=dict(api_version="v1beta1")
)
  
app = AdkApp(agent=agent)
  
# 新規作成するエージェントで Agent Identity を有効化する
remote_app = client.agent_engines.create(  
    agent=app,
    config={
        "identity_type": types.IdentityType.AGENT_IDENTITY,  # Agent Identity を有効化
        "requirements": ["google-cloud-aiplatform[agent_engines,adk]"],
    },
)

既存のエージェントを更新して Agent Identity を有効化する場合は、update() を使用します。

# 既存のエージェントで Agent Identity を有効化する
remote_app = client.agent_engines.update(
    name=resource_name,
    config={
        "identity_type": types.IdentityType.AGENT_IDENTITY,
    },
)

エージェントには projects/<プロジェクト番号>/locations/<ロケーション>/reasoningEngines/<エンジンID> 形式のリソース名と、これに対応する SPIFFE ID が自動で割り当てられます。

Agent Runtime のエンジン ID は、コンソールから確認できるほか、以下のようなコマンドを使用して確認できます。

# Agent Runtime のエンジン ID を確認する
$ curl -X GET \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    "https://<ロケーション>-aiplatform.googleapis.com/v1/projects/<プロジェクトID>/locations/<ロケーション>/reasoningEngines" \
    | jq -r '.reasoningEngines[] | select(.displayName == "<エージェントの表示名>") | .name | split("/") | last'

例として、エージェントから Cloud Run サービスを呼び出すために、対象の Cloud Run サービスに roles/run.invoker ロールを付与するコマンドを以下に示します。エージェントの SPIFFE ID は principal:// プレフィックスで指定します。

# エージェントの SPIFFE ID に Cloud Run の呼び出し権限を付与する
$ gcloud run services add-iam-policy-binding <Cloud Run サービス名> \
    --region=<リージョン> \
    --member="principal://agents.global.org-<組織ID>.system.id.goog/resources/aiplatform/projects/<プロジェクト番号>/locations/<ロケーション>/reasoningEngines/<エンジンID>" \
    --role="roles/run.invoker"