BrowseSafe++：実世界のプロンプトインジェクションに対するより強固な防御の構築

CometやComputerに組み込まれたアシスタントのように、Webを閲覧できるエージェントは、Webページとやり取りし、コンテンツを読み取って、それをもとにユーザーに代わってアクションを実行する必要があります。そのため、攻撃者がWebページに悪意のあるテキストを仕込む間接プロンプトインジェクションの影響を受けやすくなります。エージェントがこうした指示に従うと、誤解を招く回答を返したり、ユーザーが求めていないアクションを実行したりする可能性があります。

2025年12月、私たちはこの脅威に対するベンチマークおよび検出モデルであるBrowseSafeをリリースしました。これは、エージェントが遭遇する可能性の高い現実的なWebページに合成攻撃を加えることで構築したものです。この1年で攻撃はより巧妙になり、通常のページコンテンツと見分けにくいものへと進化しています。「以前の指示を無視せよ」のような見え透いたフレーズを使う代わりに、サイトからの公式なお知らせやユーザー設定に関するメモなど、エージェントが信頼しやすいコンテンツを模倣することが多くなっています。

こうした変化を受けて、現在のインジェクション検出器がこれらの攻撃を捉えられるか、そしてエージェントがそれらに抵抗できるかを測定するため、更新版のベンチマークBrowseSafe++を構築しました。このベンチマークには、主に実環境で収集されたインジェクションをもとに構築された、攻撃ありとクリーンのページペアが38,675組含まれています。各ページについて、プライバシー保護のために周囲のコンテンツを書き換えていますが、攻撃部分はそのまま保持しています。すべてのページは、ブラウザエージェントが読み取る4つの形式（HTML、Markdown、アクセシビリティツリー、スクリーンショット）で提供されます。ベンチマークの一部を使用して、テキスト検出器とマルチモーダル検出器からなる0.8Bパラメータの検出器ペア、BrowseSafe-Guardをトレーニングしました。2つのGuard検出器は、フロンティアモデルを含め、テストしたプロンプトベースのモデルよりも正確にインジェクションを識別します。また、より高速かつ低コストで、通常のページを誤ってフラグ付けする頻度もはるかに低くなっています。

BrowseSafe++をオープンなベンチマークとして公開します。プロジェクトWebサイトでは、データセット、SDK、研究論文、公開リーダーボードへのリンクを掲載しています。どのチームも、ラベルが提供されていないテストページに対して自分たちの検出器でスコアを算出し、そのラベルを提出して採点を受けることができます。結果はリーダーボードに掲載される場合もあります。結果を評価して提出するには、利用方法をご覧ください。

観測されたインジェクションからのベンチマーク構築

BrowseSafe++は、実際のWebサイトで観測されたプロンプトインジェクションから構築されています。2025年9月から2026年9月までの間に、Cometのプロンプトインジェクション検出器は、Cometのエージェントが読み取ったページで115万件のインジェクションにフラグを立てました。それらのインジェクションをもとに32,187組のペアを構築し、元のBrowseSafeベンチマークから6,488組を追加して、合計38,675組としました。各ペアには、攻撃ページと、そのクリーンな対（インジェクションを除いた同じページ）の両方が含まれています。

実環境におけるインジェクションの実態

ベンチマークから2つの例を挙げ、こうしたインジェクションが実際にどのようなものかを示します。

1つ目の例では、偽の購入リクエストがエージェントに無許可の操作を行うよう促しています。2025年10月、Cometの検出器は、ロシア語の開発者向けドキュメントページ上にあるこの英語のテキストブロックにフラグを立てました。

このテキストは冒頭と末尾に命令を置き、その間をありふれたトークンの宣伝文句で埋めています。エージェント自身の開発元からのものだと称し、購入が承認済みであるかのように見せるため、最後に承認コードを添えています。

もう1つの例では、偽造された会話によってエージェントのタスクを妨害しようとしています。このテキストは2026年3月にコードリポジトリのページで見つかりました：

