BrowseSafeをレッドチーミングすると、AIブラウザのガードレールのギャップが露呈

Perplexityは最近、プロンプトインジェクション攻撃からAI搭載ブラウザを保護するために開発者を支援することを目的としたオープンソースモデル「BrowseSafe」を公開しました。 

しかし、Lassoの研究者によるレッドチームテストでは、このガードレールは宣伝されているほど包括的ではない可能性が示唆されています。 

「標準的な手法を使い、しかも高度な方法ではなく、数時間で36%のバイパス率を達成しました。より時間をかけられる意欲的な攻撃者なら、さらにうまくやるでしょう」と、Lassoのプロダクトリサーチ責任者であるEliran Suisa氏は述べています。

自律型Webエージェントにおけるセキュリティリスク

BrowseSafeはすでにPerplexity自身のAIブラウザ「Comet」内で使用されており、ライブのWebコンテンツを読み取り、そこで行動する自律型エージェントを保護することを意図しています。 

その検知の前提が崩れると、主要な防御としてこれに依存する組織は、下流のモデルを悪意ある指示にさらしてしまい、データ漏えい、ポリシー違反、または危険な行動につながる可能性があります。

研究者らは、現実的なHTMLブラウジングの文脈において、BrowseSafeがプロンプトインジェクション攻撃を検知できるかを評価しました。 

テストは、Perplexityのメッセージングが示唆するように、このモデルが単独のセキュリティ制御として機能し得るかどうかに焦点を当てました。  

手作業でのプロンプト作成に頼るのではなく、研究者らは自動化されたレッドチーミングを用い、人間のテストだけでは表面化しにくいエンコーディングや難読化の手法を体系的に適用しました。

攻撃に対するBrowseSafeのテスト

BrowseSafeはQwen3-30Bの上に重ねられた二値分類器として実装されており、コンテンツがエージェントの中核ロジックに到達する前に、safe（安全）またはmalicious（悪意あり）という単純な判定を出力します。 

モデルカードによれば、このシステムは、乱雑なHTML、注意をそらす要素、ブラウジング中に遭遇する一般的なインジェクションパターンに対して堅牢であるよう設計されています。

この設計は、単純な攻撃に対してはうまく機能します。しかし、平文の指示ではなくエンコーディングに依存するプロンプトインジェクション手法に対しては、モデルは苦戦しました。 

テストでは、Base32、NATOフォネティックアルファベット、Pig Latinを用いてエンコードされた悪意あるプロンプトをBrowseSafeが検知できませんでした。これらのペイロードが実際のWebページに近いHTML構造に埋め込まれていた場合でも同様でした。

対照的に、16進数でエンコードされた攻撃は一貫して検知されており、これらのパターンが学習データ内でより一般的だったことを示唆しています。 

全体として、悪意あるプロンプトのおよそ36%が誤って安全と分類されました。

エンコードされた攻撃がすり抜ける仕組み

中核的な問題は、実装固有というよりアーキテクチャ上のものです。BrowseSafeは入力テキストをデコードせずに、そのまま分類します。

エンコーディング手法は、悪意ある指示の表面的な見え方を変えつつ、意図は保持します。 

下流の大規模言語モデル（あるいは人間）は、ガードレールが入力を承認した後でも、これらの変換を容易にデコードできます。

これにより危険なギャップが生まれます。セキュリティモデルはデコードされていないテキストを評価する一方で、対象モデルはデコードされた意図を解釈するのです。

ガードレールがエンコードされたペイロードを承認してしまうと、下流のエージェントが攻撃者の指示を実行することを本質的に妨げるものはありません。

BrowseSafeが主要、あるいは唯一のガードレールとして使われる環境では、これが単一障害点になります。いったんプロンプトが安全と分類されると、下流側に悪意ある振る舞いを検知または停止する制御が存在しない可能性があります。 

これらの失敗は、曖昧なエッジケースではありませんでした。 

多くのケースで、BrowseSafeは明らかに悪意あるコンテンツに対して高い確信度でsafe判定を返しており、確信度スコアだけでは保護の信頼できる指標にならないことを示しています。

エージェントセキュリティのための多層的な制御

単一のモデルベースのガードレールに依存するだけでは、現実世界のプロンプトインジェクション攻撃、特にエンコーディングや難読化手法を悪用する攻撃に対して防御するには不十分です。 

効果的な緩和には、プロンプトがエージェントの中核ロジックに到達する前後の失敗を考慮した、多層防御（Defense-in-Depth）アプローチが必要です。 

組織は、初期スクリーニングをすり抜ける攻撃があることを前提に、影響を限定し、不正利用を検知し、時間とともに適応できる制御を設計すべきです。 

• レッドチームにより、デプロイ前にエージェントのパイプライン全体を自動テストで検証する（意味的、エンコード、難読化されたプロンプトインジェクション手法をカバー）。
• 分類前に入力を正規化しデコードすることで、難読化ベースのバイパスを減らし、ガードレールが真の意図を評価できるようにする。
• 単一モデルではなく、多層・アンサンブルのガードレールを使用することで、意味的・構造的・行動的な異常を検知する。
• 決定論的なポリシーと最小権限の制御を強制することで、プロンプトが初期スクリーニングを通過した場合でも、エージェントやツールが実行できることを制限する。
• 実行時モニタリングとアクションレベルの制御を追加することで、行動のドリフトを検知し、ツール使用を検証し、危険なブラウザ操作をリアルタイムでブロックする。
• ガードレールモデルをコンポーネントとして扱う—継続的なテスト、監視、フィードバックループに基づいて更新されるセキュリティアーキテクチャの一部として位置づける。

これらの手順を組み合わせることで、ライフサイクル全体を通じてエージェントの振る舞いを整合的で、レジリエントで、安全な状態に保つ助けとなります。

リスクはオープンソースではない — 前提がリスクだ

BrowseSafeの限界は、AIセキュリティにおけるより広い傾向を反映しています。ガードレールがより特化するにつれ、攻撃者は明白な悪意ある言語ではなく、表現レベルの操作にますます依存するようになっています。 

エンコーディングに基づくプロンプトインジェクションは新しいものではありませんが、検査時点で脅威が意味的に判読可能であると仮定するシステムに対しては、依然として有効です。

問題はオープンソースではありません。BrowseSafeは透明性、再現性、そしてAIブラウザセキュリティの有用なベースラインを提供します。リスクは、単一のガードレールモデルを、それ単体で十分な保護であるかのように位置づけることにあります。

自律型エージェントがツール、データ、ワークフローに対してより大きな権限を持つようになるにつれ、セキュリティチームは一部の攻撃が早期検知をすり抜けることを前提にし、そうなった場合でも安全に失敗できるシステムを設計する必要があります。

この変化は、現代のAIシステムがますますゼロトラストのマインドセットを必要としている理由を浮き彫りにします — 侵害を前提とし、実行のあらゆる段階で影響を限定するという考え方です。