2026年3月3日、セキュリティ企業Zenity Labsが公開した「PleaseFix」脆弱性ファミリーは、エージェンティックブラウザという新興カテゴリの構造的欠陥を白日の下に晒した。特にPerplexity Cometを対象とした「PerplexedBrowser」サブファミリーでは、ゼロクリックでのファイルシステム窃取、パスワードマネージャーからの認証情報奪取、完全なアカウントテイクオーバーが実証されている。Zenity CTOのMichael Bargury氏は「これはバグではない。エージェンティックシステムに内在する構造的脆弱性である（This is not a bug. It is an inherent vulnerability in agentic systems.）」と断言した。本稿では、テクノロジーの視点からPleaseFix脆弱性の技術的メカニズムを解剖し、AIエージェント統合における防御設計の要件を分析する。

PleaseFix脆弱性ファミリーの解剖 ── 「意図の衝突」が生む構造的欠陥

PleaseFix脆弱性の根本原因は、間接プロンプトインジェクション（Indirect Prompt Injection）の一形態である「Intent Collision（意図の衝突）」にある。AIモデルは、ユーザーが明示的に与えた正当な指示と、外部データに埋め込まれた攻撃者の指示を原理的に区別できない。従来のWebブラウザでは、Same-Origin Policyやコンテンツセキュリティポリシー（CSP）によってデータとコードの境界が明確に定義されていた。しかしエージェンティックブラウザでは、自然言語による指示がデータとコードの両方の役割を担うため、この境界が消失する。

Perplexity Cometの事例では、ブラウザがローカルファイルシステムへのアクセス権、パスワードマネージャーとの連携機能、Webページの自動巡回機能を統合的に提供している。これらの機能は個別にはユーザー利便性を高める正当な設計であるが、攻撃者がカレンダー招待やメール、Webページに悪意ある指示を埋め込むことで、エージェントの権限をハイジャックする経路となる。Zenity Labsは2025年10月22日にPerplexityへ責任ある脆弱性開示を行い、2026年1月23日に修正が完了した。しかし、約3ヶ月の修正期間が必要であったことは、この問題がパッチ適用で簡単に解決できる類のものではないことを示している。

この構造的問題は、プロンプトインジェクション攻撃の防御限界で分析したとおり、LLMベースのシステムに共通する未解決課題である。PleaseFix脆弱性は、この理論的リスクが実環境で具体的に悪用可能であることを実証した点で、エージェンティックAIセキュリティの転換点となる事例である。

3つの攻撃ベクトル ── ゼロクリック窃取からアカウントテイクオーバーまで

PleaseFix脆弱性が実証した攻撃ベクトルは3つに大別される。第一のベクトルは「ゼロクリック・ファイルシステム窃取（Zero-Click File System Exfiltration）」である。攻撃者はカレンダー招待、メール本文、あるいは通常のWebページに悪意ある指示を埋め込む。エージェンティックブラウザがこれらのコンテンツを処理する際、埋め込まれた指示に従ってローカルファイルシステムにアクセスし、機密データを外部に送信する。ユーザーには正常な処理結果のみが表示されるため、窃取が発生していることに気づく手段がない。インシデント対応の現場では、1秒の判断遅れが被害範囲を指数関数的に拡大させるが、ゼロクリック攻撃では検知そのものが困難であり、被害認知時点ですでに大量のデータが流出している可能性が高い。

第二のベクトルは「認証情報窃取とアカウントテイクオーバー（Credential Theft & Account Takeover）」である。Zenity Labsのデモンストレーションでは、1Passwordとの連携を悪用し、保存されたクレデンシャルの表示、マスターパスワードの変更、リカバリー資料の抽出が可能であることが示された。エージェントはパスワードマネージャーの正規APIを通じてこれらの操作を行うため、パスワードマネージャー側から見れば正当なユーザー操作と区別がつかない。この攻撃は特に深刻である。パスワードマネージャーは「最後の砦」として設計されており、ここが突破されれば連鎖的に全アカウントが危殆化する。