このテキストは、ユーザーとエージェントの会話のように見えるよう作られています。<|im_start|>と<|im_end|>は、一部のチャットモデルが会話のターンを区切るために使用するマーカーです。この攻撃に引っかかったエージェントは、偽造されたユーザーのクエリに応答し、攻撃者が指定したフレーズで返信してしまいます。

フラグが立てられたインジェクション全体で、同様のパターンが見られます：

• 信頼できる情報源を装う。どちらの例も、ページのテキストをエージェントが信頼する情報源からのものであるかのように見せかけています。1つ目の例では開発元、2つ目の例ではエージェント自身の会話です。インジェクションは、セキュリティチェックやポリシーの通知を模倣してサイトそのものを装ったり、偽の設定を提示してユーザーを装ったりすることもあります。約3分の2はフォーマルな言葉遣いで書かれています。
• 多くは異なる言語で書かれています。ペアの24.4%では、インジェクションがページの他の部分とは異なる言語で書かれています。典型的なのは、最初の例のように、英語以外のページに英語の指示が含まれているケースです。こうした攻撃は明らかに、あらゆる言語を読み取り、通常は英語を母語とするエージェントに向けられたものです。言語の切り替えは検出も難しくします。当初のBrowseSafe評価でも、多言語攻撃は最も検出が難しいものの1つでした。
• 大半は言葉ではなく行動を求めています。10件中4件以上は、最初の例のトークン購入のように、ユーザーが求めていないアクションへとエージェントを誘導し、約3分の1は、2番目の例のように、エージェントにユーザーのタスクを放棄させようとします。回答に虚偽の情報を仕込もうとするものは約3%にすぎません。
• 誰でも投稿できるコンテンツに便乗することが多い。攻撃者がサイトを管理している必要はありません。一般的なサイト上のフォーラム投稿や共有ドキュメントだけで十分であり、BrowseSafe++のインジェクションのうち23,000件以上がこの経路で入り込んでいました。信頼できるドメインであっても、攻撃者のテキストの注入に利用される可能性があります。

最終的なベンチマークに含まれるインジェクションは、12種類のWebサイト、24種類の攻撃タイプ、6つの攻撃目的、ページ上の18の配置箇所にわたります。

拡大

フラグが立てられたページからベンチマークのペアへ

フラグが立てられたページには、エージェントが代行していたユーザーの個人情報が含まれている可能性があるため、そのままベンチマークに使用することはできません。ページを共有可能なベンチマークペアにするには、主に次の3つの段階が必要です：

1. インジェクションの収集：フラグが立てられたページを収集して重複を除去し、PII-Tracerで個人情報をマスクします。次に、ページにインジェクションが含まれていることを確認します。具体的には、ユーザーが意図したタスクからエージェントを逸らそうとする指示が含まれていることについて、複数のモデルからなるパネルの合意を必須としています。
2. ペアの構築：エージェントが各ページからインジェクションのテキストを削除し、周囲のページコンテンツを書き換えて、名前やブランドなどの詳細を架空のものに置き換えます。2つ目のエージェントが、書き換えたページに実世界のコンテンツが残っていないかを確認し、不合格のものはフィードバックとともに差し戻します。人間のレビュアーがランダムに抽出した10%のページを検査し、見つかった問題はパイプラインで修正され、その修正はコーパス全体に適用されます。インジェクションは書き換えたページに再挿入されて攻撃版となり、クリーン版には含めません。2つのページは、同じタスク、期待される結果、通常の指示を共有しています。
3. 検証：エージェントはさまざまな形式でページを読み取るため、各ページのHTMLをMarkdown、アクセシビリティツリー（ページのインターフェース要素とそのラベルを構造化したリスト）、スクリーンショットとしてレンダリングします。別のエージェントが、攻撃ページの4つのビューすべてにインジェクションが現れていること、そしてクリーンなページがすべてのビューで無害と判定されることを確認します。いずれかのビューでインジェクションが欠落している場合は、ページ上の別の位置に移動して再度レンダリングし、最終的な攻撃ページのすべてのビューにインジェクションが含まれるようにします。最後に一連の自動チェックを行い、実在のホスト名やブランド名など、元のページの痕跡が残っているペアを修正します。

