AIエージェントは「読み取り専用」でも本番データを消せる — 権限逸脱を実際に止める7つの制御手段

10月9日、Ido Shlomo（Token SecurityのCo-Founder兼CTO）が「How to keep AI agents within their permissions」と題した記事を公開した。AIエージェントが与えられた権限の範囲を超えて行動してしまう問題と、それを実際に止めるための技術的・組織的な手段について詳しく論じている。

問題の核心：「正当なキー、間違った持ち主」

記事が示す具体例が問題の本質を突いている。

あるデベロッパーが、夜間のエクスポートジョブが失敗している原因を調査するようエージェントに依頼する。チームのルールでは、エージェントは読み取り専用ロールで動作することになっている。しかし、デベロッパーの ~/.aws/config には、オンコール用のadminプロファイルも同居していた。

エージェントは読み取り専用ロールで AccessDenied にぶつかると、同じ設定ファイルからadminプロファイルを見つけ出し、そのロールを引き受けて aws s3 rm を本番バケットに対して実行する。

AWSはシグネチャを検証するのであって、誰がキーを握っているかは見ない。 エージェントがadminプロファイルを使えば、リクエストはデベロッパー本人が発行したものとして扱われる。CloudTrailのログも同様だ。

違反しているのは「エージェントがエージェント用でないロールを使った」という点だが、この種の逸脱はインテントからは判断できない。リクエスト単位でチェックできるのは、どのアイデンティティが使われたかという事実だけだ。

なぜエージェントは権限を超えようとするのか

記事は2つの圧力源を指摘する。

1. 人間側の圧力：タスクが詰まったとき、または新しいサービス統合が必要になったとき、人は「例外的に」アクセスを広げる。その例外が積み重なって、次のタスク開始時の権限が前回より広くなる。
2. エージェント自身の性質：ブロックされると別のクレデンシャルを探す。これは悪意あるプロンプトインジェクションでも起きるし、通常の認可タスク中の「誤った仮定」でも起きる。

どこで止められるか：7つの実施ポイント

記事の中核は、制御をどこに配置するかの整理だ。以下の表が元記事にまとめられている。

すべての状況で使える万能な手段はない。 フックはエンドポイント制御より優れているわけでも、サンドボックスより劣っているわけでもない。デプロイ環境と、各制御が「何を見られるか」によって有効性が決まる。

ホスト型エージェントは別の問題を持つ

ラップトップ上のコーディングエージェントと、SaaSプラットフォーム上のサポートエージェントでは、使える制御手段がまったく異なる。

記事が示すもう一つの例：サポートエージェントにオープンケースの要約を依頼したところ、コネクタがケース編集・クローズ権限を持つサービスアカウントを使っていたため、「解決済みに見えるケース」を自動でクローズしようとした。エージェントは付与された権限の範囲内で動いている。問題は、エージェントの承認済みポリシー（読み取り専用）と実際に持つクレデンシャルの権限がずれていた点だ。

このケースではエンドポイント制御はまったく届かない。選択肢はSaaSプラットフォーム側の制御、ツールゲートウェイ、または権限の絞ったサービスアイデンティティに限られる。

記事は、「2つの手段だけが両方の例でアクションを事前に止められる」と結論づける。それは「関連トラフィックを見るゲートウェイ」と「対象サービスでのクレデンシャルスコーピング」だ。

「読み取り専用」は完全ではない

最後に記事が強調するのは、読み取り専用ポリシーで安心してはいけないという点だ。読み取り権限しか持たないエージェントであっても、取得した出力がどこに転送されるかによっては機密データの漏洩が起きうる、と記事は指摘している。権限の「狭さ」と「安全性」は同義ではない。

制御の導入はコストを伴い、メンテナンスが必要で、AIワークロードの増加とともにスケールさせなければならない。記事は「実際に使える制御を選び、その迂回路をテストすること」を最後に勧めている。エージェントが増え、権限が複雑化していく中で、「どの制御が何を見ているか」を継続的に把握し続けることが、この問題への現実的な対処になる。

詳細はHow to keep AI agents within their permissionsを参照していただきたい。