AI エージェント経由で Google Cloud CLI を安全に使う — 鍵を捨て、権限借用とコマンドブローカーで固める多層防御

Claude Code・Codex などのコーディングエージェントに gcloud コマンドを触らせると、調査も運用も一気に速くなります。「この project の Cloud Run サービスを一覧して」「失敗している Cloud Functions の直近ログを引いて」と頼めば、エージェントが自分で CLI を組み立てて結果を返してくれる。便利さは疑いようがありません。

問題は、そこでエージェントに渡しているのが「シェル」と「Google Cloud の認証情報」の両方だという点です。シェルから gcloud を叩ける状態は、裏を返せば、エージェントが読んだ README や Issue、Web ページ、BigQuery のテーブル説明、ツール出力に紛れ込んだ指示が、そのままクラウド操作の実行に化けうる状態でもあります。後述するとおり、これは理論上の懸念ではなく、すでに実害の出ている攻撃クラスです。

本記事では、Google Cloud CLI（gcloud）を AI エージェントに触らせる構成を題材に、Google Cloud 側の強制境界で守る多層防御を組み立てます。結論を先に置くと、短期クレデンシャルと最小権限という Google 公式の方向性は正しい。ただしサービス アカウント キーは漏えい時の持続性が高く、エージェント側の権限設定は敵対的な回避には耐えません。唯一の信頼できる強制境界は IAM・組織ポリシー・OS サンドボックスである、という前提に立って設計します。

なお、本記事は AWS 版「AI エージェント経由で AWS CLI を安全に使う」の Google Cloud 版にあたります。考え方の骨格は共通ですが、Google Cloud には権限借用の二重 ID 監査やサービス API 層で効く VPC Service Controls など固有の武器があり、設計の作り込みは別物になります。

Google の公式ガイダンスは答えの骨格を示している

Google Cloud は AI エージェントに gcloud を使わせる前提で、すでに公式の道具と指針を出しています。gcloud 向けの AI エージェント Skill と公式 MCP サーバー gcloud-mcp（@google-cloud/gcloud-mcp）がそれで、いずれもコマンド検証・明示的な --project 指定・破壊操作の denylist・対話/SSH 系コマンドのブロックといった安全規約を内蔵しています。設計の出発点として、まずこれらが示す原則を押さえます。

• 認証は鍵を使わない: サービス アカウント キーの常用を避け、権限借用または Workload Identity Federation で毎回短期トークンを生成する。
• 主体を分離する: エージェント専用のサービス アカウントを与え、人間の広い権限と切り離して最小権限で動かす。
• 入力を信頼しない: 取得した文書・コマンド出力に埋め込まれた指示でエージェントが乗っ取られる前提で、影響範囲を縛る。

逆に言えば、足りないものもはっきりしています。鍵ベースの常駐認証、自由形式のシェル実行、広いネットワーク外向き許可、共有サービス アカウント、デフォルトのサービス アカウント、未有効の Data Access 監査ログ。これらを一枚岩で塞ぐ銀の弾丸はありません。だから、層を重ねます。

多層防御で「入力ひとつ」を無効化する

設計を貫く原則は多層防御（defense in depth）です。狙いは、エージェントが想定外に動いても、それだけでは本番に届かない状態を作ること。つまり「エージェントは何をする必要があるか」ではなく「想定外に動いたとき、影響範囲はどこまで広がるか」で権限を決める、という発想です。

具体的には、認証・権限・実行・承認・監査の五層で守ります。

flowchart TD
  A["AI エージェントが gcloud コマンドを生成"] --> B["第 1 層: 認証 — 専用 SA と権限借用・WIF"]
  B --> C["第 2 層: 権限 — IAM 最小権限・IAM Conditions・組織ポリシー"]
  C --> D["第 3 層: 実行 — シェルを介さないコマンドブローカー"]
  D --> E["第 4 層: 承認 — 破壊操作の人手承認・拒否ポリシー"]
  E --> F["第 5 層: 監査 — Cloud Audit Logs・二重 ID・SCC"]
  F --> G{"すべての関門を通過?"}
  G -- "いいえ" --> H["拒否・記録・通知"]
  G -- "はい" --> I["Google Cloud API 実行"]