拡大

BrowseSafe-Guard：あらゆるビューに対応する高速かつ高精度な検出器

有用な検出器は、すべてのページを迅速かつ低コストでチェックする必要があります。また、攻撃ページとクリーンなページの両方で正確である必要があります。ほとんどのページは安全であるため、高い適合率が特に重要です。偽陽性率が比較的低くても、アラートの大半が誤警報になってしまうからです。プロンプトベースの汎用モデルは適合率が不十分なことが多く、すべてのページで実行するには遅すぎ、コストもかかりすぎます。

攻撃を受けたページとクリーンなページを別々に収集して学習させた検出器は、ページのトピックやレイアウトなど、たまたま2つのセットを区別できてしまうショートカットを学習する可能性があります。しかし、そのような検出器はうまく汎化しません。そこでGuardは、インジェクションの有無だけが異なるペアで学習し、検出器の適合率を高めています。各ペアについて、Guardは攻撃を受けたページとそのクリーンな対応ページを別々に読み取り、それぞれにインジェクションを含む可能性を示すスコアを付けます。モデルの更新には2つの学習目的関数を使用します。標準的な分類の目的関数と、攻撃を受けたページのスコアが対応ページより一定のマージン以上高くならない限りGuardにペナルティを課すランキングの目的関数です。直感的に言えば、分類の目的関数はGuardにどのような判断を下すべきかを教え、ランキングの目的関数はその判断をインジェクションそのものに結び付け、無害な紛らわしい要素を無視させます。これにより、Guardは周囲のページコンテンツではなく、インジェクションそのものに反応するよう学習します。

Guardは2つの検出器で構成されており、いずれもQwen3.5-0.8Bをファインチューニングしたものです。テキスト検出器は、ページのテキストビュー（HTML、Markdown、アクセシビリティツリーのいずれか）を1つ読み取ります。マルチモーダル検出器は、ページ全体のスクリーンショットを読み取ります。実運用では、Guardは1回のフォワードパスでページを読み取ってインジェクションスコアを出力し、スコアがしきい値を超えるとそのページにフラグが立てられます。Guardのパラメータ数はわずか0.8Bで、出力も単一のスコアだけなので、すべてのページで実行できるほど高速かつ低コストです。

パフォーマンスのベンチマーク評価

ベンチマークのホールドアウトサブセットで、インジェクションを検出するようプロンプトを与えた18のモデルとGuardを比較しました。BrowseSafe++で測定した次の4つの指標を報告します：

• 再現率（Recall）は、インジェクションを含むページのうち検出器がフラグを立てたページの割合で、どれだけ多くの攻撃を捉えられるかを測る指標です。高いほど優れています。
• 偽陽性率（FPR）は、クリーンなページのうち検出器が誤ってフラグを立てたページの割合で、どれだけ頻繁に誤警報を出すかを測る指標です。低いほど優れています。
• 適合率（Precision）は、フラグが立てられたページのうち実際にインジェクションを含むページの割合で、アラートがどれだけ正しいかを測る指標です。高いほど優れています。
• F1は再現率と適合率の調和平均です。検出器が攻撃の大部分を捉え、かつフラグのうち誤警報がわずかである場合にのみ高くなります。

優れた検出器は適合率と再現率の両方が高くあるべきなので、主要な指標としてF1を使用します。4つの指標はすべて、3つのテキストビューの平均値です。

拡大

拡大

モデルの比較

テストした小規模なオープンウェイトモデルは最下位にとどまりました。Mistral NeMoとQwen3 30B-A3Bはいずれもクリーンなページの約半数にフラグを立て、一方Llama 3.1 8Bはほとんど何にもフラグを立てず、攻撃の大半を見逃しています。このグループで最も強力なモデルであるGPT-OSS 20BでさえF1は70.97%にとどまります。はるかに大規模なオープンウェイトモデルであるDeepSeek V3.1は、F1が75.23%とわずかに良い結果でした。

