AIエージェントがもたらす新たな「認証の壁」：Ping IdentityがAWS、Google Cloud、Cloudflareでランタイムセキュリティを強化

AIエージェントが企業環境に急速に浸透する中、ある重大なセキュリティの欠落が浮き彫りになっています。それは、クラウドサービスやAPI、エッジインフラを越えて継続的かつ自律的に行動するエージェントにとって、ログイン時の一度限りのID確認では全く不十分だという現実です。

2026年6月16日、Ping Identityはこのギャップを埋めるため、Amazon Web Services（AWS）、Google Cloud、Cloudflareとの一連の統合を発表しました。これにより、同社の**ランタイムアイデンティティ（Runtime Identity）**の強制機能が、AIエージェントが構築・展開・運用されるプラットフォーム上に直接拡張されます 。これは、静的な認証から、エージェントのあらゆるアクションの瞬間における継続的かつコンテキストを考慮した認可へと、実践的に進化する動きを意味します。

根本的な転換：「認証」から「実行時の認可」へ

Ping Identityのアプローチは、一つの基本的な考え方に基づいています。それは、AIエージェントは人間のユーザーとは異なり、単にログインして終わりではないということです。彼らはAPI呼び出しを連鎖させ、ツールにアクセスし、分散システム全体で意思決定を行います。この現実は、エージェントが取るすべてのアクションに対して、ID、委任、ポリシーが実行時に継続的にチェックされるセキュリティモデルを要求します 。

これを実現するため、2026年3月に一般提供が開始されたPingの Identity for AI フレームワークは、AIエージェントを「モノ」としてのファーストクラスの非人間IDとして扱います。このフレームワークは、エージェントの登録とライフサイクル管理、委任された認可のためのOAuth 2.0トークン交換、そして環境をまたいだエージェント活動の一元的な可視化を提供します 。

中核となる技術原則：なりすましではない「委任」

3つの統合すべてに共通する中心技術は、OAuth 2.0トークン交換です。人間のユーザーがエージェントにタスクを委任する際、エージェントは全権限を持ってユーザーを単純になりすますわけではありません。代わりに、Pingのインフラは人間のユーザーのサブジェクトトークンを、新しく権限を縮小したトークンと交換します。この委任トークンは、人間のユーザーのID（actクレーム経由）とエージェント自身のID（may_actクレーム経由）の両方を保持し、後続のすべてのアクションに対して安全な**証拠保全の連鎖（Chain of Custody）**を構築します 。これにより、セキュリティチームは常に「誰が承認したのか」「どのエージェントが実行したのか」「どの範囲の権限を持っていたのか」を追跡できるようになります。

AWS：クラウドワークロード全体でエージェントIDを保護

Ping IdentityのAWSとの統合は、AmazonがAIエージェントと自動化ワークロード向けに特別に構築したID・認証情報管理サービスであるAmazon Bedrock AgentCoreが中心です 。

仕組み：

PingのIDプロバイダー（PingOne, PingOne Advanced Identity Cloud, PingFederate）は、以下の2つの方法で設定できます。

• AgentCore GatewayおよびRuntimeのインバウンドIdPとして：エンドユーザーを認証し、エージェントが後続のリソースに到達する前に提示しなければならない、スコープ付きOAuthトークンを発行します 。
• アウトバウンドの認証情報プロバイダとして：エージェントが長期間有効な認証情報を露出させることなく、サードパーティサービス用のアクセストークンを安全に取得できるようにします 。

具体的な機能：

• ユニークなエージェントID — すべてのAIエージェントは、関連するメタデータとともに一意のIDを受け取ります。管理者は、マルチアカウントのAWS環境全体に最小権限のアクセスポリシーを適用できます 。
• リアルタイムガバナンス — エージェントがAPIやツール、データストアと連携するたびに認可が動的に強制され、機密データや規制対象ワークロード、運用制限に関する企業ポリシーにエージェントの動作を準拠させます 。
• モニタリング — Amazon Bedrock AgentCoreはインバウンド/アウトバウンドの認証ログを提供します。また、Pingのエージェント検出機能により、企業はAWSのデジタルエコシステム全体でAIエージェントを発見、追跡、監査できます 。

Google Cloud：エージェントとツール間通信のインライン認可

