OWASP LLM06 は「AI に権限を与えすぎる雑さ」を止めるための最低線だ
このノートは原文の代替ではありません。読むべきポイントと実装上の意味を整理し、原典への入口を示します。
要点まとめ
- AI に仕事を任せるときは、できるだけ賢い相棒として扱うより、余計な権限を持たせない不器用な作業員として設計したほうが事故を減らせる。
- このページの焦点は prompt injection そのものではなく、AI に不要な write、delete、send、execute 権限までまとめて渡す雑設計をどう止めるかにある。
- OWASP は mitigation として、open-ended tool を避ける、OAuth scope を最小化する、read-only を優先する、user review を残す、downstream system 側で complete mediation を行う、という停止線を並べている。
- 日本の AI 導入では、agent の危険が prompt injection に寄りがちだが、実際には与えすぎた scope と自動送信のほうが先に事故を起こしやすい。
読み終えたら次へ
この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。
何が変わったのか
このページは、危険を抽象論で終わらせず、agency の増え方を具体的に分けています。たとえば extension functionality が広すぎる、permission scope が広すぎる、autonomy が高すぎる、という形です。そのうえで mitigation も対応していて、mail 読み取りだけの extension にする、OAuth を read-only scope に絞る、送信前に user review を必須にする、といった具体策を並べています。 さらに重要なのは、authorization を LLM に任せるなという点です。OWASP は complete mediation を downstream system 側で実装し、各 request が security policy に照らして検証されるべきだと書いています。つまり「モデルがこれは許可される操作だと判断した」では不十分です。
なぜ重要か
日本語圏では、agent の安全策というと prompt injection、フィルタ、最終回答 moderation に話が寄りやすいです。しかし運用事故の多くは、もっと手前で起きます。read-only で足りる tool に write を渡す、send を自動化する、削除系 API を同じ token で束ねる、といった設計の雑さです。このページはその盲点を埋めます。 経営側や PM にも重要です。AI 導入の稟議では「どれだけ仕事が減るか」に目が向きますが、本当に止めるべきは「何を自動化しないか」です。OWASP LLM06 は、その停止線を権限と承認の言葉で説明しやすくしてくれます。
技術的ポイント
- `Excessive Agency` は、LLM application が不要に広い capability を持ち、危険な action を自律実行できてしまう状態を指す。
- mitigation の一つは open-ended tool を避けることだ。任意 shell、自由 URL fetch、広すぎる extension は被害範囲を急に広げる。
- OWASP は OAuth を例に、必要最小限の scope、できれば read-only scope を使えとしている。認証できることと、広い権限を渡すことは別問題である。
- `complete mediation` は、downstream system 側で全 request を policy に照らして再確認する考え方だ。認可を LLM 判断に埋め込まないのが要点になる。
- user review は旧式の手動確認ではなく、送信や変更のような irreversible action を AI から切り離す最後の停止線として残す意味がある。
英日キーワード
| 英語 | 日本語 | 補足 |
|---|---|---|
| Excessive Agency | 過剰な権限委譲 / 過剰な自律性 | AI に不要に広い capability を与え、危険な action を自律実行できてしまう状態。問題はモデルより設計者の権限付与にある。 |
| least privilege | 最小権限 | 必要最小限の権限だけを与える原則。agent では broad token を避ける出発点。 |
| read-only scope | 読み取り専用スコープ | OAuth などで変更操作を許さない権限範囲。AI へ渡す scope はまず read-only で足りるかから考えるべき。 |
| open-ended tools | 制約の弱い汎用ツール | 任意 shell や自由 URL fetch など、用途が広すぎて被害範囲を読みづらい道具。便利さの代わりに stop line を失いやすい。 |
| complete mediation | 完全な都度検証 | downstream system が各 request を毎回 policy で検証する原則。認可を LLM 判断の中へ埋め込まないために必要。 |
| downstream system | 下流システム | 実際に送信、削除、更新を行う先の system。AI が判断しても、最終認可はここで持つべきである。 |
試すなら
- まず各 agent が持つ tool と token を一覧化し、read-only で足りるのに write/delete/send を持っていないかを確認する。
- OAuth や API key の scope を棚卸しし、送信や削除を分離できるなら別 credential に分ける。
- open-ended shell や URL fetch を使っているなら、具体用途に絞った wrapper tool に置き換えられないか検討する。
- 送信、削除、支払い、公開のような戻しにくい操作は、人が最後に確認する設計を残す。
注意点
- このページは最低線を示すもので、どの操作を read-only にできるかは自社の業務分解が必要になる。
- approval を残しても、権限が広すぎれば人は危険な差分を見抜けないことがある。承認は最小権限の代替ではない。
- complete mediation を downstream system でやらないと、表向きに安全そうな agent でも裏では広い token で何でも実行できるままになる。
この記事は役に立ちましたか
公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。