GPT-5.4 nano、Gemini 3.1 Flash-Lite、Claude Haiku 4.5などの軽量APIモデルは、85%～97%の再現率で、より多くの攻撃を検出します。しかし、その代償として誤検知の割合が高くなります。このグループで最もFPRが低いGemini 3.1 Flash-Liteでも35.2%で、HaikuのFPRは69%近くに達します。その結果、このグループの最大F1スコアは、Gemini 3.1 Flash-Liteによる80.9%にとどまります。

残りのモデルはより強力な汎用モデルで、F1スコアは85%から92%に達します。しかし、依然として再現率とFPRのトレードオフに直面しています。慎重寄りのモデルは正当なページをブロックし、フラグを立てる頻度が低いモデルは攻撃を見逃します。Claude Sonnet 5は全検出器の中で最も高い98.73%の再現率を示しますが、FPRは24.65%です。Gemini 3.1 ProとGPT-5.5の再現率はそれぞれ97.78%と97.19%、FPRはそれぞれ19.80%と20.44%です。GPT-6 Astraは全体の精度が最も高く、再現率は96.42%、FPRは14.41%です。Deciderがそれに続き、再現率は96.02%、FPRは17.44%です。Claude Opus 5.5はFPRが最も低くわずか4.21%ですが、再現率が77.71%であるため、攻撃の5件に1件以上を見逃しています。Claude Fable 5.1は回答したページでは再現率89.31%、FPR 7.92%と高い性能を示していますが、約30%のページで回答を拒否しており、「(all)」の行ではそれらをフラグとしてカウントしています。

拡大

Guardはパレートフロンティアを押し広げ、攻撃の見逃しと誤警報の間でより優れたトレードオフを実現しています。F1は約95%に達し、すべてのテキストビューで1位です。クリーンなページにフラグを立てるのは約20ページに1ページのみで、プロンプトベースのモデルの中で最も精度の高いAstraの約3分の1の割合です。この差は私たちのトレーニングによるものです。Guardのベースとなっている素のQwen3.5-0.8Bは、他のモデルと同じ方法でプロンプトを与えた場合、F1は64%にとどまり、クリーンなページの4分の3近くにフラグを立ててしまいます。スクリーンショットビューのシナリオでは、Guardのマルチモーダル検出器を、画像に対応した4つのモデルと比較しました。フルページのスクリーンショットを与えた場合、GuardのF1は約93%で、評価した他のモデルの中で最も優れたものは約79%でした。

攻撃を認識することと、攻撃に抵抗することは同じではない

直感的には、インジェクションを正しく識別できるモデルであれば、ユーザーのタスクを遂行する中でそのページに遭遇した際にも、そのインジェクションを無視できるはずです。しかし、私たちの実験では、高い検出スコアがモデルの攻撃への耐性を保証するものではないことが示されました。各モデルに同じ攻撃ページを2回与え、1回目はインジェクションが含まれているかを判定させ、2回目は前回の判定を見せずにユーザーのタスクを実行させました。インジェクションに従ったかどうかは、別の判定モデルが確認しました。テストしたすべてのモデルが、自らフラグを立てたインジェクションの一部に依然として従っており、その割合はフラグを立てたページのうちGPT-6 Astraの1.64%からLlama 3.1 8Bの24.73%まで幅がありました。

拡大

検出スコアは、モデル間の差を確実に予測するものではありません。Claude Sonnet 5とGPT-5.5のインジェクション検出能力はほぼ同等で、F1スコアはそれぞれ約88%と約89%です。しかし、Sonnet 5は自らフラグを立てたインジェクションに19.74%のページで従っており、これはGPT-5.5の1.97%の10倍に相当します。

インジェクション防御のためのデプロイ可能なシステム

これらの結果は、ページをブロックするかどうかの判断を、ユーザーのタスクを遂行するモデルに頼るのではなく、専用モデルに委ねることに価値があることを示唆しています。エージェントが行動する前に各ページをスクリーニングする独立した検出器は、防御層を一段追加するものであり、乗っ取られるタスクも悪用されるツールも持ちません。