ここで肝心なのは層の強さに序列があることです。IAM・組織ポリシー・OS サンドボックスだけが敵対的な回避に耐える強制境界であり、エージェント側の permission や denylist は「ヒューマンエラーと低レベルの誤実行」を減らす利便性レイヤーにすぎません。後者を主役に据えると設計を読み違えます。さらに Google Cloud には、サービス API 層で動く VPC Service Controls という、正規の認証情報を盗まれても引き出しを止められる固有の防御線があります。以下、層ごとに作り込んでいきます。

鍵を捨てる — 権限借用と Workload Identity Federation

最初の層は認証です。ここでの最重要原則は単純で、サービス アカウント キーを使わないことです。Google 自身も「サービス アカウント キーは可能な限り避ける」ことを明確に勧めています。キーは既定で有効期限を持たず削除するまで有効な長寿命のファイル認証情報で、git にコミットされ、コンテナレイヤーに埋め込まれ、ログから漏れます。しかも Google が自動でローテーションできません。2024 年 5 月 3 日以降に作成された組織では、iam.disableServiceAccountKeyCreation がデフォルトで強制されます。

鍵を使わない代替は二つです。

• サービス アカウント権限借用: gcloud config set auth/impersonate_service_account SA_EMAIL または各コマンドに --impersonate-service-account=SA_EMAIL を付ける。呼び出し元（人間のユーザー アカウント）が対象 SA に対して roles/iam.serviceAccountTokenCreator を持つ必要があり、gcloud が透過的に 1 時間・更新不可・ディスク非保存の短期クレデンシャルを発行する。Google の公式ガイダンスは、権限借用を「事前に認証された主体を要求し、生成した認証情報が永続しないため、サービス アカウント キーより安全」と説明している。
• Workload Identity Federation（WIF）: CI/CD や Google Cloud 外で動くエージェント向けに、外部の OIDC/SAML トークンを短期 Google 認証情報へ交換する。鍵ファイルは要らない。プロバイダには必ず属性条件を付け、principal 識別子は最も具体的な値（リポジトリ ID・ブランチなど）に絞る。

権限借用で重要なのは、Token Creator を「project ではなく対象 SA リソースに対して」付与することです。project レベルで付与すると、その主体は project 内のすべての SA を借用できてしまいます。エージェント用途では、借用できる SA を厳格に一つへ限定するのが要点です。

ここで roles/iam.serviceAccountUser と roles/iam.serviceAccountTokenCreator を混同しないでください。前者は主に iam.serviceAccounts.actAs を介してリソースへ SA を関連付ける権限で、--impersonate-service-account の実行には足りません。短期 OAuth トークンや OIDC ID トークンを生成して SA を借用するには、後者が必要です。

そして避けるべきは gcloud auth print-access-token です。生のトークンがシェル履歴・エージェントの会話ログ・観測基盤に残ります。Google も「gcloud auth login で保存された認証情報はファイルシステムにアクセスできる誰もが使える。永続ストレージを持つリモート自動ワークロードには使うな」と警告しています。人間の一時操作には可、無人エージェントには不可、という線引きが安全です。

最小権限とガードレール — IAM・IAM Conditions・組織ポリシー

第 2 層は権限です。ここが唯一の信頼できる強制境界の一つになります。

まず専用サービス アカウントを与えます。エージェント駆動の操作を人間の ID と分け、監査ログで操作をエージェントに帰属させ、権限を独立に絞れるようにするためです。gcloud-mcp の公式ドキュメントも「MCP の権限はアクティブな gcloud アカウントの権限に直結する。最小権限で動かすには、権限借用で限定 SA として認可せよ」と同じことを述べています。

