OWASP Top 10 for LLM Applications 2025 について: ⑥ Excessive Agency

AI OWASP

説明

LLM（大規模言語モデル）を利用したシステムは、開発者によって一定の「エージェンシー（行動権限）」を付与されることが多い。
これは、LLMが関数を呼び出したり、拡張機能（ベンダーによって「ツール」「スキル」「プラグイン」とも呼ばれる）を通じて他のシステムと連携したりする能力を持つことを意味する。
また、どの拡張機能を使用するかの判断がLLMエージェント（LLM 'agent'）に委ねられることもあり、エージェントは入力プロンプトやLLMの出力を基に動的に決定する。
このようなエージェントベースのシステムでは、過去の呼び出し結果を元に、次の呼び出しを調整するため、LLMへのリクエストが繰り返し行われる傾向がある。

Excessive Agency（過剰なエージェンシー） とは、LLMが誤作動した場合に、意図しない破壊的なアクションが実行されるリスクを指す脆弱性である。
この誤作動の原因に関わらず、以下のような要因がトリガーとなることが多い：

  • ハルシネーション（Hallucination）/ 虚偽生成（Confabulation）
    • 適切に設計されていないプロンプト や 性能の低いモデル によって誤った出力が生成される
  • 直接的/間接的なプロンプトインジェクション
    • 悪意のあるユーザーによる攻撃
    • 悪意のある/侵害された拡張機能（またはその前回の呼び出し）による攻撃
    • マルチエージェント・協調型システムにおける悪意のあるエージェント による攻撃

Excessive Agency の主な原因
この脆弱性の根本的な原因として、以下の要素が挙げられる：

  • 過剰な機能性（Excessive Functionality）
    • LLMが不要なほど多くのアクションを実行できる
  • 過剰な権限（Excessive Permissions）
    • LLMが不必要なシステムやデータへのアクセス権を持っている
  • 過剰な自律性（Excessive Autonomy）
    • LLMが十分な制御なしに自己判断でアクションを実行する

影響（Impacts）
過剰なエージェンシーによるリスクは、LLMアプリが連携できるシステムによって異なるが、機密性（Confidentiality）・完全性（Integrity）・可用性（Availability） のいずれにおいても重大な被害をもたらす可能性がある。

注記：
Excessive Agency（過剰なエージェンシー）は Insecure Output Handling（不適切な出力処理）とは異なる概念 である。
不適切な出力処理は LLMの出力の検証不足に起因するが、過剰なエージェンシーは LLMが持つ権限や機能性が過剰であることに起因する点で異なる。

 

過剰なエージェンシー（Excessive Agency）の一般的なリスクの例

1. 過剰な機能性（Excessive Functionality）

ケース1

ケース2

  • 開発中に試用された拡張機能が、より適した代替手段が導入された後もLLMエージェントに利用可能な状態のまま放置されている

ケース3

  • 汎用的すぎるLLMプラグインが、意図しないコマンドの実行を防げていない
    • 例：特定のシェルコマンドを実行するための拡張機能が、不適切なフィルタリングにより他の任意のコマンドも実行可能になってしまう

2. 過剰な権限（Excessive Permissions）

ケース4

  • LLM拡張機能が不要な権限を持っている
    • 例：本来データを読み取るだけの拡張機能が、データベース接続時にSELECTだけでなく、UPDATE、INSERT、DELETEの権限も持っている

ケース5

  • 個々のユーザーの操作を想定した拡張機能が、高権限のアカウントで動作している
    • 例：ユーザーのドキュメントストアを読み取る拡張機能が、すべてのユーザーのデータにアクセスできる管理者権限で動作している

3. 過剰な自律性（Excessive Autonomy）

ケース6

  • LLMベースのアプリや拡張機能が、影響の大きいアクションを実行する前に適切な確認を行わない
    • 例：ユーザーのドキュメントを削除できる拡張機能が、ユーザーの確認なしに削除を実行してしまう


防御および緩和策（Prevention and Mitigation Strategies）

1. 拡張機能の最小化（Minimize Extensions）

  • LLMエージェントが呼び出せる拡張機能を最小限に制限する
    • 例：LLMアプリがURLの内容を取得する必要がないなら、そのような拡張機能は無効化する

