この記事は、LLM エージェントを プロンプトインジェクション（プロンプトインジェクション）から守ることについての論文をレビューするものであり、その論文が提案する 6 つのデザインパターンについての、このウィキの情報源である。著者はこの論文を、プロンプトインジェクションと LLM セキュリティに関する文献への優れた追加だと評し、その価値は論文が約束しないことから生まれていると捉えている。論文は汎用的な防御を提示するのではなく、エージェントが任意のタスクを解決することを意図的に妨げるというトレードオフを受け入れているのである。
記事はそのトレードオフについての論文自身の捉え方を引用している。エージェントとその防御の両方が現在の種類の言語モデルに依存している限り、汎用エージェントが意味のある信頼できる安全性の保証を提供することはありそうにない。そのため問いは、攻撃に耐えながら有用な仕事を生み出すエージェントとして、今日どのようなものを構築できるのかへと向け直される。記事はこれを非常に現実的なアプローチと呼び、エージェントが任意のタスクを実行する能力を制限することをいとわない姿勢は、不人気なトレードオフではあるが論文に信頼性を与えていると述べる。
要点
- 記事が論文から取り上げる組織原理は、エージェントが信頼できない入力を取り込んだ後は、その入力が重大な結果をもたらす行動を引き起こすことが不可能になるように、エージェントを制約しなければならないというものである。
- 記事はその原理を著者自身の言葉で言い直している。悪意のある可能性のあるトークンに少しでもさらされれば、そのプロンプトの出力は完全に汚染される。そしてトークンを挿入できる攻撃者は、モデルが出力するテキストと、モデルが行えるあらゆるツール呼び出しの両方を支配していると想定すべきである。
- 6 つのパターンが要約されている。Action-Selector パターン、Plan-Then-Execute パターン、LLM Map-Reduce パターン、デュアル LLM パターン、Code-Then-Execute パターン、Context-Minimization パターン である。
- 著者は、6 つのうち 1 つは自分自身のものだと指摘している。デュアル LLM パターンを自分が以前に提案したものだと説明し、論文は自分のパターンをそのまま記述していると述べ、それが図で示されていると報告している。記事はその以前の文章へのリンクを示しているが、それはこのページの情報源には含まれていないため、その日付とタイトルはここでは述べない。
- 記事は、十分に理解しきれなかったパターンが 1 つあることを明言しており、コンテキスト最小化パターンには少し混乱したと述べたうえで、自分なりの読み方を示している。
- 記事は、論文が 10 件のケーススタディで締めくくられ、それぞれに脅威モデルと緩和策が示されていると報告し、それらを列挙している。その中で SQL エージェントのケーススタディを、論文が 3 ページを割いている非常に難しい環境として特に取り上げている。
- ソフトウェアエンジニアリングのケーススタディから、記事は、コードエージェントが信頼できないドキュメントとやり取りするのは形式的な API 記述のような厳格にフォーマットされたインターフェースを通じてのみにすべきだという提案を引用し、懐疑も示している。十分に創造的な攻撃者なら 30 文字のメソッド名の中でもなお損害を与えられるのではないか、と疑問を口にしているのである。
- 著者は、3 年近くプロンプトインジェクションについて書いてきたが、正式な論文を書き上げる忍耐力はなかったと述べ、プロンプトインジェクションをエージェント型システムを責任をもって展開するうえでの最大の課題と呼んでいる。
背景
記事はこの論文を、以前に取り上げた別の論文との関係の中で位置づけている。記事はその以前の論文を、ツールを使う LLM システムにプロンプトインジェクションがもたらす課題のいくつかに対して信頼できる解決策を提案した、自分が見た最初の論文だと説明し、新しい論文は 6 つのパターンの中にその以前の提案を含めていると述べる。また、その以前の研究自体がデュアル LLM パターンの影響を受けていたとも報告している。これらの他の文書はこの記事による説明を通じてしか知られていないため、このページではそれらのタイトル、日付、著者を確定した事実として述べることはしない。