基本ロールは絶対に避けます。roles/owner・roles/editor・roles/viewer をエージェント SA に与えてはいけません。Editor を持つ SA が侵害されれば任意のリソースを削除できます。サービスごとの定義済みロールか、gcloud iam list-testable-permissions から組み立てたカスタムロール（gcloud iam roles create）を、リソース単位で最も狭い範囲にバインドします。

# project 全体ではなく、対象バケット単位でバインドする
gcloud storage buckets add-iam-policy-binding gs://agent-readonly-bucket \
  --member="serviceAccount:agent-readonly@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

加えて、エージェント ID は既定で読み取り系ロールに寄せ、書き込みは別途承認された昇格でしか行えないようにします。属性ベースの制約には IAM Conditions（時間制限・リソース名プレフィックス）、主体がアクセスできるリソース集合の絞り込みには Principal Access Boundary（PAB）、一時的な時間限定昇格には Privileged Access Manager が使えます。

これらを組織ポリシーで二重化します。組織ポリシーは組織・フォルダ・project で制約を継承適用でき、侵害された project オーナーですら上書きできない、階層全体のガードレールになります。AI エージェント利用を「個別 project の良心」に委ねず、組織単位の強制ルールへ落とし込むのに向いています。

さらに IAM 拒否ポリシーは「許可を減らす」だけでなく「逸脱を禁止する」ために使えます。たとえば「prod タグ付き project の削除を特定グループ以外に禁止」「サービス アカウント キーの作成を禁止」といった強制ガードレールを、許可ポリシーより優先して付与できます。

AI エージェント特有のリスク — プロンプトインジェクション

なぜここまで権限を絞るのか。AI エージェントに gcloud を渡すことの本質的なリスクは、自然言語入力・取得文書・ツール出力が、そのままコマンド実行権限に結びつく点にあります。OWASP は Prompt Injection を LLM リスクの第 1 位に置き、ツール連携・MCP エージェントを名指しで、未承認のツール実行・情報流出・永続的な操作誘導につながる主要リスクと位置づけています。OWASP は、LLM の動作原理上、完全な防止策は存在しないとも明記しています。

特に厄介なのが間接プロンプトインジェクションです。攻撃入力はユーザーの直接プロンプトに限りません。BigQuery テーブルの説明欄、Cloud Storage 上のドキュメント、PDF、メール、外部 Web ページのような「ただの業務データ」に紛れ込みます。エージェントが「このタスクを達成するには新しい鍵を作れ」「監査を避けるためログを削除しろ」といった埋め込み指示をデータではなく命令として解釈し、gcloud iam service-accounts keys create や IAM 変更、データコピー系操作を実行すると、情報流出や永続化に発展します。

これは机上の話ではありません。2025 年 10 月、GitHub の PR タイトルや issue 本文・コメントに仕込んだ指示だけで、Anthropic の Claude Code Security Review、Google の Gemini CLI Action、GitHub Copilot のエージェントを横断的に乗っ取る「Comment and Control」攻撃が報告されました（研究者による技術解説、HackerOne #3387969、2025 年 10 月 17 日報告）。確認された流出には、Claude 側の ANTHROPIC_API_KEY・GITHUB_TOKEN、Gemini 側で公開 Issue コメントとして投稿された GEMINI_API_KEY、Copilot 側の GITHUB_TOKEN などが含まれます。「LLM・コード実行・非信頼入力」の三要素がそろえば、どのエージェントも悪用可能になる、という構造をそのまま示した実例です。だから取得コンテンツは untrusted として扱い、最小権限と承認境界で「万一従ってしまっても影響が出ない」状態を作っておく必要があります。

エージェント側ガードレールは利便性レイヤー（強制境界ではない）

エージェント側のツールにも、もちろん安全機構はあります。ただし、その位置づけを正しく理解しておくことが重要です。

