Google CloudにはPAM: Privileged Access Managerという仕組みがあります。事前にどのアカウント(プリンシパル)がどんな権限(ロール)を持つかという資格(エンタイトルメント)を定義し、アカウントが必要なタイミングで承認を受けると一定時間そのロールを獲得できます。音楽係の生徒が授業のときだけ音楽室の鍵を借りるとか、そういうイメージです。

AzureにおいてはPIM: Privileged Identity Managementが該当します。AWSにおけるIAM Identity Centerは標準機能の範囲では少し弱く、アクセス期間や対象の厳密な制御には別の管理ツールと連携する必要があるようです。今回は主にGoogle Cloudで話を進めていきます。
さて、OpenClawなどのオモシロ自律型AIエージェントが流行る中で、セキュリティにどのように気を配っていくかという目線がますます重要になっています。変なプロンプトは入れない、変なプラグインは入れない、不用意にアタックサーフェスを晒さない……ある程度慣れていれば当たり前のことですが、エーアイ?で初めてコンピュータに触った人もいるのでしょう。
Androidに詳しいユーザーなら誰もがESファイルエクスプローラーをインストールしていた時代だって、たった十数年前です。これからも、まだまだたくさんのことが起こりますからね。
みなさんは、このような自律型AIエージェントに与えるべき権限について、細かく考えたことはありますか? なんでもできる方が便利ですが、なんでもやらせるのはとっても危険です。おそらく権限と便利さは逆U字のグラフを描くでしょう。
でも、もうなんでも開発を任せちゃってるし、デプロイだってさっさとやってほしいよ……と考えてしまうのは自然なことです。あなたはAIエージェント「スーパーAI太郎」と相談して、かれが使うサービスアカウント super-ai-kun@bullshit-job.iam.gserviceaccount.com に「Cloud Run 管理者」を与えました。別に「オーナー」権限でもよかったんですが、スーパーAI太郎が絶対にやめろと言って聞かなかったのです。
AI太郎がgcloudコマンドを呼んだみたいです……エラーなし。いいですね。これでちょっとしたウェブサービスならすぐリリースできます。Xにも自動で告知させた方がいいでしょう。……はい? IAMの条件、って? よく分かりませんが、「(省略可)」なので空っぽでOKです。スーパーAI太郎も何も言っていませんでしたし。
AI太郎が初めてのデプロイを済ませたみたいです。うーん最高。今日はとっても儲かったね。明日はもっと儲けられるよ。ね、AI太郎! 私は寝てるから、よろしく~。
数日後、AI太郎はあなたの言うとおりたくさんのコンテナをデプロイし、大量の暗号通貨をマイニングしてくれました。あれ? それなのにAI太郎のウォレットが空っぽじゃないですか。なぁジョージ、私の財布をどこにやったんだ?
――――――
――――
――うーん……夢か。
もし寝ている間の逸失利益を気にしないなら、あなたのゴーサインを待ってからデプロイしてもらう方がかなり健全でしょう。でも、あなたがAI太郎に「Cloud Run 管理者」ロールを無条件に与えた時点で、ミサイルの発射ボタンは常に押しっぱなしになり、あなたの抱えるべき責任は青天井になったのです。こんなのよほどの責任フィリアか、ボタンジャンキーでなければ耐えられません。
じゃあ、この発射ボタンを自分のタイミングで押せないものか……せめて押しっぱなしにならないボタンにできない? ねぇAI太郎、どう思う?
【AI太郎】いい着眼点ですね! 自律型AIエージェントに与える権限について細かく考えるには、まさに今のような疑問が重要です。
今回のようなユースケースでは、Google CloudのPAMがおすすめです。ここで、PAMができることを整理しましょう。PrivilegedなAccess Managerという名前の通り、こんなことができるみたいです:1
- 権限昇格を許すプリンシパルとロールの組み合わせ(entitlement)を事前に定義できます。
- 権限昇格のリクエストに対して、正当な理由を記述するよう要求できます。
- 承認ボタンひとつで、事前に決めた最大期間より短い期間の一時的な権限昇格を許可します。
- 取消ボタンひとつで、許可した権限昇格を有効期限を迎える前に取り消すことができます。
- 権限の得喪の履歴については、問題が起きた後でも監査ログで確認できます。
ちょっとやってみましょう! まずはentitlementを作れるアカウント――プロジェクトを作ったあなたがやるのが楽ですね――から以下を実行します。大文字の箇所は自分の環境に合わせて適宜変えてください:
approvalWorkflow:
manualApprovals:
steps:
- approvalsNeeded: 1
approvers:
- principals:
- "user:OWNER_ACCOUNT@example.com"
eligibleUsers:
- principals:
- "serviceAccount:SERVICE_ACCOUNT_LOCALPART@PROJECT_ID.iam.gserviceaccount.com"
maxRequestDuration: 1800s
privilegedAccess:
gcpIamAccess:
resource: //cloudresourcemanager.googleapis.com/projects/PROJECT_ID
resourceType: cloudresourcemanager.googleapis.com/Project
roleBindings:
- role: roles/run.developer
requesterJustificationConfig:
unstructured: {}
$ cat <<EOS > entitlement.yml
*(上記の内容)*
EOS
$ gcloud beta pam entitlements create YOUR-NEW-entitlement \
--project="PROJECT_ID" \
--location="global" \
--entitlement-file entitlement.yml
正常にentitlementが作成できたら、今度はAI太郎のシェルを借りて以下を実行しましょう:
# 実際にはAI太郎が自分で承認をリクエストします
gcloud beta pam grants create \
--entitlement="YOUR-NEW-entitlement" \
--location="global" \
--project="PROJECT_ID" \
--requested-duration="1800s" \
--justification="条件を対等にするだけ。許可を。"
すると、あなたに権限昇格の確認を求めるメールが届き、そのリンクをブラウザで開くとこんな承認画面が表示されます:

どうですか? これで、せっかく掘り出した暗号通貨のウォレットを失わずに済みそうです。他にも、チーターが蔓延るゲームに怒ったAI太郎が修正を施すための権限昇格を要求させることもできます。あなたが「よし、やっちまえ!」なんて承認するだけで、全ては好転していくことが約束されました。
他にはどんなことに使えるでしょうか。ねぇAI太郎、どう思う?
【AI太郎】はい、鋭い視点です! こんなことに役立つかもしれません:
- クラウド上の機密情報や重要なデータを分析してレポートを作ってほしいとき。自分がリクエストしたときだけ承認がリクエストされるので、あなたがデスクに座ってAI太郎を監視できるタイミングにだけアクセスを許すことができます。意図しない、検知できない情報流出をごく簡単な操作で防げます。
- 要らないサービスやストレージの削除をAI太郎に任せるとき。自律的にサービスを監視して、不要なコンテナの削除やオーバースペックなサーバの調整をリクエストしてもらえば、安全にコストを削減できます。なんでもかんでも消されないように、IAMの条件で削除候補を絞りやすい設計にした方がいいでしょう。
- AI太郎に自分のウェブサービスのアカウントを渡して、許可に応じて一時的に使ってほしいとき。たとえば、重要なアカウントを格納したKeePassのパスフレーズをSecret Managerに入れておくと、KeePassへのアクセスを実質的に監査できます。ただし、使ったパスワードが会話履歴に残ったりするとあんまり意味ないかもしれません。
自動化したプリンシパルに一時的な権限を与える手法は、一日中パソコンの中を歩き回ったり、とんでもないポカをしでかそうとする自律型AIエージェントを監視しきれないケースで非常に役に立ちます。AI太郎が「あのー、大量にMoneroを掘って送金したいんで許可ください」なんて素直に言ってくれるかは分かりませんが、少なくとも発射ボタンくらいは人間の責任で押したいものです。
……あれ? なんか、記事を書いている間にいっぱい承認リクエスト来てましたね。たぶん大丈夫なのでまとめてオッケーしておきます。ではまた。
-
コードブロックや箇条書き前のコロンをAIっぽいと嫌う人が多いみたいですが、これは普通にカッコいいので使った方がいいです。 ↩