LLM08: 過剰なエージェンシー (Excessive Agency)
説明
LLM ベースのシステムは開発者によってある程度のエージェンシー、他のシステムとのインタフェースやプロンプトに応答してアクションを実行する機能、が与えられることがよくあります。どの機能を呼び出すかの判断は、入力プロンプトまたは LLM 出力に基づいて動的に決定する LLM 「エージェント」に委譲されることもあります。
過剰なエージェンシーは LLM からの予期しない/あいまいな出力に応答して有害なアクションを実行できる脆弱性です (LLM が誤動作する原因が何であるかに関係なく、ハルシネーション/作話、直接的/間接的プロンプトインジェクション、悪意のあるプラグイン、不十分な設計の無害なプロンプト、単にパフォーマンスが悪いモデルなど) 。過剰なエージェンシーの根本原因は一般的に過剰な機能、過剰な権限、過剰な自律性のうちの一つ以上です。これは LLM 出力の精査が不十分であることを懸念する安全でない出力処理とは異なります。
過剰なエージェンシーは機密性、完全性、可用性の領域にわたる広範囲の影響につながる可能性があり、LLM ベースのアプリがどのシステムとやり取りできるかに依存します。
脆弱性の一般的な例
過剰な機能: LLM エージェントはシステムの意図された操作に必要のない機能を含むプラグインにアクセスできます。たとえば、開発者は LLM エージェントにリポジトリからドキュメントを読み取る機能を付与する必要がありますが、開発者が使用することを選択したサードパーティプラグインにはドキュメントを変更および削除する機能も含まれています。
過剰な機能: プラグインが開発フェーズで試用され、よりよい代替品を優先して削除された場合でも、LLM エージェントは元のプラグインを引き続き利用できることがあります。
過剰な機能: 制約のない機能を備えた LLM プラグインは、アプリケーションの意図した動作に必要なもの以外のコマンドの入力命令を適切にフィルターできません。たとえば、ある特定のシェルコマンドを実行するプラグインは、他のシェルコマンドの実行を適切に防止できません。
過剰なパーミッション: LLM プラグインにはアプリケーションの意図した操作には必要のない他のシステムに対するパーミッションがあります。たとえば、データの読み取りを意図としたプラグインが SELECT パーミッションだけでなく UPDATE, INSERT, DELETE パーミッションも持つ ID を使用してデータベースサーバーに接続します。
過剰なパーミッション: ユーザーに代わって操作を実行するように設計された LLM プラグインは、汎用の高権限の ID でダウンストリームシステムにアクセスします。たとえば、カレントユーザーのドキュメントストアを読み取るプラグインは、すべてのユーザーのファイルにアクセスできる権限を持つアカウントでドキュメントリポジトリに接続します。
過剰な自立性: LLM ベースのアプリケーションやプラグインは影響の大きいアクションを個別に検証および承認できません。たとえば、ユーザーのドキュメントの削除を許可するプラグインはユーザーからの確認なしで削除を実行します。
予防および緩和戦略
以下のアクションで過剰なエージェンシーを防止できます。
LLM エージェントが呼び出せるプラグイン/ツールは必要最小限の機能のみに制限します。たとえば、LLM ベースのシステムが URL のコンテンツをフェッチする機能を必要としない場合、そのようなプラグインを LLM エージェントに提供すべきではありません。
LLM プラグイン/ツールに実装する機能は必要最小限に制限します。たとえば、ユーザーのメールボックスにアクセスして電子メールを要約するプラグインは、電子メールを読み取る機能のみを必要とするため、そのプラグインにはメッセージを削除したり送信したりするような他の機能を含めるべきではありません。
可能な限り制約のない機能 (シェルコマンドの実行、URL のフェッチなど) を避け、より細かい機能を持つプラグイン/ツールを使用します。たとえば、LLM ベースのアプリはファイルに出力を書き込む必要があるかもしれません。これをシェル関数を実行するプラグインを使用して実装すると、望ましくないアクションの範囲が非常に大きくなります (他のシェルコマンドが実行される可能性があります) 。より安全な代替策は特定の機能のみをサポートするファイル書き込みプラグインを構築することです。
LLM プラグイン/ツールが他のシステムに付与されるパーミッションを必要最小限に制限して、望ましくないアクションの範囲を制限します。たとえば、製品データベースを使用して顧客に購入を進める LLM エージェントは、'products' テーブルへの読み取りアクセスだけが必要かもしれません。他のテーブルへアクセスしたり、レポートを挿入、更新、削除することはできません。これは LLM プラグインがデータベースへの接続に使用する ID に対して適切なデータベースパーミッションを適用することで強制すべきです。
ユーザー認可とセキュリティスコープを追跡し、ユーザーに代わって実行されるアクションが特定のユーザーのコンテキストで必要最小限の権限でダウンストリームシステム上で実行されることを確保します。たとえば、ユーザーのコードリポジトリを読み取る LLM プラグインでは OAuth 経由かつ必要最小限のスコープでユーザーを認証する必要があります。
人間参加型 (human-in-the-loop) 制御を利用して、すべてのアクションを実行する前に人間が承認することを要求します。これはダウンストリームシステム (LLM アプリケーションのスコープ外) や LLM プラグイン/ツール自体に実装できます。たとえば、ユーザーの代わりにソーシャルメディアコンテンツを作成して投稿する LLM ベースのアプリには、'post' 操作を実装するプラグイン/ツール/API 内にユーザー承認ルーチンを含める必要があります。
アクションが許可されるかどうかを決定するために LLM に依存するのではなく、ダウンストリームシステムに認可を実装します。ツール/プラグインを実装する際には、完全な仲介の原則を適用して、プラグイン/ツールを介してダウンストリームシステムに対して行われるすべてのリクエストがセキュリティポリシーに対して検証されるようにします。
以下のオプションは過剰なエージェンシーを防止するものではありませんが、引き起こされる損害のレベルを制限できます。
LLM プラグイン/ツールおよびダウンストリームシステムのアクティビティをログ記録および監視して、望ましくないアクションが行われている場所を特定し、それに応じて対応します。
レート制限を実装して、一定時間内に起こりうる望ましくないアクションの回数を減らし、監視を通じて、望ましくないアクションを重大な損害が発生する前に発見する機会を増やします。
攻撃シナリオの例
LLM ベースのパーソナルアシスタントアプリは受信メールの内容を要約するためにプラグインを介して個人のメールボックスへのアクセスが許可されます。この機能を実現するために、電子メールプラグインはメッセージを読み込む機能が必要ですが、システム開発者が使用することを選択したプラグインにはメッセージを送信する機能も含まれています。LLM は間接プロンプトインジェクション攻撃に対して脆弱で、悪意を持って作成された受信メールで LLM を騙し、電子メールプラグインにコマンドして、'send message' 機能を呼び出し、ユーザーのメールボックスからスパムを送信します。これは以下で回避できます。 (a) メール読み取り機能のみを提供するプラグインを使用することで過剰な機能を排除します。 (b) 読み取り専用スコープでの OAuth セッションを介してユーザーの電子メールサービスに対して認証することで過剰なパーミッションを排除します。 (c) LLM プラグインによって作成されたすべてのメールをユーザーが手動でレビューして 'send' を押すことを要求することで過剰な自立性を排除します。 あるいは、メース送信インタフェースにレート制限を実装することによって引き起こされる損害を軽減できます。
参考情報リンク
Embrace the Red: Confused Deputy Problem: Embrace The Red
NeMo-Guardrails: Interface guidelines: NVIDIA Github
LangChain: Human-approval for tools: Langchain Documentation
Simon Willison: Dual LLM Pattern: Simon Willison
Last updated