THREAT BRIEFING · AGENTIC BROWSER × PROMPT INJECTION
Brave の脆弱性公表（2025年8月20日）を一次情報とし、Perplexity が製品公開前に委託していた Trail of Bits の監査報告、LayerX が別経路で行った発見、および Perplexity 自身の防御公表と論文を突き合わせて検証した解説
2025年8月20日、Brave のセキュリティチームが、Perplexity の AI ブラウザ Comet に間接プロンプトインジェクションの脆弱性を公表した。Reddit のコメントに指示を隠しておくと、「このページを要約して」と頼んだだけの利用者から、メールアドレスとワンタイムパスワードが攻撃者の手に渡る——という実証だった。
報じられた形は「AI ブラウザに脆弱性が見つかった」である。だが出典を時系列に並べ直すと、話の形が変わる。
Perplexity は Comet を公開する前に、Trail of Bits に監査を委託していた。2025年4月のその監査は、「利用者が攻撃者の管理するページの要約を依頼したときに、Gmail のメールを攻撃者のサーバへ持ち出す」攻撃を4通り実証している[3]。トリガーも到達先も、Brave が3か月後に示したものと同型である。そして Perplexity の記録では、それらは公開前に塞がれた。
つまりこの事案の要点は「既知の問題を放置して出荷した」ではない。「クラス単位の対策を打った後に、同じクラスが別の連鎖で再発した」である。非難としては前者より弱く、構造的問題の証拠としては前者より強い。
Brave は本件を、実装の不手際ではなく設計の問題として提示している。「エージェント型 AI に対しては従来の Web セキュリティの前提が成り立たない」とし、続く第2報では「間接プロンプトインジェクションは孤立した問題ではなく、AI ブラウザというカテゴリ全体が直面する系統的な課題である」と述べた[1][2]。
この一般化は、競合ベンダーによる誇張として割り引きにくい。Perplexity が自ら費用を払って雇った監査法人が、独立に同じ結論を書いているからである——「これらの脆弱性は Comet 固有ではない。認証済みセッションとブラウザ操作へのアクセスを持つ AI エージェントは同様の攻撃に直面する」[3]。
カテゴリ全体の問題であることと、実装で回避できないことは別である。Brave 自身が、Fellou ブラウザについて「隠蔽指示攻撃に一定の耐性を示した」と書いている[2]。実装間に差はある。
さらに示唆的なのは Trail of Bits の誤字の挿話である。偽のシステム警告に紛れ込んでいた綴り間違いは PoC 作成時の偶発的なものだったが、それを修正したところ、エージェントは警告を偽物と正しく判定し、攻撃は成立しなくなった。同社は「誤字がエクスプロイトの動作に必要である」と書いている[3]。この挙動は脆く確率的であり、決定論的な構造的必然ではない。
本稿は、この事案を「境界の欠如」と「権限の全面委任」の連言として読む。どちらか一方を断てば成立しない。カテゴリに共通するのはこの2条件を同時に満たしやすい設計上の誘因であって、回避不能性ではない。
独立した起源は3つある——Brave（第1報・第2報は同一著者ペアによる継続調査であり、両者の関係は自己改訂であって相互裏付けではない）、Trail of Bits、LayerX。加えて Perplexity 自身の公表が3件ある。ただし独立性は主張の水準によって異なる。「AI ブラウザが間接プロンプトインジェクションに系統的に脆弱である」は3起源＋ベンダー自認で裏付けられるが、Brave が示した特定の連鎖（末尾ドット・OTP・Reddit 返信）を再現した第三者の記録は、本稿の参照範囲に見当たらない。
また Trail of Bits は「独立した第三者」ではない。Perplexity が費用を払って委託した外部監査である。ただし同社は発注者に不利な内容を公表しており、その点は信頼性を上げる材料になる。
時点に注意が要る。Brave の更新注記は2025年8月時点の記述で、本稿の取得日（2026年8月3日）との差は約1年ある。Perplexity の4層防御は2025年10月時点の公表内容で、その後さらに別の防御が公開されている。本稿は「2026年8月現在 Comet が安全かどうか」を判断できない。
この事案は、7件の出典を公表日ではなく出来事の順に並べ直したときに最もよく見える。Brave の発見は起点ではなく、途中の一点である。
Trail of Bits の記述は明快である。「Comet ブラウザを公開する前に、Perplexity は我々を雇って AI 閲覧機能のセキュリティを試験させた」——監査は2025年4月に実施され、4つの手法（要約指示の悪用、偽のセキュリティ機構、偽のシステム指示、偽の利用者要求）が用いられた[3]。
4つのエクスプロイトはいずれも同じ結果に至った——利用者が攻撃者の管理するページの要約を依頼したときに、Gmail のメールを攻撃者のサーバへ持ち出す、という結果である。
Brave の PoC も、トリガーは「要約の依頼」であり、到達先は利用者がログイン済みの認証済みサービスである。同じクラスの攻撃が、製品公開前に4通り実証され、是正され、そして3か月後に別の連鎖で再び成立した。
Trail of Bits の記事には、Perplexity のセキュリティ責任者 Kyle Polley 氏の署名入りコメントが置かれている。同社の体系的手法は「公開前にこれらの隙を特定し塞ぐ」助けになった、というものである[3]。Perplexity 自身の記事にも独立に同旨の記述がある——「利用者に影響が及ぶ前に緩和策を洗練し、脆弱性を塞いだ」[6]。
したがって「既知の脆弱性を抱えたまま出荷した」という読みは、記録に反する。ただし留保が要る。この2つの記述はいずれも発話者が Perplexity 自身であり（Trail of Bits の記事に載っていても発話者は同社である）、Trail of Bits は修正の完了を独立には断定していない。第三者検証もない。「公開前に塞いだ、というのが記録上の説明である」——本稿はこの水準にとどめる。
Brave の PoC は4段階からなる。注目すべきは、そのうち1段階が「認証の回避」に費やされていることである。
perplexity.ai. のように末尾にドットを付けることで、perplexity.ai とは別のドメインを作り、既存の認証状態を回避して新しく OTP を発行させている。この一手が必要だったという事実は、第4節で見るとおり、この事案の性格そのものを規定している。攻撃の入口は、攻撃者が管理するサイトである必要すらない。Brave は、白背景に白文字、HTML コメント、その他の不可視要素といった手段のほかに、Reddit のコメントや Facebook の投稿といった利用者生成コンテンツに指示を注入する方法を挙げている[1]。同社の表現では、この攻撃は「相互作用の点で間接的、範囲の点でブラウザ全体」である。
Brave は「同一オリジンポリシー（SOP）や CORS といった従来の保護は事実上無力である」と書いた。この表現は結果を正しく伝えるが、機構としては誤解を招きうる。
この点を正確に押さえると、当初立てたくなる読みが1つ崩れる。「最初に破られたのは LLM の判断力ではなく、権限設計である」という整理は魅力的だが、Brave 自身の PoC がそれを否定している。
もし Comet のエージェントが本当に無条件で全認証済みセッションを横断できたのなら、攻撃者は末尾ドットで別ドメインを作って「既存の認証を回避する」必要がなかった。その一手が要ったという事実は、オリジンと認証の境界がこの攻撃のなかでも実効性を保っていたことを示している。
したがって本稿は順序づけを次のように改める。成立の起点はプロンプト構築時の信頼境界の欠如であり、被害の範囲を決めたのが権限設計である。両者は連言であって、どちらか一方だけでは成立しない。
この定式化は Brave 自身のものでもある。第2報で同社は、これらの攻撃が「LLM のプロンプトを構築する際に、信頼された利用者入力と非信頼の Web コンテンツの明確な境界を維持できないこと」と「ブラウザに強力な代行操作を許していること」の両方に帰着すると書いている[2]。Trail of Bits も、5つの提言のうち第2位に「システム指示と外部コンテンツの間に明確な境界を確立せよ」を、第4位に「AI エージェントの能力に最小権限原則を適用せよ」を並置している[3]。同じ2条件に、独立した2つの起源が、3か月の差で到達している。
本サイトが扱った EchoLeak（メール1通で Microsoft 365 Copilot から社内データが漏れたゼロクリック脆弱性）と本件は、同じ間接プロンプトインジェクションでありながら破られた境界が違う。EchoLeak は、AI が読むべきでないデータを読んで漏らした——境界の失敗である。本件は、そこに行動の権限が重なっている。エージェントは読むだけでなく、利用者として別ドメインへ移動し、ログインし、書き込んだ。
また s1ngularity で本サイトは「被害を決めたのは AI ではなく CI の権限設計だった」と書いた。本件でも成り立つのは、より一般的な水準の主張である——被害の範囲を決めるのは、AI の判断力ではなく、その周囲に置かれた設計である。ただし本件では、AI の判断そのものが攻撃の入口になっている点が異なる。
Brave は4つの緩和策を挙げた。Perplexity は2025年10月に4層の防御を公表した。両者は対応しているのか。
| Brave の緩和策[1] | Perplexity の公表内容[5]（2025年10月時点） | 対応 |
|---|---|---|
| ① 指示と内容の分離 利用者の指示とサイトの内容を明確に分けてバックエンドへ送る。ページ内容は常に非信頼として扱う |
第2層：構造化プロンプト 「外部コンテンツをプロンプト内で非信頼として明示的に区切り、利用者の指示と取得データを区別する」 |
対応あり |
| ② 出力の利用者整合性の独立検査 モデルが立てた行動を「潜在的に安全でない」ものとして扱い、利用者の要求との整合性を独立に検査する |
第2層の一部：Intent reinforcement ルーティング系がツール選択・実行時に元の利用者クエリを継続参照する。ツール単位の意図整合ガードレールも記載 |
性質が異なる |
| ③ 機微な操作に利用者確認 事前の計画がどうであれ、機微な作業には明示的な利用者操作を要求する |
第3層：利用者確認 メール／メッセージ送信、カレンダー変更、最終的な購入注文などで、不審な挙動の検出有無にかかわらず一時停止して確認を求める |
対応あり |
| ④ エージェント型閲覧の分離 利用者が普通に閲覧していて「うっかり」エージェント状態に入ることは不可能であるべき。権限は可能な限り最小に |
公表文に該当する記述が見当たらない。4層はいずれも同一モードの中で危険を検出・確認する設計であり、モードを分けるものではない | 記述なし |
1. ②を「対応なし」と書くのは誤りである。Perplexity の第2層には Intent reinforcement という対応物が実在する。正確な指摘は「対応物はあるが、プロンプト内での帯域内の補強であって、Brave が求めた『独立した』出力側の整合性検査とは性質が異なる」——モデルに念を押すことと、モデルの外側で照合することは、別の防御である。
2. ④の「記述なし」は「機能が存在しない」ことの証明ではない。出所となった記事は網羅的な設計文書ではなく、自社の防御を説明する解説記事である。書かれていないことから機能の不在は導けない。
3. これは2025年10月時点の構成である。同年12月に Perplexity は検出モデル BrowseSafe を公開しており、防御の世代交代が起きている可能性が高い。
そしてPerplexity の公表文は、Brave にも本件にも一切言及していない[5][6]。同社の4層防御が Brave の指摘への直接の応答であるとは、出典からは確認できない。開示タイムラインそのもの——7月27日に初期修正を実施した、といった記述——も、すべて Brave 単独の記録である。
Perplexity の防御の中核は、悪性の指示を検出する機械学習分類器である。その限界は、他ならぬ同社が関与する論文が定量的に示している。
2025年11月に投稿され12月に公開された BrowseSafe は、検出モデルと評価ベンチマークである。著者には Perplexity のセキュリティ責任者 Kyle Polley 氏らが名を連ねる[7]。ベンチマークは 14,719 サンプル、11 の攻撃類型、9 の注入手法、3 の言語スタイルからなる。
論文の指摘のうち、防御設計にとって最も重いのは次の一文である——「現在の検出モデルは、構造的に露骨な隠蔽型の攻撃を見つけるのは得意だが、意味的に溶け込んだ可視の攻撃を見分けるのははるかに不得手である」[7]。白文字や display:none のように「隠している」ことが構造に現れる攻撃は捕まえやすい。ふつうの文章として自然に読める指示ほど、検出は難しくなる。
これは Trail of Bits の誤字の挿話とも符合する。偽のシステム警告は、誤字があるうちは通り、正しい日本語ならぬ正しい英語に直すと見破られた[3]。判定は内容の意味ではなく、表層の手がかりに強く依存している。
公平を期すために付け加えると、これは自社に不利な数値をベンダー自身が公開したものである。その点は同社の開示姿勢として評価されるべきで、本稿が分類器の限界を書けるのも同社の公開があってのことである。
この事案について、出典が述べていないことは多い。そして「述べていない」ことと「無かった」ことは違う。
Brave の第1報・第2報、LayerX の報告、いずれも PoC の記述に終始しており、実際の被害者、悪用の観測、影響を受けた利用者数のいずれにも言及していない。「被害は無かった」と書かれているのではなく、言及自体が無い。本稿は被害の有無について何も述べられない。
Trail of Bits と LayerX はいずれも別の機構を報告している——前者は偽のシステム指示や偽の CAPTCHA、後者は URL クエリ文字列経由である。末尾ドット・OTP・Reddit 返信という Brave の特定の連鎖そのものを、独立に再現した記録は本稿の参照範囲に存在しない。これは不在を根拠にした記述であり、探し漏れの可能性は排除できない。
したがって確信度を分ける必要がある。「AI ブラウザが間接プロンプトインジェクションに系統的に脆弱である」は3つの独立起源とベンダー自身の認識で裏付けられる。「Brave の PoC がこのとおりに動いた」は、Brave 単独の記録である。
2025年8月13日の最終テストは「パッチされたようにみえる」というヘッジ表現であり、断定ではない。8月20日の更新注記が否定しているのは「ここで説明した種類の攻撃」——個別の脆弱性ではなく攻撃の類型である。そしてこの注記自体に日付がなく、その後の帰趨は一次情報に記されていない。
2025年4月の監査指摘についても同様で、「公開前に塞いだ」はすべて Perplexity 自身の発言である。Trail of Bits は修正の完了を独立には断定していない。
本稿が参照した7件のいずれにも識別子の記載はなく、別途の検索でも確認できなかった。1年以上にわたって複数の研究者が同一クラスの問題を報告し続けているにもかかわらず、共通の参照番号が存在しない。製品がベンダー側でホストされるサービスと一体で、利用者側の適用作業を伴わないことがひとつの説明になりうるが、これは本稿の推測であって出典の説明ではない。
Brave が調べた対象は同社が選んだ製品に限られる。母数、選定基準、攻撃が成立しなかった実装の件数は、いずれも公表されていない。比較対象に挙がった Nanobrowser について脆弱性の報告はなく、Brave 自身の Leo はどの検証対象にも含まれていない。
ただし前述のとおり、これを「競合による誇張」と片付けることはできない。Perplexity が発注した監査法人が、独立に「これらの脆弱性は Comet 固有ではない」と書いている[3]。
Perplexity は LayerX の指摘を「セキュリティ上の影響を特定できない」として Not Applicable と分類した[4]。また同社は自社の記事で、Comet の防御に関する知見が「扇情的あるいは不完全なセキュリティ主張によって歪められない」ようにしたいと書いている[6]。
これを「情報を隠している」と読むのは証拠と整合しない。同社は同時期に、自社の検出モデルの取りこぼし率を自ら定量公表している。開示の欠落ではなく、脆弱性の重大性評価をめぐって、ベンダー側と研究者側の判断が食い違っているという事実にとどめるのが正確である。本稿はどちらの立場も地の文にしない。
この事案で最も実務的な含意はここにある。Perplexity は公開前に外部監査を入れ、4つの手法を実証され、記録上は塞いだ。それでも3か月後に、同じクラスの攻撃が別の連鎖で成立した。個別の攻撃経路を潰すことと、その経路を成立させている条件を取り除くことは別である。「報告された PoC が動かなくなったこと」を修正の完了と読むと、この差を見落とす。Brave の8月13日の記録が「パッチされたようにみえる」という慎重な表現だったことは、示唆的である。
分類器は「この内容は悪性か」を判定する。だがベンダー自身の測定によれば、その判定は攻撃の約16%を取り逃がし、意味的に自然な文章に溶け込んだ指示ほど苦手である。一方、境界設計が問うのは「この内容に指示の資格があるか」であり、攻撃の巧拙に依存しない。前者だけに依存する設計は、攻撃分布を永久に追いかけ続けることになる。両方が要る。
Brave の4つの提言のうち、Perplexity の公表文に対応が見当たらなかったのはエージェント型閲覧と通常閲覧の分離だけだった。そして同社が投げかけた問いは、そのまま導入判断の問いになる——「Reddit の議論を要約したいだけなのに、ブラウザは本当にメールアカウントを開き、メールを送り、ログイン済みの全サイトから機微データを読む能力を必要とするのか」[1]。
組織で AI ブラウザの導入を検討する場合、評価すべきはモデルの賢さではなく、「要約」のような日常的な操作に、どこまでの権限が結び付いているかである。
この攻撃が価値を持ったのは、利用者が Perplexity と Gmail に既にログインしていたからである。エージェント型ブラウジングを、業務の認証済みセッションを持つプロファイルと同じ場所で動かすかどうかは、製品側の設計を待たずに利用側で決められる。プロファイルの分離は、ベンダーの修正状況に依存しない数少ない打ち手である。
本稿が時系列を組み直せたのは、Trail of Bits が発注者に不利な内容を公表し、Perplexity がそれを自社ブログから参照し、さらに自社モデルの取りこぼし率まで公開したからである。同社の脆弱性 triage の判断には研究者側との食い違いがあり、公表文の自己評価には割り引いて読むべき箇所もある。それでも、この分野で検証可能な記述が積み上がっているのは、こうした開示があってのことである。調達の場で問うべきは「脆弱性が報告されたことがあるか」ではなく、「外部監査の結果を、不利なものも含めて公表しているか」である。