セッションタイトル

Agent Identity as the backbone for secure AI innovation

はじめに

2025年は AI Agent にとって圧倒的な進化・浸透となった一年でしたが、AIエージェントの台頭はビジネスにさらなる革新をもたらすと同時に、「アイデンティティ」と「セキュリティ」の概念に大きな変革を迫っています。
セッションの冒頭で、「皆さんはオフィスに入るための入館バッジを持っていますよね。では、皆さんのエージェントはバッジを持っていますか？」という非常に印象的な問いかけがありました。
このブログでは、Google Cloud Next ’26のセッション内容をもとに、AIエージェント時代におけるセキュリティの要となる「エージェント・アイデンティティ」について触れてみたいと思います。

AIエージェントがもたらすアイデンティティの危機とは？

現在のAIは、単なるオートコンプリートのような「副操縦士」から、自律的に意思決定を行いツールを駆使する「超優秀な新入社員（オーケストレーター）」へと進化しました。ここで問題となるのが、エージェントのアイデンティティ管理です。
なぜこれが非常に危険かというと、セッションで語られた驚くべき数値に表れています。現在の市場において、実に約98%のエージェントが単一の長寿命なキーや共有サービスアカウントを使い回しているというのです。
もし悪意のあるユーザーが間接的プロンプトインジェクションなどでエージェントを騙した場合、どうなるでしょうか。例えるなら、「全フロアに入れるマスターキー」を持った新入社員が、外からドアを破壊されるのではなく、住人を騙すことで中から鍵を開けさせ、社内のあらゆる機密データを外部に持ち出せる状態になっているようなものです。誰がどのリソースにアクセスしたか追跡できず、攻撃者に権限を奪われ悪用（借用）されるリスクが極めて高くなります。
過去のワークロード認証で犯した「長寿命なキーの共有」や「サービスアカウントの使い回し」という負の遺産を、新しいAIエージェントの時代で繰り返してはなりません。

Google Cloud Agent Identityとは？

この課題に対処するため、Google Cloudは「Identity-First Security Stack」の中核として、エージェント専用の識別子である「Agent Identity」を提供しています。

Agent Identityの最大の特徴は、SPIFFE（X.509証明書）ベースでランタイムに強力にアテステーション（紐付け）される点です。これにより、エージェントが起動する際に動的に証明書が発行され、そのランタイムでしか使用できません。わかりやすく言えば、入館バッジが「本人の指紋」と強固に紐づいており、絶対に他人に貸し借り（権限の借用）ができない仕組みになっているようなイメージです。

デモで見る：Agent Identityを用いた安全なアクセス管理

セッションでは、実際にどのように安全なアクセス管理が実現されるのか、3つの検証デモを交えて解説いただきました。

1. BigQueryへのアクセスと固有IDの確認

まずは、シンプルなエージェントをデプロイし、BigQueryデータセットへアクセスさせる検証です。
Agent Registryでエージェントを作成し、他のエージェントと共有されない固有の「Agent ID」を取得します。
このAgent IDに対し、IAMポリシーでBigQueryへのアクセス権限を付与します。
エージェントのプレイグラウンドから「BigQueryのデータセットをリストアップして」と指示します。
エージェントは正しくツールを使用し、データセットをリストアップしました。
開発者視点では、アプリケーションのクレデンシャルコードを変更する必要はありません。しかし裏側では、クライアントライブラリがAgent Identityを検知し、X.509証明書に紐づいたバウンドトークンを取得しています。万が一トークンが流出しても、他の環境からは利用できない仕組みになっています。

2. Agent Auth ManagerによるOAuth連携


次に、エージェントがエンドユーザーの代理としてSalesforceやSlackにアクセスするケースの検証です。
Agent Registryの管理画面から「Auth Provider」を作成し、OAuthサーバーの標準的な設定（Client IDやSecret等）を登録します（Terraformでも設定可能です）。
アプリケーションコード内に、作成したAuth Providerの名前を紐付けます。
Cloud Runで動作するアプリケーションからエージェントに話しかけます。
サインインボックス（ポップアップ）が開き、エンドユーザーである私自身の認証情報が求められます。
同意すると、クレデンシャルが「Agent Auth Manager」というセキュアなVaultに保存され、エージェントがエンドユーザーの代理として安全にタスクを実行できました。

3. Principal Access Boundary (PAB)によるアクセス境界の強制

最後に、Identity-centricな多層防御であるPrincipal Access Boundary（PAB）を利用し、エージェントの行動範囲を制御する検証です。
初期状態のエージェントに対し、別プロジェクトのCloud Storageバケットのリストを取得するプロンプトを投げます（この時点ではリストが表示されてしまいます）。
組織の管理者が、Principal Access Boundaryを設定し、「Agent Identityはこのプロジェクト内のGCSバケットにしかアクセスできない」というポリシーを定義します。
再度、エージェントに別プロジェクトのバケットへアクセスするよう指示します。
ポリシーによりアクセスがブロックされ、エージェントの権限範囲が正しく制限されたことが確認できました。

開発者のハマりポイントと気づき

開発者にとって「Agent Auth ManagerによるOAuth連携」の箇所は非常に大きな気づきとなるはずです。
エージェント開発者がOAuth連携を自力で実装しようとすると、エンドユーザーの同意取得、リフレッシュトークンの管理、シークレットの安全な保存など、泥臭く複雑なプロセスに直面します。結果として、開発者が独自の抜け道を作ってしまい、セキュリティ管理者の制御から外れた「シャドーIT」を生み出してしまうのが、よくあるハマりポイントです。
Agent Auth Managerを利用すれば、Agent Gatewayで動的にトークンが注入されるため、エージェントのコード自体はクレデンシャルに一切触れることがありません。これは、開発の生産性を落とさずにガバナンスを効かせるという意味で、非常に画期的な仕組みだと実感しました。この点も非常に重要と思います。

まとめ

AIエージェントは我々のシステムを劇的に進化させますが、同時にアイデンティティ管理という新たな課題を突きつけています。Google CloudのAgent IdentityやAgent Auth Manager、そしてPrincipal Access Boundaryのような多層防御の仕組みは、AIエージェントに「適切な権限を持った入館バッジ」を与え、安全に働かせるための強力な基盤となります。
貴社においても、エージェントが強大な権限を持ったまま野放しになっていないか、同様の課題に直面している可能性があります。ぜひ、今日のワークフローのセキュリティを強化するために、これらの機能の活用を検討してみてください。

本ブログが安全な AI Agent 利用の促進に一役立てば幸いです。