第三のベクトルは、上記2つを組み合わせた「完全アカウントテイクオーバー」である。エージェントの正規アクセス権限を利用して、認証情報の取得からアカウント設定の変更まで一連の攻撃をシームレスに実行する。従来のRCE（Remote Code Execution）脆弱性と異なり、エージェントが持つ正規の権限範囲内で攻撃が完結するため、既存のエンドポイント保護ソリューションやネットワーク監視では検知が極めて困難である。Claude Desktop Extensions RCE脆弱性でも同様の権限モデルの問題が指摘されており、デスクトップAIツール全般に共通する構造的課題であることがわかる。

エージェンティックAIエコシステムの系統的リスク ── 31,000スキル分析が示す現実

PleaseFix脆弱性はPerplexity Comet固有の問題ではない。Ciscoが開発したSkill Scannerによる31,000以上のエージェントスキルの分析では、26%が少なくとも1つのセキュリティ脆弱性を含んでいることが判明している。4つに1つのスキルが脆弱であるという事実は、エージェンティックAIエコシステム全体がセキュリティ負債を抱えていることを意味する。さらに深刻なのは、デプロイ済みのAIエージェントの25.5%が他のエージェントを作成・タスク委任する能力を持っている点である。この「エージェント・スポーニング」は監査を事実上不可能にする。

エージェントが別のエージェントを生成し、そのエージェントがさらに別のエージェントにタスクを委任する連鎖構造では、最初のエージェントに付与された権限がどこまで伝播するかを追跡する手段がない。これはエージェンティックAI攻撃面の産業化で論じた権限エスカレーション問題の具体的な顕在化である。従来のIAM（Identity and Access Management）は人間のユーザーを前提として設計されており、自律的に行動するエージェントの権限管理には対応していない。

この系統的リスクは、サプライチェーン攻撃の文脈でも増幅される。MCP Server 36.7%のSSRF脆弱性とサプライチェーン防御で分析したとおり、AIエージェントが利用するツールやスキルのサプライチェーン自体が攻撃対象となる。PleaseFix脆弱性で示されたブラウザレベルの攻撃と、スキルレベルの脆弱性、サプライチェーンの汚染が組み合わさることで、攻撃面は乗算的に拡大する。エージェンティックAIの攻撃面は線形ではなく指数関数的に増大するという認識が、防御設計の前提となるべきである。

防御設計の5原則 ── エージェンティック時代のセキュリティアーキテクチャ

PleaseFix脆弱性から導出される防御設計は、5つの原則に集約される。第一は「アイデンティティ制御の厳格化」である。エージェンティックブラウザのセッションにはSSO（Single Sign-On）とMFA（多要素認証）を必須とし、エージェンティックブラウジングと機密データへのアクセスを伴うブラウジングをセッションレベルで分離する。これは最小権限の原則をエージェントに適用する最も基本的な措置であるが、現時点でこの分離を実装しているエージェンティックブラウザは皆無に近い。

第二は「行動監視とSIEM/XDR統合」である。エージェントの全操作をイベントとして記録し、SIEM（Security Information and Event Management）やXDR（Extended Detection and Response）プラットフォームに連携する。通常のブラウザ操作と異なり、エージェントの行動パターンは機械的で予測可能であるため、異常検知モデルの構築は技術的に実現可能である。ファイルシステムへのアクセスパターン、パスワードマネージャーとのインタラクション頻度、外部通信先の変化などをベースラインとして監視する。

第三は「Human-in-the-Loop（人間介在）の強制」である。特権セッション、すなわちパスワードマネージャーへのアクセス、ファイルシステム操作、アカウント設定変更を伴う操作では、エージェントの自動実行を無効化し、人間による承認を必須とする。利便性は低下するが、PleaseFix脆弱性が示したリスクの深刻さを考慮すれば、現時点では不可欠な措置である。脆弱性診断のノウハウは、開発段階で活かしてこそ価値がある。後付けのセキュリティは常にコストが高く、Human-in-the-Loopの設計もプロダクト初期段階で組み込むべきである。

