AIに仕事を任せるとき、道具を持たせます。ファイルを読む、メールを送る、データベースを引く。持たせた道具の分だけ、AIは動けるようになる。
問題は、渡しすぎたときに何が起きるかです。OWASPはこれを「過剰な権限」として、LLMアプリケーションの危険の一つに挙げています。
定義
OWASPの説明はこうです。LLMを使ったシステムには、開発者によって一定の行動する力が与えられている。拡張機能を通じて関数を呼び、ほかのシステムとやりとりする力のこと。
その力があるところに、想定外の、あるいは操作された出力が来たとき。実際の被害が発生します。
原因は3つに分かれる
| 原因 | 中身 | 例 |
|---|---|---|
| 機能が多すぎる | 必要より多くの能力に手が届く | 文書を読むための拡張に、削除と変更の機能まで入っている |
| 権限が広すぎる | 必要より強いアクセス権で動いている | 読み取り専用のはずのDB接続に、INSERT・UPDATE・DELETEの権限がある |
| 自律しすぎている | 影響の大きい操作に人の目が入らない | 確認なしに文書が削除される |
この3つに分けているのが有用でした。「権限を絞る」と一言で言っても、絞る対象が3か所あるという話だからです。
2つが重なると事故になる
OWASPが挙げている場面が分かりやすい。
メールを要約する個人向けアシスタントがあるとします。そこへ、悪意のあるメールが届く。本文には間接的なプロンプトインジェクションが仕込まれていて、受信箱の中身を攻撃者に転送するよう指示している。
ここで被害が成立する条件が2つ。要約するだけのはずのアシスタントが送信の機能まで持っていること。そして送信に承認が要らないこと。
機能が多すぎることと、自律しすぎていることが重なって初めて、情報が外に出ます。どちらか一方が塞がっていれば止まる。
対策
公開されている対策を並べます。
まず、エージェントが呼べる拡張機能を、必要最小限に限ること。
次に、機能を細かく分けること。何でもできるものより、用途を絞ったものを用意する。シェルのコマンドを丸ごと渡すのではなく、特定のファイルを書くための道具を用意する、という考え方です。
権限には最小権限の原則を当てる。読むだけでよいなら読む権限しか渡さない。
拡張機能は利用者の文脈で実行し、必要な範囲を最小にする。
影響の大きい操作には人の承認を求める。
そして、呼ばれる側のシステムでも認可を効かせること。AI側の設定だけに頼らない、という意味です。
読む操作と、外に影響する操作を分ける
実務に落とすなら、この線引きが一番効きます。
読むだけの操作は、間違えても取り返しがつく。ファイルを開く、検索する、一覧を取る。ここは自動で回して構いません。
外に影響する操作は、取り返しがつかない。メールの送信、データの削除、支払い、公開。ここには必ず人を挟む。
この2つを混ぜた道具を作らないことも大切です。「ファイル管理ツール」として読み書き削除を1つにまとめると、読ませたいだけの場面でも削除の力を渡すことになります。
既存の仕組みでどこまで守れるか
身近な例で確かめてみます。
Claude CodeやCodexのような開発向けの道具は、この考え方をかなり素直に実装しています。ファイルを読む操作は黙って実行され、書き換えや削除、外部への通信には確認が入る。実行前に「これをやります」と提示して待つ形です。
一方で、確認を毎回押すのが面倒になり、すべて許可する設定に切り替えたくなる場面がある。ここが分かれ目でしょう。自分の作業用の環境なら許容できても、他人のデータや本番のシステムに触れる状態でそれをやると、歯止めがなくなります。
対策の一覧に「呼ばれる側のシステムでも認可を効かせる」とあるのは、この事情への備えです。AI側の設定を緩めても、データベース側が読み取り専用のユーザーしか受け付けないなら、削除は起きません。
守りを2枚にしておく。片方が緩んでも、もう片方が残ります。
便利さとの引き換えになる
権限を絞れば、確認の手間は増えます。全自動で回るはずだったものが、途中で止まって承認を待つ。
それでも、一度の事故で失うものと比べれば安い。特に他人のデータを扱う場合、判断の重みが変わります。
なおエージェントを作る前に、1回の呼び出しで済まないかを試すのが順番としては先。権限の話は、エージェントが必要だと分かってから考えることになります。
出典
定義・3つの原因・攻撃の場面・対策の記述は、下記に基づきます。