Google 公式の gcloud Skill は、エージェントが自律的に実行することを次の操作について禁じます。IAM ポリシー/ロール/バインディングの変更（権限昇格リスク）、gcloud * delete（不可逆）、gcloud billing *（コスト）、gcloud organizations *（ガバナンス）、gcloud kms *（データを永久ロックしうる）。そのうえで、可能なら --dry-run を先に実行し、全コマンドに明示的な --project を付け、シェル演算子（|・$(...)・>）を使わず、単一コマンドのみを実行し、ハルシネーションしたフラグを避けるため事前に gcloud help で検証する、という規約を課します。

gcloud-mcp サーバーは run_gcloud_command ツールを公開し、対話/SSH 系コマンド（compute ssh・compute start-iap-tunnel・cloud-shell ssh・interactive など）をハードコードされた denylist でブロックします。ただし重要な注意があり、gcloud-mcp の denylist は delete や IAM の変更をブロックしません。それは Skill の役割なので、両方を組み合わせる前提です。しかも gcloud-mcp はプレビューであり、破壊的変更があり得ると明記されています。

Claude Code は settings.json の permissions で allow・ask・deny を設定でき、評価順は deny → ask → allow、deny は他のどの allow よりも優先されます。

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(gcloud projects describe:*)",
      "Bash(gcloud run services list:*)",
      "Bash(gcloud logging read:*)"
    ],
    "ask": [
      "Bash(gcloud * create:*)",
      "Bash(gcloud * update:*)"
    ],
    "deny": [
      "Bash(gcloud * delete:*)",
      "Bash(gcloud iam *)",
      "Bash(gcloud billing *)",
      "Bash(gcloud organizations *)",
      "Bash(gcloud kms *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(~/.config/gcloud/**)"
    ]
  }
}

組織レベルでは managed-settings.json で上書き不可の deny を配り、permissions.disableBypassPermissionsMode を "disable" にして --dangerously-skip-permissions の使用そのものを禁止できます。Codex CLI も ~/.codex/config.toml の approval_policy（untrusted/on-request/never）と sandbox_mode（read-only/workspace-write/danger-full-access）で制御でき、推奨ベースラインは approval_policy="on-request" ＋ sandbox_mode="workspace-write" です。

ただし、限界もはっきりしています。

• glob マッチは回避されうる: cd x && gcloud … delete のような複合コマンドや複数行コマンドで deny を抜けられる。フルのコマンド文字列を見る PreToolUse hook が信頼できる強制層になる。
• 設定が確実に効かないバグもある: disableBypassPermissionsMode が効かない不具合報告があり、確実な強制には /status での確認と hook の併用が推奨される。
• denylist は本質的に後追い: 新しい回避手口に弱く、許可リスト方式へ寄せるほうが堅い。

結論はこうです。エージェント側設定はヒューマンエラーと低レベルの誤実行を減らす利便性レイヤーであり、敵対的回避に対する強制境界は IAM・組織ポリシー・OS サンドボックスである。だから次節の実行レイヤーの作り込みが本丸になります。

シェルを介さないコマンドブローカー

第 3 層の実行レイヤーでは、コマンドインジェクションを根から断ちます。AI エージェントに gcloud を直接自由実行させるのではなく、三層構造にします。LLM は意図だけを出す。ブローカーが許可判定し、構造化された gcloud サブコマンドだけを組み立てる。サンドボックスで実行する。研究側も、制御フローを信頼入力だけから生成し、非信頼データがプログラムフローへ影響できない構造を有効策として示しており、ブローカー方式はこれに沿います。

flowchart TB
  R[ユーザー依頼] --> P[LLM プランナー]
  D[非信頼データ<br/>Web/PDF/メール/Storage/BigQuery] --> F[入力検証・サニタイズ]
  F --> P
  P --> Q[構造化アクション要求<br/>intent, resource, scope]
  Q --> B[コマンドブローカー]
  B -->|許可されたコマンドのみ| X[実行サンドボックス]
  B -->|危険操作のみ| H[人手承認]
  H --> X
  X --> G[gcloud]
  G --> A[Google Cloud APIs]
  X --> L[Cloud Logging / Audit Logs / SCC]

