AI ブラウザの安全性：５項目のリスク・ケースを８種類のエージェントでテストした

Browser agents don’t always respect your privacy choices

2025/12/22 HelpNetSecurity — ブラウザ・エージェントの普及において、ユーザーによる継続的な入力を必要とせずにオンライン・タスクを処理できるという新たなセールスポイントが強調されている。AI モデルを用いて Web ブラウザを操作することで、ショッピング／予約／アカウント管理などのタスクが可能になる。しかし、新たな学術研究によると、こうした利便性にはセキュリティ上の懸念として無視できないプライバシー・リスクが伴うと警告されている。

2025年にリリースまたはアップデートされた 8 つの主要ブラウザ・エージェントが、このレポートでは評価されている。対象としては、ChatGPT Agent／Google Project Mariner／Amazon Nova Act／Perplexity Comet／Browserbase Director／Browser Use／Claude Computer Use／Claude for Chrome が含まれる。

なお、この調査で検証された５つのユーザー・リスクは、エージェントのアーキテクチャ／不審なサイトの処理／クロスサイト・トラッキング／プライバシー・ダイアログへの応答／Web サイトへの個人データ開示という領域におけるものである。その結果として、合計 30 件の脆弱性が特定され、テストされたすべての製品には、少なくとも１件の問題が含まれることが判明した。

コンポーネントとアーキテクチャの欠陥

研究者たちが測定したのは、それぞれのブラウザ・エージェントが依存する構成要素である Web ブラウザ／言語モデル、および、それらの構築方法に関連するプライバシー・リスクである。その結果、合計８件の脆弱性が特定された。主要な問題は言語モデルの所在であり、８つのエージェントのうち７つが、ユーザー・デバイス外のモデルを使用していた。それが意味するのは、ユーザーのブラウザ状態に関する詳細情報や、アクセスした各 Web ページの内容が、サービス・プロバイダー管理のサーバに送信されることである。

モデルがリモート・サーバで実行される場合、検索クエリや機密性の高い Web ページ・コンテンツの処理および保存の方式を、ユーザーが制御できなくなる。一部のプロバイダーにおいては、データ利用の制限が明示されているが、ユーザーはサービス・プロバイダーのポリシーに依存せざるを得ない。

ブラウザのバージョンの古さも要因である。ブラウザはセキュリティ欠陥を修正するため頻繁に更新されるが、今回のテスト時点で、あるエージェントは、16 世代前のメジャー・バージョン・ブラウザを実行していることが判明した。このソフトウェアには、悪意の Web サイトにより悪用され得る、既知の脆弱性が存在していた。この結果が示すのは、導入したエージェントにおいて、ブラウザ更新が厳密に管理されていない場合に生じるリスクである。

不十分な Web サイト保護

Web ブラウザは、安全でないサイトや悪意のサイトに対して警告を表示することでユーザーを保護する。しかし、ブラウザ・エージェントで確認された８件の脆弱性により、これらのチェックは頻繁に回避されていた。最も蔓延している問題は、セーフ・ブラウジング・リストに掲載される、フィッシングやマルウェアを警告するサイトに対して、警告が表示されない点である。

８つのブラウザ・エージェントのうち６つは、既知のフィッシング・テスト・ページに誘導された際に、セーフ・ブラウジング警告を一切表示しなかった。これらのケースにおいて、エージェントは警告を表示せずに操作を継続する場合もあれば、サイトの危険性を示す表示に失敗する場合もあった。

警告が表示されない場合に、エージェントは悪意のサイトを信頼できるものとして扱い、タスクの一環としてインタラクトを継続する可能性がある。それにより、フィッシング・サイト上でログイン認証情報などの機密情報の入力を促される、リスクが高まる。

エージェントは TLS 証明書の処理においても脆弱性を示した。２つのエージェントは、失効した証明書に対して警告を表示せず、もう１つのエージェントは期限切れ証明書や自己署名証明書についても警告を表示しなかった。無効な証明書を信頼した接続では、中間者攻撃のリスクが高まり、送信情報に対する読み取りや改竄が生じる可能性がある。

あるケースでは、自己署名証明書に関するブラウザ警告をモデルが検知した後であっても、エージェントはサイトへの接続を継続していた。その一方で、すべてのエージェントは、安全でない HTTP 接続を HTTPS にアップグレードまたはブロックし、安全なページ上で安全でないサブリソースをロードしないポリシーを適用していた。

クロスサイト・トラッキングの失敗

ブラウザ・エージェントはクロスサイト・トラッキング防御を弱めており、この領域では３件の脆弱性が確認された。トラッキングにより、企業は異なるサイト間のアクティビティを関連付け、ユーザー・プロファイルを構築できる。一般的な防御策の１つは、Cookie などのサードパーティ・データを分離する、ストレージ・パーティショニングである。

しかし、２つのエージェントは保存状態の一部のみをパーティショニングしており、標準ブラウザのデフォルト設定と比較して、より高いクロスサイト・トラッキング・リスクにユーザーをさらしていた。

