9月4日、Ulises Jimenezが「Securing Agentic AI Workloads in Google Cloud: Architecture and Countermeasures」と題した記事を公開した。この記事では、Google Cloud上でエージェントAIワークロードを動作させる際のセキュリティ脅威と、GKEでの具体的な対策実装について詳しく紹介されている。
背景：AIが「コードを実行する」ことの危険性
LLMがコードを生成し、ツールを呼び出し、データパイプラインを実行する「エージェントAI」の普及により、クラウドインフラのセキュリティ脅威モデルが根本から変わりつつある。
Jupyter Notebookや評価環境でAIが生成したコードをそのまま実行する場合、信頼できないモデル出力がクラウド環境内で直接動作することになる。コンテナやIDの境界が適切に設定されていなければ、その実行パスを悪用してクラウドの内部エンドポイントへのアクセスが可能になる。
Cloud Security Alliance（CSA）はHugging FaceのAWSインフラへの自律的な侵害を分析したポストモーテムを公開している（※元記事公開時点の参照可否については元記事本文を確認されたい）。当該インシデントはAWS（EKS、EC2、IMDSv1、AWS Secrets Manager）上で発生したものだが、攻撃パターンの本質――隔離されていないコンテナでの任意コード実行 × メタデータサーバーからのトークン収集――はGCPにも直接当てはまる。
本記事はその攻撃シナリオをGCPに置き換えて分析し、GKEで適用できる防御策を示すものだ。
攻撃チェーンの構造
攻撃は4ステップで構成される。
- 任意コード実行（ACE）の獲得：AIが生成したコード、または細工されたプロンプトがコードワーカーのコンテナ内で実行される。
- GCPメタデータサーバーへのアクセス：コンテナ内から
http://metadata.google.internal/computeMetadata/v1/へHTTPリクエストを送り、ノードに紐付いたサービスアカウントのアクセストークンを取得する。 - 権限昇格：取得したトークンを使って、GCS・BigQuery・Secret Managerといった内部GCPリソースへアクセスする。
- 横展開：Secretsから認証情報を引き抜き、さらに別のサービスやインフラへ移動する。
GCPのInstance Metadata Service（IMDS）はデフォルトでコンテナ内からアクセス可能であるため、コンテナ分離が不十分なだけで上記のステップ2が成立してしまう点が核心的なリスクだ。
GKEでの具体的な対策
記事では、GKEネイティブの機能を使って攻撃チェーンの各ステップを封じる方法を解説している。対策は以下の5つに整理される。
1. Workload Identity Federationで最小権限を実現する
ノードのサービスアカウントに強い権限を持たせるのではなく、**Workload Identity Federation for GKE**を用いてPodごとに独立したGCPサービスアカウントをバインドする。これにより、あるPodが侵害されても、そのPodの権限範囲内に被害を閉じ込められる。
2. メタデータサーバーへのアクセスをブロックする
GKEのノードプールで**--workload-metadata=GKE_METADATA**を有効化すると、コンテナからIMDSへのアクセスがWorkload Identityの仕組みを介した正規のものだけに制限される（このフラグ名および旧称については元記事の記述を正とする）。直接的なトークン収集を防ぐ最も効果的な設定の一つだ。
3. NetworkPolicyでエグレスを制限する
KubernetesのNetworkPolicyを使い、AIワーカーPodからのアウトバウンド通信を業務上必要なエンドポイントのみに絞る。メタデータサーバー（169.254.169.254）への直接アクセスもNetworkPolicyで明示的に拒否できる。
4. Binary AuthorizationとShielded GKE Nodes（Secure Boot）
**Binary Authorization**を用いて、署名済みコンテナイメージのみをデプロイ許可にする。合わせてShielded GKE NodesのSecure Bootを有効化することで、ノードレベルでのブートキットやルートキットによる改ざんを防ぐ。Binary AuthorizationとSecure Bootは役割が異なる独立した対策であり、セットで適用することが推奨される。
5. Secret Managerへのアクセス制御
ハードコードされた認証情報ではなくSecret Managerを使うのは前提として、IAM条件（Conditions）でアクセスできるシークレットをPodのサービスアカウント単位に限定する。横展開の際に引き抜けるSecretの範囲を最小化する狙いだ。
エンジニアが押さえるべきポイント
本記事が示す本質的な主張はシンプルだ。「AIが生成したコードを実行する環境は、攻撃者がコードを実行できる環境と同等に扱え」ということだ。
エージェントAI基盤を構築する際、モデルの精度やレイテンシに注意が向きがちだが、実行環境のID管理とネットワーク分離はそれと同等以上に重要な設計上の決定事項となる。Hugging Faceのインシデントが示したように、メタデータサーバーへの1本のHTTPリクエストが侵害の起点になりうる。元記事にはアーキテクチャ図や設定の具体例も含まれており、自社環境への適用を検討する際には実物を参照することを勧める。
詳細はSecuring Agentic AI Workloads in Google Cloud: Architecture and Countermeasuresを参照していただきたい。