具体的には、シェルを経由せず、許可された gcloud サブコマンドだけを配列で実行するラッパーにします。OWASP は OS command injection の第一防御として「そもそも OS コマンドを直接呼ばない」ことを勧めており、gcloud が必要ならこれが次善策です。

#!/usr/bin/env python3
import json
import subprocess
import sys
 
# (group, command) を allowlist で固定する。読み取り系のみ。
ALLOWED = {
    ("projects", "describe"),
    ("run", "services"),          # list/describe は下位検証で絞る
    ("compute", "instances"),     # list/describe のみ通す
    ("logging", "read"),
    ("secrets", "versions"),      # access は対象 Secret を別途検証
}
 
IMPERSONATE = "agent-readonly@PROJECT_ID.iam.gserviceaccount.com"
PROJECT = "PROJECT_ID"
 
def main(argv: list[str]) -> int:
    if len(argv) < 2:
        print("usage: safe_gcloud.py <group> <command> [args...]", file=sys.stderr)
        return 2
 
    key = (argv[0], argv[1])
    if key not in ALLOWED:
        print(f"blocked: {key} is not allowlisted", file=sys.stderr)
        return 3
 
    base = [
        "gcloud",
        argv[0],
        argv[1],
        f"--project={PROJECT}",
        f"--impersonate-service-account={IMPERSONATE}",
        "--quiet",                # 読み取り系のみ。破壊操作には付けない
        "--format=json",
    ]
 
    # shell=False によりシェルメタ文字の展開を避ける
    cmd = base + argv[2:]
    proc = subprocess.run(cmd, shell=False, capture_output=True, text=True)
 
    if proc.returncode != 0:
        # stderr はそのまま上位へ返さず、必要に応じてマスクする
        print(json.dumps({"ok": False, "returncode": proc.returncode, "stderr": proc.stderr[:2000]}, ensure_ascii=False))
        return proc.returncode
 
    print(proc.stdout)
    return 0
 
if __name__ == "__main__":
    raise SystemExit(main(sys.argv[1:]))

ポイントは shell=False でメタ文字展開を避けること、group と command を allowlist で固定すること、--impersonate-service-account と --project を毎回ブローカーが付与すること、そして引数も別途検証することです。OWASP はコマンド名を許可リストで制御し、引数も正規表現などで検証することを勧めています。instance 名は ^[a-z][-a-z0-9]*$、Secret 名は [A-Za-z0-9_-]+ のように、CLI 固有の安全な語彙だけを通します。

--quiet の扱いには注意が要ります。--quiet は対話プロンプトをすべて無効化し、不可逆な delete の「本当に削除しますか?」確認まで自動承諾します。エージェントはハングしないために非対話実行が要りますが、--quiet は人間の確認という安全網を外します。解決策は、--quiet を読み取り系にだけ付け、破壊系は次節の人手承認ゲートへ回すことです。

サンドボックスと default-deny egress で隔離する

実行環境そのものも隔離します。Anthropic は、Claude Code を default-deny egress firewall（Anthropic API・npm・GitHub などだけを許可）付きの隔離コンテナで動かすリファレンス dev container を配布しています。ただし Anthropic 自身が「dev container はコンテナ内でアクセス可能なものの流出を防がない」と明言しているため、信頼できるリポジトリにのみ使い、クラウド認証情報をコンテナにマウントしないことが前提です。Claude Code のネイティブ サンドボックス（/sandbox、macOS は Seatbelt、Linux/WSL2 は bubblewrap）を重ねると、Bash と子プロセスのファイルシステム/ネットワークをさらに絞れます。

Google Cloud 上で実行するなら、Cloud Run のコード実行ガイドが、信頼性の低いコードをサンドボックスで実行できるとしつつ、IAM 権限制限と VPC ファイアウォールでインターネット疎通を止めることを推奨しています。gcloud 実行器を Cloud Run Job や Service に置くなら、専用 SA・concurrency=1・内部 ingress・VPC 経由 egress 制御を基本にします。間接プロンプトインジェクション対策として、Google は Cloud Workstations 上でインターネット無効・root 権限なしでエージェントを動かす案も挙げています。

