AIに「設定を読むだけ。変更はしないで」と頼む場面が増えました。確認作業を任せるなら、間違って更新しないことも確かめておきたいところです。そのためには、指示文に加えて、AIが使うアカウントの権限と、コマンドを実行する環境を分ける必要があります。
確認作業から更新コマンドが実行された
開発中、構成情報を読むためのツールを設定・確認する作業で、意図していないデプロイ用の更新コマンドが実行されました。依頼したのは読み取りの準備だったのに、変更を伴う操作まで進んでしまったのです。
その後、対象のアクセス制御ルールを読み直し、内容が変わっていないことは確認できました。ただ、エラーが返ったという理由だけで「何も起きていない」とは判断できません。ひとつのコマンドが複数の処理を行う場合、途中まで成功してから止まることもあるためです。何を実行したかと、実行後に何が変わったかを分けて確認する必要がありました。
見直すべきなのは、作業を任せる側の設定も含めた全体です。「変更しない」という依頼と、実際には変更できる実行環境が、食い違っていました。
「読み取り専用」はどこで制限しているのか
たとえば、AIに設定を調べてもらうとします。指示文には「読むだけ」と書き、使えるツールも設定取得の機能だけに絞ります。ここまでなら、画面上は読み取り専用に見えます。
でも、そのツールがOwnerなどの強い権限を持つアカウントで動いていたら、アカウントには変更する力が残っています。AIが別のコマンドを実行できて、同じ認証情報を使える場合も同様です。ツール一覧から更新機能を外すだけでは、その経路はなくなりません。
確認する箇所は三つあります。AIへの指示は「何をしてよいか」。公開するツールは「どの操作を選べるか」。実行環境とIAMの権限設定は「そのアカウントで実際に何ができるか」です。それぞれをそろえる必要があります。
さらに、ツールの名前だけでは分からない処理もあります。調査したFirebase CLI v15.30.2では、MCPというAI向けの接続機能でツール一覧を取得すると、課金状態の確認処理が呼ばれます。その中には、Cloud Billing APIが有効かを調べ、未有効なら有効化を試みる処理がありました。ツール一覧の処理から、課金状態の確認、APIの有効化処理へとたどれます。
これは先ほどの更新コマンドの原因を示す話ではありません。ただ、一覧取得のように見える操作でも、内部で設定変更を試みる場合があると分かりました。APIの有効化と、課金プランの変更も別の操作です。
読むためのアカウントを分ける
最初から独自の管理システムを作る必要はありません。まずは読み取り用のアカウントを分け、調査に必要な対象と権限だけを与えます。Google Cloudも、用途ごとにサービスアカウントを分け、必要な権限だけを付けることを推奨しています。
ここで大事なのは、専用アカウントを作っただけで終わらせないことです。実行環境に管理者の認証情報が残っていれば、そちらを使う可能性があります。コマンドの実行機能も含めて、強い権限へ切り替えられる経路がないかを確認します。
変更が必要になったら、対象と変更内容を人が確認したうえで、変更用の手順へ進めます。読み取りに失敗したときも、その場で管理者権限を足す前に、何の権限が足りないのかを調べます。
接続できたあとに確かめること
読み取り用の接続を用意したら、次の点を確認します。
- 実際に使われているアカウントは、用意した読み取り用のものか
- 必要な設定情報を取得できるか。不要なデータまで読めないか
- ツールの起動や一覧取得に、設定変更の処理が含まれていないか
- 変更の権限がないことを、権限設定や検証用環境で確かめたか
- エラーが出た場合、ログと対象の状態を確認できるか
拒否されるか試すために、本番で更新コマンドを実行するのは避けます。
今回の見直しでは、読み取り用のアカウントを作るところまでは進めました。予定している接続方法で一通り動くかは、まだ確認が済んでいません。「読み取り専用にした」と言う前に、どのアカウントで何ができ、何ができないのかを確かめるところまでが、準備だと考えています。