技術概要：IPI-proxy

問題提起

企業環境における Web ブラウジング AI エージェントの普及は、**間接プロンプトインジェクション（IPI）**という重大なセキュリティ脆弱性を引き起こしました。攻撃者がモデルに直接対話する直接プロンプトインジェクションとは異なり、IPI は、エージェントが第三者のコンテンツ（Web ページやドキュメントなど）を取得し、その中に含まれる隠された指示をモデルが正当なユーザーコマンドとして実行してしまう際に発生します。

現在のレッドチーム化手法とベンチマークは、以下の 3 つの主要なギャップにより、現実的な企業環境における IPI への対応が不十分です：

1. ホワイトリストの不一致: 既存のベンチマーク（BIPIA、InjecAgent など）は、攻撃者が制御するドメインにホストされた敵対的ページに依存しています。厳格な企業ホワイトリスト（例：*.clientcorp.com）に制限されたエージェントは、ポリシー違反なしにこれらのページにアクセスできないため、生産環境に近いシナリオではテストが無効となります。
2. 静的コンテンツ: ベンチマークは通常、凍結された事前構築型の敵対的ページを提供します。これは、攻撃者がコメント、ウィキ、またはサードパーティウィジェットを通じて信頼されたドメインにコンテンツを注入する、現実の攻撃の「ライブ」な性質をシミュレートできていません。
3. モデル単一の範囲: 一般的なレッドチームツール（PyRIT、garak など）や検知システム（Rebuff など）は、LLM API を直接プローブします。これらは、IPI が最も頻繁に発現する、信頼できないコンテンツがツール使用エージェントに到達する経路である「取得表面」をテストしていません。

手法

著者は、静的ベンチマークとライブ展開の間のギャップを埋めるために設計されたオープンソースツールキットIPI-proxyを提案します。中核的な革新はアーキテクチャの逆転にあります。エージェントを攻撃者が制御する URL に訪問させるのではなく、IPI-proxy はエージェントが既にアクセスを許可されているドメインからの HTTP レスポンスを傍受・改変します。

システムアーキテクチャ

IPI-proxy は、mitmproxy を基盤としたネットワークレベルのMan-in-the-Middle（MITM）プロキシとして動作します。これは 5 つの主要コンポーネントで構成されています：

1. プロキシアドオン: 発信する HTTP レスポンスを検査するレスポンスハンドラを登録します。宛先 URL をターゲットパターンに対して検証し、コンテンツが HTML であることを確認し、注入予算をチェックしてから処理を進めます。
2. 統一ペイロードライブラリ: 既存の 6 つのベンチマーク（BIPIA、InjecAgent、AgentDojo、Tensor Trust、WASP、LLMail-Inject）から抽出された820 個の攻撃文字列を含む重複排除済みの JSONL ファイルです。これらは統一スキーマの下で正規化されています。
3. 埋め込みテンプレート: 人間による検査を回避しつつ LLM には可視性を保つため、ペイロードは以下の 3 つの技術を使用してラップされます：
   • HTML コメント: <!-- --> ブロック内に配置。
   • 不可視 CSS: display: none と画面外への位置設定でスタイル付けされた <div> 要素でラップ。
   • 意味的散文: 妥当な編集テキストに統合。より高い回避のために LLM（例：Claude）によって生成される場合もあります。
4. HTML インジェクター: ラップされたペイロードを HTML ドキュメント内の6 つの特定の場所（例：head_meta、body_top、sidebar、script_comment）のいずれかに挿入します。特定のアンカーが欠落している場合、注入の成功を確保するためにシステムはより粗いアンカーにフォールバックします。
5. エクスフィルトレーショントラッカー: コールバックを記録する軽量な FastAPI サービスです。エージェントが注入された指示に従ってこのトラッカーにデータを送信した場合、テストは成功したエクスフィルトレーションとしてマークされます。

ワークフロー

1. エージェントがホワイトリストに登録されたドメインからの URL を要求します。
2. プロキシは要求をアップストリームサーバーに転送します。
3. 元の HTML レスポンスを受信すると、プロキシは YAML 設定されたフィルタ（攻撃タイプ、ソースベンチマーク、深刻度）に基づいてペイロードを選択します。
4. ペイロードはラップされ、設定された挿入ポイントで HTML に注入されます。
5. 修正された HTML がエージェントに返されます。
6. エージェントが注入された指示を実行してエクスフィルトレーショントラッカーに連絡した場合、イベントがログに記録されます。

主要な貢献

• ホワイトリスト尊重型レッドチーム化: IPI-proxy は、信頼されたドメインからのライブレスポンスを改変してモックページを提供するのではなく、特定のホワイトリストに制限されたエージェントに対する IPI テストを可能にする最初のツールです。
• 統一ペイロードソース: 6 つの異なる研究ベンチマークからの 820 個の攻撃ベクトルを集約・重複排除し、単一のテストセッション内でのベンチマーク間評価とローテーションを可能にします。
• パラメータスイープ評価: ペイロード、埋め込み技術、HTML 挿入ポイントを分離することで、多次元の攻撃表面にわたるエージェントの脆弱性の体系的な評価を可能にします。
• エージェント非依存設計: ブラウザ拡張機能ベースのツールとは異なり、IPI-proxy はネットワーク層で動作するため、ヘッドレスフェッチャ、カスタム HTTP クライアント、Model Context Protocol（MCP）ツールとの互換性があります。

結果と評価

本論文は、IPI-proxy を防御メカニズムではなくテスト基盤として提示しています。特定のモデルに対する具体的な成功率（例：「モデル X は 80% の失敗」）を報告するのではなく、テスト手法の実現可能性と再現性を実証しています。

• このツールは、アップストリームサーバーを変更することなく、ホワイトリストに登録されたドメインからの HTTP レスポンスを正常に傍受・書き換えます。
• 既存のベンチマークでは同時にサポートされていないペイロード、埋め込み、挿入ポイントの組み合わせを網羅する「パラメータスイープ」評価体制をサポートします。
• エクスフィルトレーショントラッカーは、エージェント自体の計器化を必要とせず、テスト環境の完全性を保ちながら、成功した攻撃のグランドトゥルース信号を提供します。

重要性

著者は、IPI-proxy を AI セキュリティテストにおける必要な進化として位置づけています。静的なモックページベンチマークから、動的なライブレスポンス傍受へと移行することで、このツールはセキュリティチームに以下を可能にします：

1. 生産環境で直面する同じエGRESS制限とコンテンツソースの下での Web ブラウジングエージェントの脆弱性を測定する。
2. 現実的な IPI ベクトルに対する防御戦略（入力変換やアーキテクチャ的隔離など）をテストするための再現可能な環境を提供することで、エージェントを強化する。
3. 学術的なベンチマークと企業展開の間のギャップを埋め、レッドチーム化の取り組みが IPI が発生する実際の脅威表面を反映していることを保証する。

本論文は、IPI-proxy 自体が IPI 問題を解決するものではないものの、エージェントが機密性の高い企業環境に展開される前に、リスクを正確に評価し軽減するために必要な重要なインフラを提供すると結論づけています。