Agent Identity は、SPIFFE 標準に基づいて、各エージェントに厳密に証明された暗号 ID を提供します。Agent Identity を使用すると、エージェントは MCP サーバー、クラウド リソース、エンドポイント、他のエージェントに対して安全に認証を行い、エージェント自身またはエンドユーザーの代理として動作できます。Agent Identity は、エージェント独自の認証情報と Agent Identity Auth Manager を使用します。認証マネージャーを使用すると、認証プロバイダを作成して管理できます。認証プロバイダは、API キー、OAuth クライアント ID、OAuth クライアント シークレット、委任されたエンドユーザー OAuth トークンの取得、管理、保護に使用される特定の構成です。
サービス アカウントとは異なり、エージェント ID はデフォルトで複数のワークロードで共有されず、権限を借用できません。また、デベロッパーは有効期間の長いサービス アカウント キーを生成できません。 Google Cloud用に生成されたアクセス トークンは、トークンの盗難を防ぐために、エージェントの一意の X.509 証明書に暗号的にバインドされます。
Agent Identity は、Agent Registry および Agent Gateway と連携して、AI エージェントのセキュリティとガバナンスを強化します。Agent Identity は暗号化された ID をプロビジョニングして認証情報を管理し、Agent Registry は環境内のツールと宛先をカタログ化し、Agent Gateway はエージェントがそれらの宛先を呼び出すときにアクセス ポリシーを適用してネットワーク トラフィックを検査します。
次のサービスは、エージェント ID をサポートしています。
- Gemini Enterprise Agent Platform Runtime（Agent Runtime）
- Gemini Enterprise
- Cloud Run
認証モデル
さまざまなツールやサービスで認証を行うため、Agent Identity は複数の認証モデルをサポートしています。エージェントが使用するモデルは、ターゲット リソースが提供する認証方法と、エージェントが独自の権限で動作するのか、エンドユーザーの代理として動作するのかによって異なります。
| 権限 | 認証方法 | ターゲット リソース | ユースケースとソリューション |
|---|---|---|---|
| ユーザー委任権限 | OAuth 2.0（3-legged） | 外部ツールとサービス | エージェントが特定のユーザーに代わって操作する場合（ユーザーの Jira タスクや GitHub リポジトリにアクセスする場合など）。Agent Identity Auth Manager で 3-legged OAuth 認証プロバイダを構成して、ユーザーの同意とトークンを管理します。詳細については、認証マネージャーで 3-legged OAuth を使用して認証するをご覧ください。 |
| エージェント自身の権限 | クラウドベースの ID（エージェント ID） | Google Cloud サービス | Google Cloud でホストされているエージェントが、独自の ID を使用して他の Google Cloud サービスにアクセスする必要がある場合。詳細については、エージェント独自の ID を使用して Google Cloud に対する認証を行うをご覧ください。 |
| クラウドベースの ID（OIDC ID トークン） | 外部ツールとサービス | Google Cloud でホストされているエージェントが、独自の ID と OpenID Connect（OIDC）ID 連携を使用して、外部バックエンド、カスタム API、またはサードパーティのクラウド プラットフォームに対して認証する必要がある場合。詳細については、エージェント独自の ID を使用して外部サービスを認証するをご覧ください。 | |
| OAuth 2.0（2-Legged） | 外部ツールとサービス | OAuth をサポートする外部サービスを使用したマシン間認証におすすめです。Agent Identity Auth Manager で 2-legged OAuth 認証プロバイダを構成して、クライアント認証情報とアクセス トークンを処理します。詳細については、認証マネージャーで 2-legged OAuth を使用して認証するをご覧ください。 | |
| API キー | 外部ツールとサービス | 認証に暗号鍵またはパスワードが必要な外部サービスの場合。Agent Identity Auth Manager で API キー認証プロバイダを構成して、キーを安全に保存して管理できるようにします。詳細については、認証マネージャーで API キーを使用して認証するをご覧ください。 | |
| HTTP 基本認証 | 外部ツールとサービス | 平文のパスワードを使用します。この方法はおすすめしません。API キーと同様にパスワードを保存できます。詳細については、認証マネージャーで API キーを使用して認証するをご覧ください。 |
ID 委任アーキテクチャ
サービス アカウントの権限借用に依存せずに、人間のユーザー、自律型ワークロード、外部ツールにわたって信頼境界を適用するために、Agent Identity は 3 つの ID 委任フレームワークを使用します。このフレームワークは、環境全体で 3 つの異なる ID コンテキストを分離して調整します。
- ユーザー ID: 開始するエンドユーザーの ID。Google Identity または連携 Workforce Identity プロバイダ（IdP）を使用した標準の OAuth 2.0 または OpenID Connect（OIDC）で認証されます。
- エージェント ID: デプロイされたエージェントの一意の暗号的に証明された SPIFFE ID と自動プロビジョニングされた X.509 証明書。これは、エージェントが独自の権限で動作していることを表します。
- 委任された ID: エージェントが、Agent Identity Auth Manager によって仲介されたスコープ付き 3-legged OAuth（3LO）認証情報を使用して、開始した人間のユーザーに代わって行動する場合の、結合された権限コンテキスト。
次の図は、ユーザー ID、エージェント ID、委任された ID が、上り（内向き）、ランタイム、下り（外向き）の信頼境界を越えてどのように相互作用するかを示しています。
プラットフォームが信頼境界を越えて各 ID レイヤを評価して伝播する方法については、ID 委任アーキテクチャをご覧ください。
コア コンポーネント
Agent Identity には、安全な認証と認可を実現するためのいくつかの主要コンポーネントが含まれています。
SPIFFE ベースの ID
各エージェントには、SPIFFE 標準に基づいて一意の ID 文字列（SPIFFE ID）が割り当てられます。この ID は、エージェントのライフサイクルに関連付けられ、エージェントがホストされているリソース URI に直接マッピングされます。
ID の形式は次のとおりです。
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 を使用する場合、プリンシパル ID は次の形式になります。
principal://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH例:
- Vertex AI Agent Engine（組織）:
principal://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent - Vertex AI Agent Engine（組織のないプロジェクト）:
principal://agents.global.proj-9876543210.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
識別子には次のものが使用されます。
TRUST_DOMAIN: リソース階層の信頼ドメイン。- 組織内のプロジェクトの場合:
agents.global.org-ORGANIZATION_ID.system.id.goog - 組織のないプロジェクトの場合:
agents.global.proj-PROJECT_NUMBER.system.id.goog
- 組織内のプロジェクトの場合:
SERVICE: Google Cloud サービスの略称（aiplatform、discoveryengineなど）。RESOURCE_PATH: エージェントをホストするリソースのフルパス。
エージェント自体がプリンシパルであるため、この識別子に直接権限を付与して、エージェントがアクセスできるリソースを制御します。
ID と権限のライフサイクル
エージェント ID の IAM バインディングを管理する必要があります。エージェントを削除しても、そのプリンシパルを参照する IAM バインディングは削除されません。これらのバインディングは、無効な権限付与としてポリシーに残ります。エージェントのデコミッションの一環として、手動で削除する必要があります。
エージェントの ID は、エージェントをホストするリソースの ID（reasoningEngines リソース ID など）から派生します。エージェントを削除して代替エージェントをデプロイすると、表示名、コード、構成が同じであっても、新しいエージェントには新しいリソース ID が割り当てられ、新しいプリンシパル識別子が割り当てられます。以前の ID を参照していた既存の IAM バインディングは、新しいプリンシパルには適用されません。新しいプリンシパルに必要なロールを付与する必要があります。
エージェントの認証情報
エージェント認証情報は、エージェントの ID の暗号証明を提供します。このシステムは、X.509 証明書、 Google Cloud アクセス トークン、OIDC ID トークンをサポートしています。X.509 証明書が自動プロビジョニングされ、エージェントで管理されるため、より強力な認証をサポートできます。
これらの X.509 証明書は、Google が管理するルート認証局（CA）にチェーンされます。パブリック デフォルト CA 証明書は、次のエンドポイントで確認できます。
- すべてのリージョン:
https://www.gstatic.com/gcp_default_ca_certs/default_ca_certs.pem（すべてのリージョンのデフォルトの CA 証明書） - リージョンごと: サポート対象の地域の
https://www.gstatic.com/gcp_default_ca_certs/REGION/public_cert.pem（例:us-east1のデフォルトの CA 証明書）
デフォルトでは、エージェント ID は、 Google Cloud API と直接通信するときに X.509 証明書を使用した相互 TLS（mTLS）を使用します。エージェントが Agent Gateway を介してやり取りする場合、Demonstrating Proof of Possession（DPoP）も使用して、エンドツーエンドのセキュリティのために二重バインド認証情報を作成します。この二重バインディングは、エージェントがゲートウェイへのファーストパーティ アクセスに mTLS を使用して認証し、ゲートウェイを越えたやり取りに DPoP を使用することを意味します。
Agent Identity Auth Manager
Agent Identity Auth Manager は、エージェントのアウトバウンド ツール認証を簡素化する、一元化された認証情報ボールトおよび認証ブローカーです。エージェントは、API キーまたは OAuth クライアント ID とシークレットを使用して認証することも、エンドユーザー アクセス トークンを使用して OAuth 委任を介してユーザーの代わりに認証することもできます。認証マネージャー内で、特定のサードパーティ アプリケーションの認証タイプと認証情報を定義する認証プロバイダを構成します。
Agent Identity Auth Manager へのアクセスは IAM に則って管理され、エージェントは独自の Agent SPIFFE ID を使用して Auth Manager に対して認証を行います。すべてのエンドユーザー アクセス イベントは、エージェントの SPIFFE ID にも関連付けられるため、ガバナンスが容易になります。
Agent Identity Auth Manager は、ユーザーのログインと同意を求めるダイアログを開くなど、OAuth 認証情報の取得を自動化します。また、エンドユーザーのアクセスを可視化し、アクセスを取り消すことができるため、ユーザーに委任された権限のガバナンスを強化できます。
詳細については、Agent Identity Auth Manager の概要をご覧ください。
セキュリティとガバナンス
エージェント ID は、IAM、プリンシパル アクセス境界（PAB）、VPC Service Controls などの Google のポリシー システムと完全に統合されており、セキュリティとガバナンスを強化できます。また、監査ロギングと統合して、エージェントが自身として動作しているときと、エンドユーザーの代わりに動作しているときの両方で、説明責任を確保し、明確な監査ログを提供します。
- コンテキストアウェア アクセス: デフォルトでは、Google が管理するコンテキストアウェア アクセス ポリシーにより、mTLS と DPoP トークン バインディングを適用して、エージェント認証情報を保護します。このアプローチにより、証明書にバインドされたトークンが信頼できるランタイム環境外でリプレイされるのを防ぐことができます。
- IAM の統合: 標準の IAM 許可ポリシーと拒否ポリシーをサポート。
- プリンシパル アクセス境界（PAB）: プリンシパル アクセス境界ポリシーは、エージェントが持つ他の権限に関係なく、エージェントがアクセスできるリソースを制限します。エージェント ID に適用されたプリンシパル アクセス境界ポリシーは、アウトバウンド（下り（外向き））呼び出しの一部として評価されます。プリンシパル アクセス境界ポリシーの対象となるエージェント ID は、これらのポリシーで指定されたリソースにのみアクセスできます。これにより、エージェントは指定された境界に厳密に分離されます。
- VPC Service Controls: 境界保護とプリンシパルの使用のサポート:
- 境界保護: Agent Identity API（
agentidentity.googleapis.com）と Agent Identity Credentials API（agentidentitycredentials.googleapis.com）をサービス境界に追加して、これらの API へのアクセスを制御できます。サービス境界内でこれらの API を使用するには、クライアントは制限付き VIP（restricted.googleapis.com）を介してリクエストをルーティングする必要があります。 - 上り（内向き）ルールと下り（外向き）ルール: 上り（内向き）ルールと下り（外向き）ルールでエージェント ID をプリンシパルとして使用し、サービス境界で保護されたリソースへのアクセスを許可できます。
- 境界保護: Agent Identity API（
Agent Identity の仕組み
Agent Identity は、セキュリティを強化するために設計されたワークフローを通じて、エージェントのアクションを認証および認可します。
- ID の割り当て: エージェントをデプロイすると、 Google Cloudは一意の SPIFFE ID と X.509 証明書を割り当てます。各 X.509 証明書は 24 時間有効で、 Google Cloudはセキュリティを維持するために自動的に証明書を最新の状態に保ちます。
- 認証情報の取得: エージェントが認証情報を取得する方法は、アクセスしようとしている対象によって異なります。以下に例を示します。
- Google Cloud サービスにアクセスする: エージェントはバインドされたアクセス トークンをリクエストします。このトークンは、トークンの盗難を防ぐために、エージェントの一意の X.509 証明書に暗号的にバインドされています。詳細については、セキュリティとガバナンスをご覧ください。
- 外部ツールにアクセスする: 外部サービスに直接認証するために、エージェントは OIDC ID トークンをリクエストします。認証プロバイダから保存済みの認証情報（API キーや OAuth トークンなど）を取得するために、エージェントは Agent Identity Auth Manager を使用します。これは、ユーザー委任権限とエージェント独自の権限の両方をサポートしています。
エージェント ID のメリット
Agent Identity は、標準のサービス アカウントよりもセキュリティを強化します。
- 強力な分離: サービス アカウントとは異なり、エージェント ID はデフォルトで複数のワークロードで共有されず、なりすましはできません。また、デベロッパーは有効期間の長いサービス アカウント キーを生成できません。
- 認証情報のセキュリティ: デフォルトのコンテキストアウェア アクセス ポリシーにより、バインドされたトークンが再生不能になり、トークンの盗難やアカウントの乗っ取りから保護されます。
- 最小権限アプローチ: 共有サービス アカウントではなく、エージェントごとの ID を提供して、過剰な権限を持つエージェントを排除します。
- 摩擦の軽減: 複雑な OAuth フローを自動化し、API キーを管理して、ツールの統合を簡素化します。
- オブザーバビリティの向上: 明確な監査ログを提供します。エージェントがユーザーに代わって操作を行うと、ログにはエージェントとユーザーの両方の ID が表示されます。
制限事項
- Cloud Storage のレガシー バケットロール: エージェント ID にレガシー バケットロール（
storage.legacyBucketReaderなど）を付与することはできません。
次のステップ
ID 委任アーキテクチャの詳細を確認する。
詳しくは、Agent Runtime で Agent Identity を使用するをご覧ください。
エージェントの管理の詳細を確認する。