プロンプトインジェクション防御パターンの比較

このウィキのいくつかのページは、プロンプトインジェクション が有害なエージェントの振る舞いにつながるのを防ぐための設計を記述している。そのうち 6 つは 1 本の論文に由来するもので、このウィキでは プロンプトインジェクションから LLM エージェントを守るためのデザインパターン にある Simon Willison によるその論文のレビューを通じてのみ知られている。さらに 3 つは別々の出典に由来する。USENIX Security の論文、Microsoft のエージェントフレームワークにおけるアーキテクチャ決定記録、そして OpenAI の記事である。本ページはこれらを並べて示し、どこが異なるかを引き出す。順位付けはしない。6 つのパターンは出典において、順位付けされた一覧としてではなく、エージェントの有用性とインジェクションへの耐性との間のトレードオフとして示されており、残りの 3 つはそれぞれ異なる文脈に由来するからである。

6 つのパターンに共通する前提

レビューは、この論文の構成原理を強調している。エージェントが信頼できない入力を取り込んだら、その入力が重大な結果を伴うアクションを引き起こすことが不可能になるように、エージェントを制約しなければならない、というものである。レビューは、エージェントとその防御がいずれも現在の種類の言語モデルに依存している限り、汎用エージェントが意味のある信頼できる安全性の保証を提供できる見込みは低いという論文の見解を引用している。レビューは、エージェントが任意のタスクを実行する能力を制限することをいとわない姿勢を、歓迎されないトレードオフと呼んでいる。6 つのパターンはそれぞれ、特定の保護と引き換えにより範囲の狭いエージェントを受け入れており、何を手放すかが異なる。

6 つのパターンの比較

パターン	信頼できないコンテンツが届く先	保護されたまま残るもの	手放すもの・前提とするもの
Action-Selector パターン	どこにも届かない。アクションからのフィードバックがエージェントに戻ることは一切許されない	エージェントのアクションの選択が完全に保護される	取得を目的とするアクション（メールを読む、ページを取得するなど）は使えない。自己完結したアクションの集合を事前に列挙できることを前提とする
Plan-Then-Execute パターン	ツールの出力はエージェントに戻るが、それはツール呼び出しの順序が確定した後に限られる	どのツールを実行するかと、計画時に確定したパラメータ。例ではメールの宛先	後続ステップの内容は露出したままである。例ではメールの本文。リクエストだけから計画を立てられることを前提とする
LLM Map-Reduce パターン	サブエージェントが信頼できない項目を読み、コーディネーターは制約された結果（例ではファイルごとの真偽値）だけを受け取る	コーディネーターは信頼できないテキストを一切見ない	タスクが項目ごとの独立した判断に分解できることを前提とする。サブエージェントは自分の担当項目について誤りうる
デュアル LLM パターン	隔離された LLM がそれを読み、特権 LLM はそれを不透明な変数としてのみ扱う	ツールを保持する特権 LLM は、汚染されたテキストを一切読まない	作業を不透明なハンドルに対する操作として表現できることを前提とする。考案者自身、そうしたシステムの構築は本当に厄介だと述べている
Code-Then-Execute パターン	ツールの出力は、特権モデルがサンドボックス化されたドメイン固有言語で書いたプログラムの中を流れる	汚染されたデータがどこへ流れるかが、何かが実行される前にデータフロー解析で追跡される	独自の言語と、それを実行するサンドボックスを前提とする。保証は解析がモデル化している範囲に限られる
Context-Minimization パターン	ユーザー自身のプロンプト。ただしデータベースクエリのような構造化された中間表現に変換されるまで	ユーザーのプロンプトに注入された指示は、応答が生成される時点ではもうコンテキストにない	対処するのは取り除かれた内容だけで、取得された文書やツールの結果には対処しない。ユーザーの正確な言い回しを応答まで保持しなければならない場合には適さない

6 つのパターンの相互関係

各ページはこれらのパターンを隣り合うものとして記述しており、それぞれが他のパターンが残した問題に答えている。Action-Selector は Plan-Then-Execute のより厳格な隣人である。一方はツールの出力を一切受け入れず、もう一方は受け入れるが、アクションの選択が確定した後に限る。LLM Map-Reduce は、Plan-Then-Execute が残す露出、すなわち悪意ある指示が後続ステップに渡される内容に影響するという問題に、信頼できないテキストを出力の形が制約されたサブエージェントの中にとどめることで対処する。デュアル LLM パターンも、信頼できないものの読み取りを別のモデルの背後に隔離するが、集約された判断ではなく記号的な変数を返す。Code-Then-Execute はデュアル LLM パターンの改良版として記述されている。デュアル LLM パターンが信頼できないコンテンツを不透明な変数に閉じ込めるのに対し、専用に作られた言語のプログラムでは、どのツールが汚染された値を消費するかについてもシステムが推論できるようになる。