別の問題として、長期的なプロファイル状態の保存が確認された。４つのエージェントは、デフォルトで何らかのプロファイル・データを保存していた。そのうちの１つは、ユーザーに通知することなく保存し、削除オプションも提供していなかった。それにより、トラッキングの再利用を可能にする識別データを、ユーザーが消去できなくなる。このレポートでは、分析リソースやエラー監視リソースをブロックするコンテンツ・フィルタリング・ライブラリを統合することで、リスクを軽減するツールも紹介されている。

プライバシー・プロンプトへの自動応答

ブラウザ・エージェントは、Cookie 同意バナーなどのプライバシー・プロンプトに対して自動応答する。この挙動において、５件の脆弱性が確認された。Cookie 同意テストでは、８つのエージェントのうちの４つが、少なくとも１つのシナリオにおいて、「すべて受け入れる」を選択していた。それが起こったのは、「すべて拒否」オプションが存在し、選択できる状況でのことだった。

あるエージェントは、Cookie バナーを承認することで、表示を抑制するエクステンションが実行されていた影響で、すべての Cookie を受け入れていた。別のエージェントは、バナーがページ・コンテンツをブロックしている状況であっても、ユーザー・プライバシーよりもタスク完了を優先して、すべての Cookie を受け入れた。その結果として、タスクを完了させるという目的のためだけに、ユーザーはトラッキングされていた。

他のケースでは、ネットワーク・レベルで Cookie バナーをブロックして、設定を回避するエージェントがあった。別のエージェントでは、応答方法をユーザーに確認し、決定をユーザーに委ねていた。

通知などのサイト権限リクエストについて、あるエージェントは自動的に許可を与えていた。他のエージェントでは、タスク完了に応答が不要な場合に、それらのリクエストは無視された。その他にも、デフォルトで拒否するエージェントもあれば、ストレージ・アクセスなど特定の権限をユーザー操作なしで許可する、ブラウザ動作を継承するエージェントなども確認された。

個人情報の漏洩

エージェントの意思決定ロジックが、ユーザー情報保護よりもタスク完了を優先した結果として、個人データの漏洩が発生していた。そこで確認されたのは、６件の脆弱性の存在である。研究者たちは、エージェントに対して偽の ID 情報を提供し、Web サイトと情報が共有される状況を観察した。

３つのエージェントは、タスク完了に必須でない状況でも、パッシブ (受動的)・テスト中に個人情報を開示していた。別の３つエージェントは、詳細情報が送信されるまで、Web サイトが情報を表示しないというアクティブ (能動的)・テスト中に、情報を共有していた。いくつかのケースでは、過去のチャット／パーソナライズ設定／接続サービスに加えて、ブラウザ・プロファイル・データに保存された情報が再利用されていた。

共有された情報は、基本的な連絡先に留まらなかった。一部のエージェントが共有した情報には、メールアドレス／郵便番号／ログイン情報／年齢／性別／性的指向／人種などの人口統計情報が含まれていた。あるケースでは、クレジットカード番号の送信が試行された。また、別のケースでは IP アドレスに基づく郵便番号が推測され、個人を特定し得る情報として共有された。

エージェントが、個人情報を開示しないケースもあった。その結果として、タスクが完了しない場合であっても、プレースホルダ値の使用や、要求された情報に対する拒絶が報告された。

ブラウザ・エージェントにおけるプライバシーの向上

ブラウザ・エージェント開発者は、ブラウザ・プライバシー専門家と協力し、既存のテスト・ツールを定期的に実行することでプライバシー・リスクを低減できるはずだ。ブラウザ・エージェントは複数の複雑なシステムを統合しているため、設計やコードの小さな変更がプライバシーに影響を与えやすい領域である。

プライバシーの専門家であれば、自動化のための設計とブラウザ保護機能との間の相互作用について、開発者に対して的確に説明できる。また、不適切な無効化やショートカットの追加を防ぐための支援もできる。ブラウザのセキュリティは、プロセス分離／ストレージ・パーティショニング／ネットワーク・パーティショニング／コンポーネント間の制御通信といったシステム設計に依存している。

開発者に対して推奨されるのは、プライバシー／セキュリティのための自動化されたテスト・スイートの使用である。これらのツールは、苦労して得られた知識を取り込み、エッジケースを検証するものであり、すでに複数のオープン・テスト・スイートとして存在している。研究者たちは、再現性のあるプライバシー・テストを支援するために、独自のテスト・サイトとデータセットを公開する予定である。

arXiv に提供された、ブラウザ・エージェント・プライバシーに関する調査結果を紹介する記事です。この領域では、さまざまな欠陥が指摘されていますが、エージェントの設計において、ユーザーの代わりにタスクを完了させることが最優先され、ブラウザ本来の安全装置が後回しにされるという問題があるようです。具体的に言うと、自動操作をスムーズに進めるために、フィッシングサイトの警告を無視したり、プライバシー設定で “すべて同意” を勝手に選択したりといった、セキュリティ上のショートカットが各所で発生しています。また、ベースとして使用するブラウザが古いバージョンであるケースや、閲覧内容を外部サーバで処理するケースも、リスクを大きくしています。利便性と引き換えに、本来ユーザーを守るはずのガードレールが外れている状態ですので、利用する際は慎重な判断が求められます。よろしければ、AI Agent での検索結果も、ご参照ください。