Google Agent Identity 認証マネージャーが正式提供開始、エージェント認証情報をアプリケーションコードから独立したコントロールプレーンへ移行

Google Cloud は8月22日、Agent Identity auth manager、`agentidentity.googleapis.com`、および `agentidentitycredentials.googleapis.com` の一般提供開始を発表した。今回の変更は、エージェントシステムが抱える現実的なリスクに対処するものだ。エージェントが GitHub、CRM、社内 API を操作するようになった際、長期有効な token をプロンプト、環境変数、または一般的なアプリケーション設定に記録すると、モデル、ツール実行系、ログの間で認証情報の露出範囲が過度に広がりやすい。

新しいアーキテクチャでは、「エージェントが誰であるか」と「どの外部認証情報を取得できるか」を分離する。デプロイされたエージェントは、まず専用の Agent Identity で認証を受け、その後 auth manager に紐付けられた provider に認証情報を要求する。現在は、静的 API key、ユーザー操作を伴わない two-legged OAuth、個々のユーザーに代わって認可を受ける three-legged OAuth をサポートしている。管理者は `roles/agentidentity.editor` またはカスタムロールを使用して provider を制御できるほか、設定の一時停止、更新、削除、および30日間の論理削除期間内での復元も行える。

エンジニアリングチームにとって、その価値は OAuth コードの記述を減らせることだけではない。エージェントID、ユーザー委任、サードパーティのシークレットを個別に監査できるようになり、Organization Policy と VPC Service Controls を組み合わせて、リソースフィールドやネットワーク境界を制限できる。Google はまた、プレビュー段階の IAM Connectors API を一般提供へ移行しないことを明言している。ユーザーは provider と API 呼び出しを再構築する必要があり、既存のエンドポイントがそのままアップグレードされると想定してはならない。

ただし、認証情報の一元保管によって最小権限が自動的に実現されるわけではない点には注意が必要だ。provider が付与する scopes、エージェントが利用できるツール、認証情報の取得後にそれがツールのログへ記録されるかどうかについては、引き続きデプロイ側が責任を負う。今後注目すべき点は、token に対して1回の呼び出し単位でより細かな制約を設定できるようになるか、サードパーティ SaaS provider の対応範囲がどこまで広がるか、そしてクロスクラウドまたはセルフホスト型のエージェントでも同じID境界を採用できるかどうかだ。