Guardは、まさにそのような検出器として設計されています。テストしたすべてのモデルの中で最も高いF1スコアと正解率を達成しているだけでなく、サイズが小さいため、すべてのページで実行できるほど低コストです。Guardが使用したGPU時間は、テキストページ1件あたり平均約0.15秒でした。レンタルのH200では、コストは1,000ページあたり0.18ドルと見積もられます。一方、フロンティアAPIモデルは定価で18.95～180.61ドルかかります。このように今回の比較では、高い検出スコアを維持しながら、頻繁なスクリーニングを大幅に低いコストで実行できます。

下の図は、各検出器の精度を、1ページあたりの処理時間と1,000ページあたりのコストに対してプロットしたものです（いずれも対数スケール）。Guardは両パネルの左上隅に単独で位置しており、精度、速度、コストのすべてで優れています。プロンプトベースのモデルはいずれも1ページあたり約1秒以上かかり、最も精度の高い2つのモデルであるGPT-6 AstraとClaude Fable 5.1は、1,000ページあたり100ドルを超えるコストがかかります。

拡大

適応型攻撃に対する防御のテスト

BrowseSafe++ベンチマークに含まれるインジェクションは有限です。しかし、実際の攻撃者は適応型攻撃を仕掛けることができます。インジェクションが失敗すれば、攻撃者はそれを書き換えて再試行できるのです。その結果、元のインジェクションに抵抗できたエージェントでも、将来の攻撃に対しては依然として脆弱である可能性があります。さらに、モデルはインターネットから収集されたデータでトレーニングされるため、ベンチマークのインジェクションの大半に抵抗することを学習してしまうかもしれません。ベンチマークを一般公開する以上、いずれ飽和し、モデルを適切に区別できなくなる可能性が高いでしょう。これら両方の問題に対処するため、攻撃モデルがインジェクションを書き換えられるテスト環境、BrowseSafe-Adaptを構築しました。各テストは次の3つの段階で構成されます：

1. ケースを設定する。ケースは、BrowseSafe++のエントリとターゲットエージェントを組み合わせたものです。BrowseSafe++のエントリには、ユーザーのクエリとタスクを含むシナリオ、攻撃を受けたページ、攻撃者が意図する結果が含まれます。エージェントは、タスクの実行に必要なツールと合成データを提供するサンドボックス内で動作します。攻撃が目的を達成したかどうかは、別の検証モデルが評価します。
2. 試行の実行：現在のインジェクションをページに挿入し、エージェントにタスクを実行させます。検証器がエージェントの回答とサンドボックスに加えられた変更を確認し、攻撃が成功したかどうかを判定します。初回の試行では、元のBrowseSafe++エントリのインジェクションを使用します。
3. 修正と反復：攻撃が失敗した場合、その試行をアーカイブし、批評モデルが何がうまくいかなかったかをレビューします。攻撃モデルはそのフィードバックをもとにインジェクションを書き換えます。その際、攻撃の文言、書式、ページ上の位置を変更できます。攻撃の目的、成功基準、周囲のページコンテンツは変わりません。次の試行では更新された攻撃を使用します。このプロセスは、攻撃が成功するか、攻撃者があらかじめ設定された試行回数の上限に達するまで繰り返されます。

拡大

それぞれ異なるモデルを基盤とする7つのエージェントをテストしました：Claude Sonnet 5、Claude Haiku 4.5、GPT-5.5、Gemini 3.1 Pro、Gemini 3.5 Flash-Lite、そしてオープンウェイトモデルのDeepSeek V3.1とKimi K2です。各エージェントは同じ1,024件のタスクに取り組み、タスクごとに最大64回の試行が行われました。初回の試行では、7つのエージェントすべてで攻撃成功率は低いものでした。元のインジェクションが成功したのは、どのエージェントに対しても評価対象タスクの最大4%でした。適応型フレームワークのもとでは、攻撃成功率は劇的に上昇しました。7つのエージェントのうち5つに対して、攻撃者はタスクの79%以上で成功しました。最も堅牢なエージェントでさえ脆弱でした。GPT-5.5に対してはタスクの約3分の2、Claude Sonnet 5に対しては約3分の1で、依然として攻撃が成功しました。