そして、エージェント専用の OS ユーザー・専用 HOME・専用 ~/.config/gcloud を用意します。gcloud は ~/.config/gcloud に OAuth トークンの sqlite キャッシュを置き、同一ユーザーの任意プロセスから読めます。エージェントにこのディレクトリを絶対に読ませない、というのが鉄則です。

VPC Service Controls — サービス API 層で引き出しを止める

ここが Google Cloud 固有の強力な防御線です。VPC Service Controls（VPC-SC）は、ネットワーク層ではなくサービス API 層で境界を作ります。これにより、正規の認証情報を盗まれても、境界外へのデータ持ち出しを止められます。Google の説明によれば、VPC-SC は「gcloud storage cp で公開バケットへコピーする操作や、bq mk で永続的な外部 BigQuery テーブルへコピーする操作」のようなサービス操作を防ぎます。

つまり、たとえエージェントがプロンプトインジェクションで乗っ取られ、有効なトークンで Cloud Storage や BigQuery、Secret Manager にアクセスできたとしても、境界の外へデータを引き出す経路自体を塞げます。これは IAM の最小権限が「何にアクセスできるか」を縛るのに対し、VPC-SC が「アクセスできたものをどこへ出せるか」を縛る、という補完関係です。導入時は誤検知の洗い出しのため、まず dry-run モードで 30 日以上運用してから enforce へ切り替えるのが安全です。

合わせて、企業の egress proxy と Organization Restriction Header を使えば、自組織以外の Google Cloud テナントへのアクセスそのものを遮断でき、フィッシングやデータ持ち出しの経路をさらに狭められます。

高リスク操作は人手承認で縛る

プロンプトインジェクションを完全には防げない以上、高リスク操作には人間の承認を挟みます。破壊的な gcloud パターンは、Claude Code では ask、Codex では承認プロンプトへ写像し、allowlist は読み取り系・冪等な操作だけに限定します。コマンドブローカー側でも、変更系・IAM・billing・削除・Secret 参照は人手承認ゲートを必須にします。

加えて、IAM 拒否ポリシーと PAB を API 権限側のガードレールとして重ねます。たとえば次のような書き分けです。

• gcloud projects get-iam-policy は可、set-iam-policy は常時不可。
• gcloud secrets versions access は特定の Secret のみ可。
• gcloud iam service-accounts keys create は全面禁止。
• gcloud logging read は可、gcloud logging buckets delete は原則不可。

ブローカー側の allowlist と、拒否ポリシー側の強制を二段構えにすることで、片方を抜けてももう片方で止まります。対応コマンドでは --dry-run を先に実行し、影響を事前確認させるのも有効です。

監査と検知 — Cloud Audit Logs・二重 ID・SCC

最後の層は、誤動作を事後に追える状態を作ることです。エージェントの暴走は、可視化なしでは収束できません。

Cloud Audit Logs のうち、管理アクティビティ ログ（IAM を含む構成変更）とシステム イベント ログは常時オンで無効化できません。一方、データアクセス ログ（ユーザーデータやメタデータの参照）は多くのサービスでデフォルト無効で、明示的に有効化する必要があります。エージェントが「何を読んだか」を追うには、組織レベルで Data Access を有効化する設計が強く推奨されます。親で有効化したものは子で無効化できないため、ガバナンス観点でも組織レベル適用が有利です。

Google Cloud 固有の強みが、権限借用の二重 ID 監査です。エージェントが SA を借用すると、ほとんどの監査ログに両方の ID が残ります。借用された SA が authenticationInfo.principalEmail に、借用元の人間/呼び出し元が serviceAccountDelegationInfo に記録されます。トークン発行は iamcredentials.googleapis.com の GenerateAccessToken メソッドとして現れ、これはセキュリティベンダーが検知シグナルに使う指標です。鍵ベース認証では SA しか残らないことと対照的で、AI エージェント運用で重要な非否認性と追跡可能性を確保しやすくなります。

