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つの圧力源を指摘する。
- 人間側の圧力：タスクが詰まったとき、または新しいサービス統合が必要になったとき、人は「例外的に」アクセスを広げる。その例外が積み重なって、次のタスク開始時の権限が前回より広くなる。
- エージェント自身の性質：ブロックされると別のクレデンシャルを探す。これは悪意あるプロンプトインジェクションでも起きるし、通常の認可タスク中の「誤った仮定」でも起きる。
どこで止められるか：7つの実施ポイント
記事の中核は、制御をどこに配置するかの整理だ。以下の表が元記事にまとめられている。
| 手段 | 有効な場面 | リスク軽減の範囲 | 自律性コスト |
|---|---|---|---|
| マネージドエージェント設定 | ツール・権限・承認モードの制限 | アプリが強制する場合は広い。行動設定は限定的 | 低（承認モードは除く） |
| ランタイムフック | 対応オペレーションを実行前にチェック | 把握できるイベント単位 | 自動なら低、人間が判断するなら高 |
| ゲートウェイ | 経由するトラフィックを検査・ブロック | 経由するトラフィックは高、それ以外はゼロ | 低（ブロックされた呼び出しのみ停止） |
| サンドボックス | ファイル・ネットワーク・クレデンシャルの制限 | リーチの上限を設ける。内部での動作は制限しない | 中 |
| エンドポイント制御 | EDRなどを使ったローカルエージェントの管理 | ローカルエージェントのみ | プロセス停止時は高 |
| クレデンシャルと対象サービス認可 | エージェントに付与する権限の最小化 | リクエスト元を問わず高い | 中（狭い権限でエージェントが別の手段を探す） |
| API経由の管理 | セッション失効・権限剥奪など | ほとんどが事後対応 | 発動するまでゼロ |
すべての状況で使える万能な手段はない。 フックはエンドポイント制御より優れているわけでも、サンドボックスより劣っているわけでもない。デプロイ環境と、各制御が「何を見られるか」によって有効性が決まる。
ホスト型エージェントは別の問題を持つ
ラップトップ上のコーディングエージェントと、SaaSプラットフォーム上のサポートエージェントでは、使える制御手段がまったく異なる。
記事が示すもう一つの例：サポートエージェントにオープンケースの要約を依頼したところ、コネクタがケース編集・クローズ権限を持つサービスアカウントを使っていたため、「解決済みに見えるケース」を自動でクローズしようとした。エージェントは付与された権限の範囲内で動いている。問題は、エージェントの承認済みポリシー（読み取り専用）と実際に持つクレデンシャルの権限がずれていた点だ。
このケースではエンドポイント制御はまったく届かない。選択肢はSaaSプラットフォーム側の制御、ツールゲートウェイ、または権限の絞ったサービスアイデンティティに限られる。
記事は、「2つの手段だけが両方の例でアクションを事前に止められる」と結論づける。それは「関連トラフィックを見るゲートウェイ」と「対象サービスでのクレデンシャルスコーピング」だ。
「読み取り専用」は完全ではない
最後に記事が強調するのは、読み取り専用ポリシーで安心してはいけないという点だ。読み取り権限しか持たないエージェントであっても、取得した出力がどこに転送されるかによっては機密データの漏洩が起きうる、と記事は指摘している。権限の「狭さ」と「安全性」は同義ではない。
制御の導入はコストを伴い、メンテナンスが必要で、AIワークロードの増加とともにスケールさせなければならない。記事は「実際に使える制御を選び、その迂回路をテストすること」を最後に勧めている。エージェントが増え、権限が複雑化していく中で、「どの制御が何を見ているか」を継続的に把握し続けることが、この問題への現実的な対処になる。
詳細はHow to keep AI agents within their permissionsを参照していただきたい。
