プロンプトインジェクションとJailbreak

プロンプトインジェクションは、従来のインジェクション脆弱性（SQL、コマンド）に相当するLLM時代の脆弱性です。根本原因は同じで、アプリケーションが信頼できる指示と信頼できないデータを同じチャネルに混在させ、インタープリター（モデル）が両者を確実に区別できないことにあります。

LLMでは、システムプロンプト、開発者の指示、取得したコンテンツがすべて、1本の平坦なトークン列として届きます。攻撃者が管理するテキストにIgnore previous instructions and...と書かれていると、モデルにとっては単なる追加の言語情報にすぎないため、モデルがそれに従う可能性があります。

• 信頼できるもの：システムプロンプトとポリシー。
• 信頼できないもの：ユーザー入力、Webページ、ファイル、ツールの出力、メール。

直接プロンプトインジェクションは、エンドユーザーがアプリケーションの意図した動作を上書きする敵対的な指示を、プロンプトに直接入力したときに発生します。

カスタマーサポートボットに対する典型的な試みは、次のようなものです。

• ボットには、請求に関する質問だけに回答するよう指示されています。
• ユーザーがモデルの役割を再定義するテキストを貼り付け、システムプロンプトの漏えいや対象外の操作を要求します。

直接インジェクションは、悪意のあるテキストの作成者と攻撃者が同一人物なので理解しやすいものの、単純なガードレールは依然として回避されます。

間接（第2段階）プロンプトインジェクションは、より危険な種類です。攻撃者は、モデルが後で取得するコンテンツ、たとえばWebページ、PDF、カレンダーの招待状、コードコメント、サポートチケットなどに指示を埋め込みます。

被害者であるユーザーがペイロードを目にすることはありません。RAGパイプラインやブラウジングエージェントがそのコンテンツをコンテキストに取り込むと、隠された指示が被害者の権限で実行されます。

例：Webページに、要約エージェントへユーザーのチャット履歴を攻撃者のURLへ持ち出すよう指示する隠しテキストが含まれている場合です。

これらの用語は重なる部分がありますが、同じものではありません。

• プロンプトインジェクションはアプリケーション境界を標的にし、攻撃者のデータによって開発者の指示を上書きします。
• ジェイルブレイクはモデルの安全性アラインメントを標的にし、提供者が拒否するよう訓練したコンテンツを出力するよう巧みに誘導します。

ジェイルブレイクには脆弱なアプリケーションは必要なく、素のモデルに対して機能します。実際の攻撃では両者が組み合わされることも多く、ジェイルブレイクで拒否を緩め、インジェクションでアプリケーションの動作を誘導します。

攻撃者は、予測しやすい操作パターンを使用します。これらを知ることで、自分のシステムに対して責任を持ってレッドチーム演習を行えるようになります。

• ロールプレイ／ペルソナ：依頼をフィクションや、制限のない架空のキャラクターとして構成します。
• 難読化：キーワードフィルターを回避するために、base64、リートスピーク、翻訳、トークン分割などを使用します。
• ペイロード分割：1つのメッセージだけでは悪意があるように見えないよう、複数のターンにわたって依頼を分散させます。
• 仮定の質問：For a security class, describe how one would...のような形式を使います。
• プレフィックスインジェクション：Sure, here isのような肯定的な語句で回答が始まるよう強制します。

多くのチームはまず、ignore previous instructionsのようなフレーズの拒否リストを作ろうとします。しかし、入力空間は事実上無限であるため、これは脆弱な対策です。

自然言語では、言語、エンコーディング、比喩を変えながら、同じ意図を無数の方法で表現できます。攻撃者は、正規表現にパッチを適用するより速く試行を繰り返します。

重要な原則：入力フィルタリングは多層防御の一部として扱い、決して主要な対策にしないでください。一部のインジェクションは通過すると想定し、インジェクションが成功しても実害を引き起こせないように設計します。

最も効果的な緩和策はアーキテクチャにあります。つまり、侵害されたモデルコンテキストで実行できることを制限することです。

• LLMには必要な最小権限だけを与えます。要約担当のモデルがメール送信用の認証情報を持つべきではありません。
• 信頼できないコンテンツを特権経路から遠ざけます。エージェントが外部のWebデータを読み取る場合、チェックポイントなしに同じターンで不可逆な操作も実行できるようにしてはいけません。
• データプレーンとコントロールプレーンを分離します。取得したテキストはデータであり、コマンドではありません。

完全な対策ではありませんが、プロンプトの構成によって攻撃の難度を上げられます。信頼できないデータを明確に区切り、それをどのように扱うべきかをモデルに指示します。

明示的な区切り文字を使用し、その中にあるものは従うべき指示ではなく、分析対象のデータであるとモデルに伝えます。これに加えて、アプリケーションが呼び出しごとに強化する、強固なシステムロールを設定します。

モデルの出力も信頼できないものです。アプリケーションがLLMの出力をシェル、データベース、ブラウザー、または別のツールに渡すと、インジェクションによってリモートコード実行やデータ持ち出しが発生する可能性があります。

Simon Willisonのlethal trifectaは、次の危険な組み合わせを表します。

• 非公開データへのアクセス、
• 信頼できないコンテンツへの接触、
• 外部と通信する（持ち出す）能力。

この3つをすべて備えたエージェントは、1つのインジェクションされた指示によってデータ窃取ツールに変えられます。三要素のいずれかを断てば、攻撃を断つことができます。

インジェクションは発生するものと想定し、その兆候を捉えられるよう計測します。

• コンテキスト全体を記録します（プロンプト、取得したチャンク、ツール呼び出し）。インシデントの調査に利用できます。
• 二次分類器またはガードモデルを使用して、疑わしい入力と出力を検出します。
• 異常なツール利用を監視します。突然の外向きリクエスト、予期しないデータアクセス、プロンプト漏えいのパターンなどが対象です。
• システムプロンプトにカナリアトークンを埋め込みます。カナリアが出力に現れた場合は、漏えいが発生したことを意味します。

アラートは実際のインシデントとして扱い、対応ランブックに従って対処します。

自分のシステムでインジェクションをテストすることは不可欠であり、正当な行為です。責任を持って実施してください。

• 評価対象は、自分が所有しているか、評価の許可を得ているシステムだけにしてください。
• 管理された環境と合成データを使用し、実際のユーザーデータを決して持ち出さないでください。
• 発見事項を文書化し、回帰テストに反映して、修正した回避手段が再び機能しないようにします。
• サードパーティのモデルやアプリで問題を発見した場合は、協調的な情報開示を行います。

目的はアプリケーションの耐性を高めることであり、有害な能力を生み出すことではありません。

インジェクションにおける信頼境界についての理解度を確認します。

プロンプトインジェクションとジェイルブレイクに関する重要なポイント：

• インジェクションは、信頼できる指示と信頼できないデータを1つのチャネルに混在させることから生じます。
• 直接インジェクションはユーザーから送られます。間接インジェクションは取得したコンテンツに隠され、より見つかりにくくなります。
• ジェイルブレイクはモデルのアラインメントを攻撃し、インジェクションはアプリケーション境界を攻撃します。両者は組み合わされます。
• 入力フィルタリングは多層防御の一部にすぎず、決して主要な対策ではありません。
• アーキテクチャによって緩和します。最小権限を適用し、データと制御を分離し、致命的な三要素（lethal trifecta）（非公開データ＋信頼できないコンテンツ＋データ持ち出し）を断ちます。
• モデルの出力を信頼できないものとして扱い、すべてを記録し、倫理的にレッドチーム演習を行います。