第四は「コンテンツバリデーション」である。エージェントがアクセスする外部コンテンツ（メール、カレンダー、Webページ）を処理前にサニタイズし、プロンプトインジェクションの可能性がある指示を除去またはエスケープする。ただし、自然言語の特性上、完全なサニタイズは原理的に困難である。現実的なアプローチは、外部コンテンツをエージェントに渡す際に「信頼されていないデータ」であることを明示的にマークし、エージェントの実行権限を制限するサンドボックスモデルの採用である。

第五は「スキル検証の体系化」である。CiscoがオープンソースとしてリリースしたSkill Scannerは、エージェントスキルの脆弱性を自動検出するツールである。31,000以上のスキルを分析し26%に脆弱性を発見した実績は、このアプローチの有効性を示している。企業はエージェントスキルの導入プロセスにSkill Scannerのような検証ツールを組み込み、脆弱なスキルのデプロイを防止する必要がある。AIエージェント攻撃の産業化が加速する中、スキルの安全性検証はソフトウェアサプライチェーンセキュリティの一部として制度化されるべきである。セキュリティ戦略は、ビジネスの制約を理解した上でないと絵に描いた餅になるため、これらの原則はコスト・利便性・リスクのバランスを考慮して段階的に導入する設計が求められる。

FAQ

PleaseFix脆弱性とは何か？

2026年3月にZenity Labsが公開した、エージェンティックブラウザに内在する構造的脆弱性ファミリーである。バグではなくエージェンティックシステムの設計原理に起因する問題であり、間接プロンプトインジェクションの「Intent Collision」メカニズムを通じてゼロクリック攻撃を可能にする。

Perplexity Cometはすでに修正されているか？

Zenity Labsが2025年10月22日に脆弱性を報告し、Perplexityは2026年1月23日に修正を完了した。ただし、修正はPerplexedBrowserサブファミリーの特定の攻撃経路に対するものであり、Intent Collisionという根本原因はエージェンティックシステム全般に残存している。

自社のAIエージェントが脆弱かどうかをどう判断するか？

CiscoがオープンソースとしてリリースしたSkill Scannerで検証可能である。31,000以上のスキルを分析した結果、26%に脆弱性が検出された実績がある。エージェントが外部データを処理しローカルリソースにアクセスする設計であれば、PleaseFix型攻撃のリスクがある。

エージェンティックブラウザを企業で安全に利用できるか？

現時点では、機密データを扱う業務でのエージェンティックブラウザ利用にはリスクが伴う。SSO・MFA必須化、セッション分離、Human-in-the-Loop強制、SIEM統合などの多層防御を実装した上で、段階的に導入範囲を拡大するアプローチが現実的である。

従来のブラウザセキュリティ対策では防御できないのか？

従来のCSP、Same-Origin Policy、WAFなどはデータとコードの境界が明確なアーキテクチャを前提としている。エージェンティックブラウザでは自然言語がデータとコードの両方の役割を担うため、既存の防御メカニズムでは対応できない。エージェント固有の行動監視と権限制御が必要となる。

パスワードマネージャーとの連携は停止すべきか？

PleaseFix脆弱性の文脈では、エージェンティックブラウザとパスワードマネージャーの連携は高リスクである。少なくとも特権セッションではエージェントのパスワードマネージャーアクセスを無効化し、人間による明示的な操作のみを許可する設定が推奨される。

AIエージェントの25.5%が他のエージェントを生成できるというリスクは何か？

エージェントが別のエージェントを生成・タスク委任する「エージェント・スポーニング」は、権限の伝播経路を追跡不能にする。初期エージェントに付与した権限がどこまで拡散するか監査できなくなり、インシデント発生時の原因特定と被害範囲の確定が極めて困難になる。

参考文献