エージェント間の差が最も大きくなるのは、攻撃者の目的がエージェントに特定のツール呼び出しを実行させることである場合です。この種の目的を持つタスクでは、Sonnet 5が攻撃に屈したのはタスクの約8%、GPT-5.5は約29%でした。残りの5つのエージェントは、タスクの半数以上で攻撃者の目的を実行してしまいました。

また、Guardで各ページを事前にスクリーニングした状態で、Gemini 3.5 Flash-Liteエージェントに対してBrowseSafe-Adaptを実行しました。Guardは元のインジェクションの94.5%をブロックし、攻撃者が必要とする平均試行回数を9.7回から17.0回へとほぼ倍増させました。しかし、64回の試行すべてを与えられた場合、攻撃者は依然としてタスクの84.2%で成功しました（Guardなしでは93.6%）。そのほとんどは、Guardがフラグを立てなかったインジェクションによるものでした。これは、BrowseSafeのリリース時に示した見解と一致しています。つまり、万能な検出モデルは存在しないため、検出器は多層防御の一部として組み込む必要があるということです。

拡大

結論

ブラウザエージェントは、間接プロンプトインジェクションの影響を受けやすいことがよくあります。これは、通常のページに隠された攻撃が、ユーザーのタスクを遂行するエージェントの能力を妨げようとするものです。エージェントがより多くのデータやツールにアクセスできるようになることで攻撃の潜在的な影響が大きくなり、また攻撃者がインジェクションを修正してより効果的にできるため、危険性は時間とともに増す一方です。

BrowseSafeスイートは、こうした脅威に対処します。BrowseSafe++ベンチマークには、主に実際のインジェクションから構築された38,675組のWebページペアが含まれており、検出器のより信頼性の高いトレーニングと評価を可能にします。これらのペアでトレーニングされたBrowseSafe-Guard検出器は、高精度・高速・低コストな検出を実現し、エージェントがページに基づいて行動する前にスキャンすることを可能にします。BrowseSafe-Adaptフレームワークでは、修正されたインジェクションに対してモデルをテストでき、固定されたインジェクションによる単発の試行では見えにくい脆弱性を浮き彫りにします。

これらのツールが、研究者やエンジニアが失敗を発見し、Webベースのプロンプトインジェクション攻撃に対する防御を改善する一助となることを願っています。また、ユーザーの安全を守るため、CometとComputerに組み込まれた防御機能の評価と改善を継続的に行っています。

利用方法

1. SDKをインストールし、データへのアクセス権を取得します。SDKはGitHubからインストールできます：

データセットはアクセス制限付きです。Hugging Faceページで一度アクセスをリクエストしてから、hf auth loginでログインしてください。

2. リーダーボードに提出します。BrowseSafe++のテストスプリットで独自の検出器を評価します：

これにより、指定した各ビューについてページごとに1つの判定が書き出されます。テキストのリーダーボードで平均値を得るには、3つのテキストビューをすべて指定してください。Hugging FaceアカウントでリーダーボードのSpaceにサインインし、predictions.jsonlをアップロードします。Spaceは、ビューごとにF1、正解率、偽陽性率などの指標を返し、希望すれば結果をリーダーボードに公開します。各アカウント（作成から60日以上経過しているもの）は、UTC基準で1週間につき1回、スコア付きの提出を行えます。テストページは評価専用です。学習に使用したり、再配布したりしないでください。ファイル形式と公開ルールについては、提出ガイドをご覧ください。

引用

@online{perplexity2026BrowseSafePlusPlus,
  author = {{Perplexity} and Yuetian Chen and Kaiyuan Zhang and Yuntao Du and Thomas Li and Mark Tenenholtz and Kyle Polley and Jerry Ma and Denis Yarats and Ninghui Li and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{BrowseSafe++: Building stronger defenses against real-world prompt injection}},
  date = {2026-10-28},
  url = {https://www.perplexity.ai/hub/blog/browsesafe-plus-plus}
}