AIセキュリティとプロンプトインジェクション

プロンプトインジェクションは、大規模言語モデル（LLM）の上に構築されたアプリケーションを特徴づけるセキュリティ問題であり、OWASP Top 10 for LLM Applicationsの筆頭に挙げられているのも当然です。攻撃者はモデルが読み取る場所にテキストを置き、モデルは開発者の指示ではなくそのテキストに従ってしまいます。

私たちは、これを完全な修正策が存在しない、未修正の脆弱性クラスとして扱うべきだと考えています。検知は有用であり、活用すべきです。しかし本当に重要な設計作業は、モデルがときに操作されてしまうことを前提とし、その結果を確実に封じ込めることにあります。

直接インジェクションは、アプリケーションに入力している本人から行われます。システムプロンプトを上書きする、抜き出す、あるいはプロダクトが許可していない振る舞いへとモデルを誘導しようとするものです。これはよく知られたケースであり、その影響は通常、そのユーザーがもともと到達できた範囲にとどまります。

間接インジェクションはより深刻です。悪意のあるテキストは、何も知らないユーザーの代わりにモデルが処理するコンテンツに紛れて届きます。要約を頼まれたWebページ、RAGパイプラインが取得したドキュメント、エージェントがトリアージしている受信トレイのメール、サポートチケットのフィールド、別のツールの出力などです。ユーザーがその指示を目にすることはありません。モデルは目にし、ユーザーの権限で行動します。

SQLインジェクションは、パラメータ化クエリによって解決されました。これはコードとデータの構造的な分離をデータベースに与える仕組みです。言語モデルにはそれに相当するものがありません。システムプロンプトも、ユーザーメッセージも、取得したドキュメントも、すべて1つのコンテキスト内のトークンであり、指示に従おうとするモデルの傾向は、その指示がどこから来たかに左右されません。区切り文字やロールマーカーは、モデルがたいていは尊重する慣習にすぎず、越えることのできない境界ではないのです。

入力分類器やガードモデルは、成功する攻撃の数を減らします。ただしこれらは確率的であり、攻撃者は言い換え、他言語、エンコーディング、複数のドキュメントに分割した指示などを使って、際限なく再試行できます。大半の試行を止める統制は、軽い気持ちの悪用には有効ですが、動機を持った相手には不十分です。私たちはこうしたフィルターを1つの層として使いますが、設計が安全であるとみなす根拠にすることは決してありません。

インジェクションが与えうる損害の上限は、モデルが呼び出せるものによって決まります。人間が読むテキストを生成するだけのアシスタントは、乗っ取られても迷惑な存在にとどまります。一方、メールを送信し、クエリを実行し、社内APIを呼び出せるエージェントは、その入力を支配する者にとっての遠隔オペレーターになります。

最も被害が大きくなるのは、モデルが非公開データにアクセスでき、信頼できないコンテンツを読み、かつ情報を外部へ送る何らかの手段を持っているという組み合わせです。3つのうちどれか1つを取り除けば、攻撃の価値はほとんど失われます。外向きのチャネルは、ツールのようには見えないため、最も見落とされやすい要素です。

Markdownの画像をレンダリングするチャットインターフェースは、モデルが出力したどのようなURLでも取得しに行きます。そしてクエリ文字列には、モデルがそそのかされて埋め込んだ内容を何でも載せられます。クリック可能なリンク、Web取得ツール、Webhook、さらにはサードパーティに送信される検索クエリも、同じ役割を果たします。私たちは、レンダリングする画像と外向きのリクエストをドメインの許可リストに制限し、パラメータを含むモデル生成のURLを除去または無害化し、エージェントのネットワークアクセスはエグレスプロキシを経由させます。

モデルが生成するものはすべて、匿名ユーザーから届いたデータと同じように扱うべきです。ページに挿入するのであれば、そのコンテキストに合わせてエンコードします。データベースクエリの一部になるのであれば、クエリをパラメータ化します。シェルやインタープリターに渡すのであれば、そのステップは認証情報もネットワークも持たないサンドボックス内で実行します。構造化出力はパースしてスキーマで検証し、検証の失敗はエラーとして扱います。モデルに際限なく問い直して修復するものではありません。

これはエージェント間にも当てはまります。マルチエージェントのワークフローでは、あるエージェントの出力が別のエージェントの入力になります。受け渡しのたびに型付けと検査を行わない限り、最初のエージェントに届いたインジェクションがチェーン全体に伝播しかねません。

資金を動かす、第三者にメッセージを送る、データを削除する、権限を変更するといった操作には、人による確認を必須とすべきです。確認画面には、モデルが意図を要約した文章ではなく、バックエンドが実際に実行するパラメータそのものを表示しなければなりません。要約は、侵害されているかもしれないコンポーネントが生成したものだからです。

トレードオフは、承認プロンプトの効果がすぐに薄れてしまうことです。すべてのステップで確認を求めると、人は読まずに承認するようになります。私たちは承認を、取り消せない操作や外部から見える操作に限定し、取り消し可能で影響の小さいステップは、厳しい制限の範囲内で自動実行させます。完全に自律的なエージェントが妥当な選択となるのは、入力が信頼できる場合か、ツールが害を及ぼしえない場合だけです。

インジェクションへの耐性は、プロンプトの編集やモデルのアップグレードのたびに変化するため、リグレッションテストが必要です。私たちは、指示が埋め込まれたドキュメントを含む敵対的入力のスイートを維持し、CIでパイプライン全体に対して実行します。アサーションはテキストだけでなく、ツール呼び出しにもかけます。本番環境では、すべてのツール呼び出しをその直前のコンテンツとともにログに記録し、インシデントを原因となったドキュメントまでさかのぼって追跡できるようにします。