Google Cloudとの統合は、AIエージェントと、それらが呼び出すツールやMCPサーバー間のトラフィックという、異なるレイヤーに焦点を当てています。Ping IdentityはGoogle Cloud Agent Gatewayと統合します。これは、エージェントからツールへのリクエストを傍受し、宛先に到達する前にポリシーを強制するマネージド制御ポイントです 。

仕組み：

PingOne Authorizeは、ext_proc統合を介してAgent Gatewayのトラフィックフローにインラインで配置されます。エージェントからMCPサーバーやツールへのリクエストが発生するたびに、「誰が代理ユーザーか」「どのエージェントが行動しているか」「どのリソースにアクセスしているか」「どのようなアクションを試みているか」といったリアルタイムのポリシー評価がトリガーされます 。

具体的な機能：

• 継続的なインライン認可 — ポリシーがリクエストを許可すれば通過し、拒否されればツールやAPIに到達する前にブロックされます。アプリケーションコードを一切変更する必要はありません 。
• きめ細かいスコープ付きツールポリシー — セキュリティチームは、アプリケーションやMCPサーバー自体を変更することなく、「従業員は100ドルの商品を購入できるが、1万ドルの購入を承認できるのはマネージャーのみ」といったコンテキスト対応ルールを強制できます 。
• 一元的なポリシー管理 — 認可ロジックが個々のMCPサーバーやエージェントの実装から外部化されるため、エージェントアーキテクチャの規模が拡大しても、ルールの保守、監査、更新が容易になります 。
• エンドツーエンドの可観測性 — Agent GatewayのログとトレースIDがPingのランタイムアイデンティティモデルと組み合わさり、「どのユーザーが委任したか」「どのエージェントが呼び出したか」「どのツールが実行したか」「どのポリシーが許可またはブロックしたか」という完全なトレーシングを提供します 。

Cloudflare：エッジでのゼロトラスト強制

グローバルに分散したインフラストラクチャ全体にAIエージェントを展開する組織向けに、Ping IdentityとCloudflareの統合は、アイデンティティ強制をエッジにもたらします。Cloudflareのグローバルネットワークは、220以上の都市にまたがり、GPUを搭載した推論ノードを備えており、従来の企業境界の外側で運用されています 。

仕組み：

Cloudflare Workers Model Context Protocol（MCP）サーバーは、OAuthリソースサーバーとして機能します。これは認証をPingのIDプロバイダー（PingOne DaVinci、PingOne Advanced Identity Cloud、PingFederate）に委任し、エージェントが下流のAPIにアクセスする前に検証します 。

具体的な機能：

• エッジでの強力なスコープ付き認証情報 — AIエージェントは、保護されたAPIを呼び出す前に、Cloudflare Workers OAuthプロバイダーを通じて認証し、スコープ付きトークンを取得しなければなりません。未登録または未認証のMCPクライアントは接続をブロックされます 。
• ゼロトラストポリシーの強制 — PingとCloudflareは、エッジ環境には存在しない企業境界に依存するのではなく、グローバルにモデルや企業データにアクセスするすべてのAIエージェントトラフィックにゼロトラストポリシーを適用します 。
• 監査と可視化 — 分散エッジインフラ全体でのエージェント活動がログに記録され、監査可能になります。これにより、セキュリティチームは、どのエージェントがいつ、誰の委任権限で何にアクセスしたかを把握できます 。

なぜ3つのプラットフォームなのか、そしてなぜ今なのか

これら3つの統合は重複しているわけではなく、AWSはクラウドワークロードのID、Google Cloudはインラインのトラフィック制御、Cloudflareはエッジでの強制という、異なるアーキテクチャレイヤーに対応しています。3つすべてが共通の「Identity for AI」基盤の上に構築されているため、組織はエージェントがどこで実行されるかに関わらず、一貫した認可ロジック、トークン交換パターン、ポリシーフレームワークを適用できます 。

このタイミングは、ある市場の現実を反映しています。それは、企業が従来のIDツールをセキュリティチームが適応させるよりも速くAIエージェントを展開しているということです。今回の統合により、企業は断片的な制御を個々のエージェントやAPIに埋め込むのではなく、認可とポリシー強制を一元化できるようになります 。

エージェント型AIの導入に取り組むセキュリティアーキテクトにとって、もはや実務上の問いは「そのエージェントは認証されているか？」ではありません。「この瞬間、このコンテキストで、この特定のアクションは認可されているか？」です。今回の統合は、その問いに、エージェントが実際に存在する主要プラットフォーム上で、リアルタイムかつ大規模に答えられるようにするものです。