2. 拡張機能の機能制限（Minimize Extension Functionality）

  • 拡張機能に実装される機能を必要最小限に抑える
    • 例：メールを要約する拡張機能は、メールを読む機能のみを持ち、削除や送信機能を持たないようにする

3. 汎用的な拡張機能の回避（Avoid Open-ended Extensions）

  • 広範な操作を可能にする拡張機能は避け、特定の機能に限定された拡張機能を使用する
    • 例：LLMアプリがファイルに書き込む機能を必要とする場合、シェルコマンドを実行する汎用的な拡張機能を使用するのではなく、ファイル書き込み専用の拡張機能を作成する

4. 拡張機能の権限最小化（Minimize Extension Permissions）

  • LLM拡張機能が外部システムに対して持つ権限を最小限に制限する
    • 例：顧客に商品の推薦を行うLLMエージェントは、データベースの「products」テーブルを読み取る権限のみを持ち、他のテーブルの操作やデータの変更権限は持たないようにする

5. 拡張機能をユーザーのコンテキストで実行する（Execute Extensions in User’s Context）

  • ユーザーの認可情報を追跡し、ユーザーごとの適切なセキュリティスコープ内で拡張機能を実行する
    • 例：LLMがユーザーのコードリポジトリを読み取る場合、OAuth認証を要求し、最小限の権限のみ付与する

6. ユーザー承認を必須とする（Require User Approval）

  • 影響の大きいアクションを実行する前にユーザーの承認を求める「Human-in-the-loop」制御を導入する
    • 例：ソーシャルメディアへ投稿を行うLLMアプリは、投稿処理を実行する前にユーザーの確認を求める

7. 完全な仲介（Complete Mediation）

8. LLMの入力・出力のサニタイズ（Sanitize LLM Inputs and Outputs）

  • OWASP ASVS（Application Security Verification Standard）に基づくセキュアコーディングのベストプラクティスを適用
  • 静的解析（SAST）や動的解析（DAST、IAST）を開発パイプラインに組み込む


リスクの影響を軽減する追加策

以下の対策は過剰なエージェンシーを完全に防ぐことはできないが、被害を最小限に抑えるのに役立つ：

  • 拡張機能や外部システムのアクティビティを監視・ログ記録する
    • 不適切なアクションを検出し、即座に対応可能にする
  • レート制限を実装する
    • 一定時間内に発生する不正なアクションの回数を制限し、大規模な被害が発生する前に検出する機会を増やす


攻撃シナリオの例

LLMを搭載したパーソナルアシスタントアプリが、拡張機能を通じてユーザーのメールボックスへアクセスする権限を付与され、受信メールの内容を要約する機能を提供している。
この機能を実現するために、拡張機能はメールの読み取り権限を必要とするが、開発者が選択したプラグインにはメールの送信機能も含まれている。

さらに、このアプリは間接的なプロンプトインジェクション攻撃（Indirect Prompt Injection）に対して脆弱であり、細工された悪意のあるメールを受信すると、LLMが誤って以下のような攻撃を実行してしまう：

  1. 攻撃者が特定のプロンプトを含むメールを送信
  2. LLMがこの内容を処理し、アシスタントエージェントに指示を出す
  3. エージェントがユーザーの受信トレイをスキャンし、機密情報を検索する
  4. 発見した機密情報を攻撃者のメールアドレスへ転送する

このリスクを防ぐ方法

1. 過剰な機能を排除（Eliminating Excessive Functionality）

  • 「メールの読み取り専用」の拡張機能を使用し、メール送信機能を持たないものに限定する

2. 過剰な権限を排除（Eliminating Excessive Permissions）

  • OAuth認証を利用し、メールサービスへのアクセスを「読み取り専用（read-only）」のスコープに制限する

3. 過剰な自律性を排除（Eliminating Excessive Autonomy）

  • LLMが作成した送信メールは、ユーザーが手動で確認し、「送信」ボタンを押さない限り送信されないようにする

被害を軽減する方法

  • メール送信インターフェースにレート制限を実装する
    • 一定時間内に送信できるメールの数を制限し、大量送信を防ぐ
    • 異常な動作を監視し、攻撃が進行する前に検出・ブロックする

 

 

ほなほな。