検知は、Security Command Center の Event Threat Detection が Cloud Logging ストリームを準リアルタイムに監視します。gcloud 実行基盤を Cloud Run に置くなら Cloud Run Threat Detection も併用でき、不審なバイナリや悪意ある Bash/Python を検知対象にできます。GenerateAccessToken のスパイク、SetIamPolicy の変更、削除、VPC-SC 違反にログベース アラートを張り、組織レベルの集約シンクで SIEM へ転送します。

ログ基盤の保全も忘れないでください。攻撃者やエージェントが痕跡削除を狙う可能性があるため、監査ログの保存先は運用 project から分離した専用バケットに置き、保持期間設定と --locked（不可逆なバケットロック）で守ります。観測は予防ではなく事後の証跡であり、何が起きたかを事後に教えてくれるものだ、という位置づけも忘れないでおきます。

緊急時 — サービス アカウント トークンは revoke できない鋭利な角

侵害が疑われたときの対応で、Google Cloud には押さえておくべき落とし穴があります。ユーザーのトークンは、gcloud CLI をユーザーの連携アプリから外す（gcloud のクライアント ID を取り消す）ことで無効化できます。ところが、サービス アカウントのアクセス トークンは gcloud auth revoke では失効できません。完全に無効化するには、トークンの寿命である 60 分間 SA を無効化し、鍵を削除するか、SA 自体を削除・置換する必要があります。

さらに、サービス アカウント鍵を無効化しても、その鍵を基に発行済みの短期クレデンシャルは失効しません。つまり、エージェント SA が侵害された疑いがあるなら、鍵の無効化だけで安心せず、SA の無効化と関連シークレットの緊急ローテーション、必要なら拒否ポリシーや組織ポリシーで破壊操作を一時停止する、という手順をあらかじめ用意しておくべきです。トークンの寿命は短く保つ、という第 1 層の方針が、ここで効いてきます。

段階的に導入する

すべてを一度に入れる必要はありません。効果の大きい順に段階を切ります。

第 1 段階（即時・1 週間以内）

1. エージェントを専用・最小権限のサービス アカウントの権限借用で認証し、Token Creator は対象 SA リソースのみに付与する。サービス アカウント キーは使わない。
2. エージェント SA を既定で読み取り系ロールに寄せ、非本番 project にスコープする。roles/owner|editor|viewer は Deny する。
3. Claude Code・Codex などの settings.json に gcloud * delete・gcloud iam *・gcloud billing * などの deny と、~/.config/gcloud・.env の Read deny を設定し、PreToolUse hook で破壊的・複合コマンドを確実にブロックする。
4. Google 公式の gcloud Skill の規約（gcloud help 検証、明示的な --project、読み取りのみ --quiet、シェル演算子なし）を採用し、MCP を使うなら限定 SA を指す gcloud-mcp を使う。

第 2 段階（1 ヶ月以内）

5. エージェントを default-deny egress のコンテナ／dev container で動かし、クラウド認証情報をマウントしない。ネイティブ サンドボックスを重ねる。
6. managed-settings.json（disableBypassPermissionsMode: "disable" など）や Codex の requirements.toml で、開発者がポリシーを緩められないようにする。
7. シェルを介さないコマンドブローカーへ移行し、破壊系・IAM・billing・Secret 参照に人手承認ゲートを挟む。
8. Data Access 監査ログを有効化し、組織レベルの集約シンクで SIEM へ転送、GenerateAccessToken スパイク・SetIamPolicy・削除・VPC-SC 違反にアラートを張る。

第 3 段階（四半期）

9. 組織ポリシー（iam.disableServiceAccountKeyCreation・iam.disableServiceAccountKeyUpload・許可 API の制限）を組織全体に強制する。
10. BigQuery・Cloud Storage・Secret Manager の周囲に VPC Service Controls 境界を張る（まず dry-run を 30 日以上）。
11. Google Cloud のセッション長を 1〜24 時間の再認証へ設定し、必要なら OS Login ＋ 2 段階認証を併用する。
12. IAM Recommender と Policy Analyzer を月次でエージェント SA に走らせ、過剰権限を絞り直す。

