Perplexityはこのほど、AI搭載ブラウザーをプロンプトインジェクション攻撃から守るためのオープンソースモデル、BrowseSafeをリリースした。
しかし、Lassoの研究者が実施したレッドチームテストによると、このガードレールは宣伝されているほど包括的ではない可能性がある。
「高度な手法ではなく標準的な手法を使い、数時間で36％の回避率を達成した。より多くの時間をかける意欲的な攻撃者なら、さらに高い成果を上げるだろう」と、Lassoのプロダクトリサーチ責任者、Eliran Suisa氏は述べた。
自律型ウェブエージェントのセキュリティリスク
BrowseSafeはすでにPerplexity独自のAIブラウザー、Cometに組み込まれており、ライブウェブコンテンツを読み取り、操作する自律型エージェントを保護することを目的としている。
その検知前提が崩れれば、主要な防御策として依存する組織は、下流のモデルを悪意ある指示にさらす可能性がある。データ漏えい、ポリシー違反、安全でない操作につながりかねない。
研究者らは、現実的なHTMLブラウジング環境でプロンプトインジェクション攻撃を検知するBrowseSafeの能力を評価した。
テストでは、Perplexityのメッセージが示唆するように、このモデルが単独のセキュリティ制御として機能できるかどうかに焦点を当てた。
研究者らは手作業でプロンプトを作成するのではなく、自動化したレッドチームテストを用いて、エンコードや難読化の手法を体系的に適用した。これらは、人手によるテストだけでは見つけにくいものだ。
攻撃に対するBrowseSafeのテスト
BrowseSafeは、Qwen3-30Bをベースにしたバイナリー分類器として実装されており、コンテンツがエージェントの中核ロジックに到達する前に、単純な安全または悪意ありの判定を出力する。
モデルカードによると、このシステムは、ブラウジング中に遭遇する乱雑なHTMLや注意をそらす要素、一般的なインジェクションパターンに対して堅牢に動作するよう設計されている。
この設計は、単純な攻撃には有効だ。しかし、通常の言語による指示ではなく、エンコードに依存するプロンプトインジェクション手法に対しては、モデルは苦戦した。
テストでは、Base32、NATOフォネティック・アルファベット、Pig Latinを使ってエンコードされた悪意あるプロンプトをBrowseSafeは検知できなかった。実際のウェブページに近いHTML構造にペイロードを埋め込んだ場合も同様だった。
これに対し、16進数でエンコードされた攻撃は一貫して検知された。このことから、こうしたパターンはモデルの学習データにより多く含まれていたと考えられる。
全体として、悪意あるプロンプトのおよそ36％が誤って安全と分類された。
エンコードされた攻撃がすり抜ける仕組み
根本的な問題は、実装固有のものではなくアーキテクチャにある。BrowseSafeは、デコードせずに入力テキストをそのまま分類する。
エンコード技術は、意図を保ったまま悪意ある指示の表面的な見た目を変える。
下流の大規模言語モデルや人間は、ガードレールが入力を承認した後でも、こうした変換を容易にデコードできる。
これにより危険な隔たりが生じる。セキュリティモデルは未デコードのテキストを評価する一方、対象モデルはデコードされた意図を解釈する。
ガードレールがエンコードされたペイロードを承認すれば、その後のエージェントが攻撃者の指示を実行するのを本質的に防ぐものは何もない。
BrowseSafeを主要、あるいは唯一のガードレールとして使う環境では、これは単一障害点となる。プロンプトが安全と分類された後、悪意ある動作を検知したり阻止したりする下流の制御が存在しない可能性がある。
この失敗は、判断の難しい例外的ケースではなかった。
多くのケースで、BrowseSafeは明らかに悪意あるコンテンツを高い確信度で安全と分類した。これは、確信度スコアだけでは防御の信頼できる指標にならないことを示している。
エージェントセキュリティのための多層制御
現実世界のプロンプトインジェクション攻撃、特にエンコードや難読化の手法を悪用する攻撃から守るには、単一のモデルベースのガードレールに依存するだけでは不十分だ。
効果的な緩和には、プロンプトがエージェントの中核ロジックに到達する前後の両方で起こる失敗を考慮した、多層防御のアプローチが必要になる。
組織は、一部の攻撃が初期スクリーニングをすり抜けることを前提とし、影響を抑え、悪用を検知し、時間の経過とともに適応できる制御を設計すべきだ。
- レッドチームテストを実施して導入前にエージェントのパイプライン全体を意味ベース、エンコード、難読化によるプロンプトインジェクション手法まで網羅した自動テストで検証する。
- 分類前に入力を正規化してデコードし、難読化を利用した回避を減らし、ガードレールが真の意図を評価できるようにする。
- 単一モデルではなく、多層型およびアンサンブル型のガードレールを使い、意味的、構造的、行動的な異常を検知する。
- 決定論的なポリシーと最小権限の制御を適用し、プロンプトが初期スクリーニングを通過した場合でも、エージェントやツールにできることを制限する。
- ランタイム監視とアクションレベルの制御を追加して挙動のドリフトを検知し、ツールの利用を検証し、安全でないブラウザー操作をリアルタイムで阻止する。
- ガードレールモデルをコンポーネントとして扱い、継続的なテスト、監視、フィードバックループから得られる情報に基づき、常に更新されるセキュリティアーキテクチャに組み込む。
これらの取り組みを組み合わせることで、ライフサイクル全体を通じて、エージェントの動作を整合的で、レジリエントかつ安全な状態に保ちやすくなる。
リスクはオープンソースではなく、前提にある
BrowseSafeの限界は、AIセキュリティにおけるより広い傾向を反映している。ガードレールが専門化するにつれ、攻撃者は明白な悪意ある言葉ではなく、表現レベルの操作にますます依存するようになっている。
エンコードを利用したプロンプトインジェクションは新しいものではないが、検査時点で脅威が意味的に読み取れることを前提とするシステムに対して、依然として有効だ。
問題はオープンソースではない。BrowseSafeは透明性、再現性、そしてAIブラウザーセキュリティの有用なベースラインを提供する。リスクは、単一のガードレールモデルを、それだけで十分な保護策だと位置付けることにある。
自律型エージェントがツール、データ、ワークフローに対する権限を強めるにつれ、セキュリティチームは一部の攻撃が早期検知をすり抜けることを前提とし、そうした場合でも安全に失敗できるシステムを設計する必要がある。
現代のAIシステムがますます必要とするゼロトラストという考え方――侵害を前提とし、実行のあらゆる段階で影響を限定するもの。