Context-Minimization パターンは、もはや必要のなくなったコンテキストを破棄することでインジェクションを防ぐ。プロンプトインジェクションから LLM エージェントを守るためのデザインパターン で引用されているとおり、元の論文は、ある種のユーザーによるプロンプトインジェクションを防ぐために、エージェントシステムは複数回のインタラクションにわたって不要なコンテンツをコンテキストから取り除くことができる、と述べている。同じグループに属する他の五つのパターンとこれを区別しているのは、脅威の向きである。取り除かれるコンテンツはユーザー自身のプロンプトであり、したがって防御の対象となる攻撃者は、リクエストを行っている当人である。
用法
挙げられている例は、カスタマーサービスのチャットボットである。悪意のあるユーザーが新車の見積もりを求め、大幅な値引きを認めさせる指示を注入しようとする。システムはまずユーザーのリクエストを——最新のオファーを見つけるための——データベースクエリに変換し、その結果を顧客に返す前に、ユーザーのプロンプトをコンテキストから取り除く。こうして、応答が生成される時点では、注入された指示はもはや存在しない。
このパターンを取り上げた記事は、自らの解釈を示す前に、このパターンには少し戸惑っていると記している。その解釈とは、ユーザーのプロンプトが生のデータを返す SQL クエリに変換され、そのデータが元のプロンプトのテキストを一切含みえない形で返されるのであれば、インジェクションが生き残る可能性はすべて排除されるはずだ、というものである。この解釈は論文の内容を言い直したものではなく記事自身の解釈であり、記事もそのようなものとして提示している。
適用される場面
このパターンが当てはまるのは、ユーザーのリクエストを、後のステップが必要とするすべてを捉えた構造化された中間表現——クエリやパラメータの集合——に還元でき、リクエストを失うことなく元の文言を捨てられる場合である。このパターンは、そのような還元が可能であり、下流のどのステップも生のプロンプトを必要としないことを前提とする。ユーザーの正確な言い回しが応答にまで残らなければならない状況では誤用となり、また、このパターンが対処するのは取り除かれるコンテンツに含まれる指示だけである。検索された文書やツールの結果から入ってくる素材は別の種類の露出であり、それにはグループ内の他のパターンが対処する。
これは、有用性と プロンプトインジェクション への耐性との間のトレードオフとしてまとめて提示された六つのパターンの一つであり、ここでの説明は論文のものではなく、それを取り上げた記事の筆者のものである。
関連用語
- プロンプトインジェクション — 攻撃の類型。ここではユーザーが攻撃者となる直接型の形態
- ジェイルブレイク — 同じくアプリケーション自身のユーザーが攻撃者となる、隣接する攻撃
- コンテキストエンジニアリング — モデルのコンテキストを何が占めるかを管理する一般的な実践。ここではそれがセキュリティ上の目的に適用されている
- プロンプトインジェクションから LLM エージェントを守るためのデザインパターン — この説明の出典