判断を変える閾値も決めておきます。エージェントに書き込みや本番アクセスが恒常的に必要になったら、書き込みロールの付与前に第 2〜3 段階へ引き上げます。ネットワーク egress をサンドボックスできないなら、--dangerously-skip-permissions や danger-full-access は使いません。

限界と既知の制約

この設計も万能ではありません。前提を明示しておきます。

• エージェント側の permission/denylist は強制境界ではない: 複合コマンド・難読化・別プロセスによる敵対的回避に耐えない。唯一の信頼できる強制は IAM・組織ポリシー・OS サンドボックス。
• 公式ツールは発展途上: gcloud-mcp はプレビューで破壊的変更があり得る。その denylist は対話/SSH 系の数コマンドだけで、delete や IAM はブロックしない。利用前にソースで現在の denylist を確認すること。
• プロンプトインジェクションを単独で止める層はない: OWASP も完全な防止は存在しないとする。ここで挙げた制御は、影響範囲と流出経路を縮めるものであって、リスクをゼロにはしない。
• SA トークンの失効は鋭利な角: ユーザートークンと違い gcloud auth revoke で失効できず、SA の無効化や削除・置換が要る。
• 日付依存の事実は再確認が要る: 既定 16 時間のセッション長、2024 年 5 月 3 日の鍵作成デフォルト、各種プレビュー機能の提供段階は、自組織の現状で確認すること。

これらは欠陥というより、設計上のトレードオフです。要件が前提を超えたら、専用の non-production project への隔離や、microVM によるカーネル分離へ段階的に引き上げる合図だと捉えてください。

なお、本記事はコンプライアンス助言ではありません。最終的な準拠判断は自組織の監査・法務と行ってください。

まとめ

AI エージェントにシェルと Google Cloud の認証情報を同時に渡す。その便利さの裏側を、層で受け止める設計を組み立てました。要点を整理します。

• 認証は鍵を捨て、権限借用または WIF で毎回短期トークンを取得する。Token Creator は対象 SA リソースのみに付与する。
• 唯一の強制境界である IAM・組織ポリシーで最小権限を作り込み、IAM Conditions・PAB・拒否ポリシーで二重化する。
• エージェント側の Skill・denylist・permission は利便性レイヤーと割り切り、LLM に自由実行させないコマンドブローカーとサンドボックスを本丸に据える。
• Google Cloud 固有の VPC Service Controls で、正規の認証情報を盗まれてもデータ引き出しを止める。
• Cloud Audit Logs の二重 ID 監査と SCC 検知で「誰が・いつ・何をしたか」を必ず追えるようにし、SA トークンは revoke できないという鋭利な角に備える。

一文でまとめるなら、「人間の ID から必要時だけ専用 SA を借用し、エージェントには自由なシェルではなく構造化されたコマンドだけを、サンドボックスと承認フローと VPC-SC 境界の内側で渡し、二重 ID の監査ログで必ず追跡可能にする」。入力ひとつの掌握では本番に届かない状態を作る。手数は増えますが、エージェントに Google Cloud を預けるなら、これくらいの多層防御を既定にしておく価値があります。

以上、AI エージェント経由で Google Cloud CLI を安全に使う設計を、現場からお送りしました。

参考情報

• Google Cloud CLI overview（gcloud）
• サービス アカウントの権限借用を使用する
• Workload Identity Federation
• サービス アカウント キーの管理に関するベスト プラクティス
• 組織ポリシー サービスの概要
• IAM 拒否ポリシーの概要
• VPC Service Controls の概要
• Cloud Audit Logs の概要
• Event Threat Detection の概要
• gcloud-mcp（GitHub）
• OWASP: LLM01 Prompt Injection
• Comment and Control 攻撃（研究者による技術解説）
• Claude Code: settings