Context-Minimization は脅威の向きが異なる。他の 5 つでは、信頼できないテキストは外部、すなわちウェブページ、メール、ファイルから届く。ここで取り除かれる内容はユーザー自身のプロンプトであり、したがって攻撃者はリクエストをしている本人である。例は、サービスのチャットボットに自動車の見積もりを求めながら、値引きを注入しようとする顧客である。レビューはこのパターンに少し戸惑っていると述べており、レビュー自身によるその読み方は、論文の記述ではなく解釈として示されている。

6 つ以外の設計

構造化クエリ は、その周りに構築されるエージェントではなく、モデルへのインターフェースを変える。入力はプロンプトとデータという 2 つの別々の部分として送られ、モデルはプロンプト部分にある指示にだけ従うように訓練される。その出典である StruQ：構造化クエリによるプロンプトインジェクションへの防御 は、古典的なインジェクション攻撃からの類推によってこの発想に至っており、SQL のプリペアドステートメントを修正のモデルとして挙げている。適用対象はプログラムから利用される LLM 統合アプリケーションであり、自由な複数ターンの会話を行うウェブのチャットボットではないとされている。また、ジェイルブレイクやデータ抽出を防ぐようには設計されていない。

FIDES は、フレームワークのミドルウェアでラベルを強制する。コンテンツは完全性ラベルと機密性ラベルを持ち、それらは最も制限の強いものが優先されるポリシーのもとで組み合わされる。ミドルウェアはラベルを伝播させ、ツール呼び出しが実行される前にポリシーを確認する。その構成要素のうち 2 つは、デュアル LLM パターンのページが記述する仕組みに対応している。信頼できないコンテンツを参照の背後に置いてモデルのコンテキストから遠ざける変数の間接参照と、信頼できないデータが処理される隔離された経路である。その決定記録は、プロンプトエンジニアリングによる防御、コンテンツのサニタイズ、別個のエージェントインスタンス、実行時監視単独のそれぞれと比較検討し、いずれも退けている。

Safe Url は、情報が外へ出ようとする地点で作用する。アシスタントが会話の中で知った情報が第三者に送信されようとしていることを検出し、送信される内容をユーザーに示して確認を求めるか、送信をブロックしてエージェントに別の方法を探すよう指示する。これは特にデータ流出を対象としており、出典はこれを安全性トレーニングの背後に置いている。つまり、エージェントがすでに説得されてしまったまれなケースを扱うものである。

それぞれが介入する場所

9 つの設計は異なる場所で作用する。

• エージェントの構造において：6 つのパターン。どのコンポーネントが信頼できないコンテンツを読んでよいか、そしてそこから行動するコンポーネントへ何が流れてよいかを決める。
• モデルの入力インターフェースと訓練において：構造化クエリ。プロンプトとデータを分離し、既存のモデルをその分離を尊重するようにファインチューニングする。
• フレームワークのミドルウェアにおいて：FIDES。各ツール呼び出しでラベルを伝播させてポリシーを確認する。オプトイン方式で、エージェントまたはツールごとに適用される。
• 外部への送信の時点において：Safe Url。データが第三者に送られようとするときにユーザーに確認するかブロックする。確認する場合には ヒューマン・イン・ザ・ループ の制御となる。

それぞれの背後にあるもの

証拠の種類は、設計そのものと同じくらい異なる。

• 6 つのパターンは、論文そのものではなくレビューを通じて知られている。レビューによれば、論文は 10 件のケーススタディで締めくくられており、それぞれに脅威モデルと緩和策が示されている。デュアル LLM パターンについては、そのページが、これは 1 人の研究者の提案として始まったものであり、文献で広く取り上げられていることは実運用や測定された有効性の証拠ではないと記している。
• 構造化クエリは実装が 1 つあり、著者ら自身が 2 つの 7B のオープンソースモデルで評価している。論文自身の結論は、これは確立した方向ではなく有望な方向だというものである。
• FIDES は、ステータスが proposed（提案中）の決定文書に記録されている。そこではパフォーマンスのベンチマークとユーザー受け入れテストが未チェックのまま残されており、この設計がリリースされたかどうかについては、どちらとも述べていない。
• Safe Url は、1 つのベンダーが自社の運用中の防御について記述したものである。出典には有効性の数値も独立した評価も示されていない。