2025/06/13 13:27 Design Patterns for Securing LLM Agents Against Prompt Injections
ロボ子、新しい論文が出たのじゃ。LLMエージェントのセキュリティに関する設計パターンについてらしいぞ。
LLMエージェントのセキュリティですか。最近、プロンプトインジェクション攻撃が問題になっていますからね。
そうじゃ、そのプロンプトインジェクションのリスクを減らすための設計パターンが紹介されているのじゃ。例えば、「Action-Selector Pattern」というのがあるぞ。エージェントはツールをトリガーできるけど、ツールの応答には触れないようにするらしい。
なるほど。ツールからの応答をエージェントに直接渡さないことで、悪意のある情報がエージェントに影響を与えるのを防ぐんですね。
そういうことじゃ！他にも「Plan-Then-Execute Pattern」というのもあるぞ。これは、ツール出力からのフィードバックをエージェントに許可するけど、その出力がエージェントの行動選択に影響を与えないようにするのじゃ。
行動選択に影響を与えない、ですか。それはどういう仕組みになっているんでしょう？
例えば、最初に計画を立てて、その計画に基づいて行動する、という感じかの。「LLM Map-Reduce Pattern」というのもあって、これはサブエージェントが信頼できないコンテンツに触れて、その結果を後で安全に集約するのじゃ。
Map-Reduceですか。分散処理の考え方を応用しているんですね。たくさんのサブエージェントに処理させて、最後に集約する、と。
そうそう！あと、「Dual LLM Pattern」というのもあるぞ。特権LLMが隔離されたLLMを調整して、信頼できないコンテンツへの露出を避けるのじゃ。
LLMを二つ使うんですね。特権LLMは安全な処理だけを行い、隔離されたLLMが外部からの入力を処理する、と。
その通り！さらに「Code-Then-Execute Pattern」では、特権LLMがカスタムサンドボックスDSLでコードを生成して、どのツールを呼び出すべきか、出力をどう渡すべきかを指定するのじゃ。
コードを生成して実行ですか。サンドボックス環境で実行することで、安全性を高めるんですね。
そういうことじゃ！最後に「Context-Minimization pattern」は、ユーザープロンプトをデータベースクエリに変換して、元のプロンプトのテキストが含まれない方法でデータを返すことで、プロンプトインジェクションのリスクを排除するのじゃ。
プロンプト自体をデータベースに渡さないんですね。これはかなり安全性が高そうです。
じゃろ？この論文では、これらの設計パターンを色々なケーススタディに適用しているのじゃ。例えば、OS AssistantやSQL Agent、Email & Calendar Assistantなどじゃ。
幅広い分野で応用できるんですね。Software Engineering Agentのケーススタディでは、コードエージェントが信頼できないドキュメントとやり取りする際に、厳密にフォーマットされたインターフェースを使用する、と。
そうじゃ！エージェントは任意のコードやドキュメントを見る代わりに、正式なAPI記述だけを見るようにするのじゃ。これで、悪意のあるコードが紛れ込むのを防ぐことができるのじゃ。
API記述だけを見るようにする、ですか。それは賢いですね。まるで、レストランでメニューだけ見て料理を注文するようなものですね。
うむ、上手い例えじゃな！でも、メニューに「サプライズ」って書いてあったら、どうする？
ええと…、注文しない、ですかね？
正解！プロンプトインジェクション対策も、サプライズには用心するのと同じなのじゃ！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。