ブラウザーエージェント：そのセキュリティリスクとは？

要約: AI搭載のブラウザエージェントのセキュリティリスクは、従来のソフトウェアリスクとは構造的に異なります。エージェントは認証済みセッションを継承し、複数のアプリケーションを同時に操作し、既存の制御層では解釈できない自然言語の指示からアクションを生成します。これらを管理することはサイバー回復力構築の一部であり、インシデント後ではなく展開前にアイデンティティとデータの両方の可視性が必要です。

ブラウザー エージェントは、ほとんどのセキュリティ チームが対応できるよりも速く、パイロット プログラムから本番のワークフローへ移行しています。

各デプロイは、Copilot の統合であれ、Claude の拡張機能であれ、あるいは財務部門で動作している ChatGPT のワークフローであれ、既存のセキュリティ コントロールでは見えない、ログに残せない、統制できないという、別個の種類の露出（エクスポージャー）を生み出します。

認証レイヤーはエージェントを信頼されたユーザーとして扱い、データ レイヤーはそれらが何にアクセスしているかを可視化できず、コントロール レイヤーは自然言語で動作する自律型のものではなく、決定論的なアプリケーションのために作られていました。

このガイドでは、その露出（エクスポージャー）を評価する方法、リスク階層ごとにエージェントを分類する方法、そして作業を止めることなくリスクを管理できるコントロールを適用する方法を説明します。

ブラウザー エージェントとは何ですか？

ブラウザーエージェントは、ユーザーの代わりにウェブブラウザ内で自律的に行動する AI システムです。ウェブアプリケーションをナビゲートし、フォームに入力し、ボタンをクリックし、ファイルをダウンロードし、認証済みセッション全体で、段階的な人手による指示なしに多段階のワークフローを実行します。

エージェントは自然言語の指示を受け取り、大規模言語モデルでそれを解釈し、ブラウザが到達できるあらゆるアプリケーション上でタスクを完了するために必要な一連のアクションを生成します。

現在のブラウザーエージェントの仕組み

3つの主要な実装が、暴露の実用的な範囲を示しています。

1. Anthropic の Claude は Web を閲覧し、タブをまたいでアクションを実行し、ローカルシステムとやり取りできます。Anthropic 自身の research documentation では、次のように明確に述べています。「ブラウザの利用は、プロンプトインジェクションのリスクを 2 つの方法で増幅します。第一に、攻撃面が非常に広いことです。あらゆる Web ページ、埋め込みドキュメント、広告、そして動的に読み込まれるスクリプトは、悪意のある指示のための潜在的なベクター（攻撃経路）となり得ます。」

2. OpenAI の ChatGPT agent には4つのコンポーネントが含まれます：Operator（自律的なWebブラウジング）、Deep Research（マルチステップのインターネット調査）、Code Interpreter（Pythonの実行）、および Google Drive、GitHub、OneDrive との連携です。OpenAI の official documentation は次のようにはっきり述べています：「これは新たなリスクをもたらします。特に ChatGPT agent がユーザーのデータと直接連携して作業できるためです。」

3. Microsoft Copilot Actions は Power Automate のフローと認証済みコネクタを使用して、Power Platform のインフラ上で実行されます。実際には、構成設定や、特定のアクション種別に対して承認がどのように実装されているかによって、ユーザーの資格情報の下で自動アクションが実行される場合があります。

既存のセキュリティ対策ではブラウザー agent の活動が見えない理由

セキュリティスタックは、構造化データ上で動作する決定論的なアプリケーションを前提に構築されてきました。ブラウザー agent は、確率的な出力を伴う自然言語で動作し、既存のすべての制御（control）が動作する場所よりも上に位置するセマンティック層（semantic layer）で判断を行います。

既存のツールは、agent が意思決定を行う層より下で動作しています。

CASB、DLP、ネットワーク監視、EDR はすべて出力層で動作します。これらは、意思決定が行われた後に、トラフィック、パターン、プロセスの動作状況を確認します。既存の多くのツールでは、エージェントがどのように推論しているのか、またはブラウザのタブ内でどの指示を実行しているのかを観察する能力が限られています。

顧客の財務データを要約して外部に送信するよう指示されたエージェントは、一連の行動によってそのタスクを完了しますが、その行動はこれら4つのツールすべてにとって完全に通常のものとして記録されます。

ブラウザエージェントは、すべての認証済みセッションを同時に読み取ることができます

ブラウザは同一オリジンポリシー（Same-Origin Policy、SOP）を適用し、あるドメイン上のスクリプトが別のドメイン上のデータを読み取れないようにします。ユーザーレベルのプロセスまたは拡張機能として動作するブラウザエージェントは、SOPが通常はスクリプトレベルで隔離する複数の認証済みセッションを実質的にまたいで操作できます。

それらはユーザーレベルのプロセスとして動作し、ブラウザ内で有効になっているすべての認証済みセッションに同時にアクセスできます。そのため、HRシステム、会計（ファイナンス）アプリケーション、CRMは互いに分離されなくなります。

Webページ、メール、またはカレンダー招待に埋め込まれた悪意のある指示によって、エージェントがそれらすべてからデータを取得し、1つの自動化されたシーケンスで結合するよう誘導される可能性があります。

エージェントの通信は有効な認証情報とともに到達するため、IDの制御がそのまま通過させてしまいます

ブラウザエージェントは既存の SSO セッションを通じて認証し、アイデンティティプロバイダーから有効なトークンを継承します。エージェントが行うすべての要求は、許可されたチャネル経由で正当な認証情報とともに組織のサービスへ到達します。

OAuth と SAML は、セッションの存続期間中は認証済みの主体を信頼できるものとして扱います。しかし、その主体がプロンプトごとに振る舞いが変わる自律エージェントである場合、このモデルは機能しません。

ブラウザーエージェントのセキュリティリスク5種類

以下のリスクは机上の空論ではありません。各カテゴリには、実際に発生した事例が記録されているか、悪用の実行を示す公開された研究プロトタイプがあります。

1. 悪意のあるWebコンテンツによるプロンプトインジェクション

OWASP LLM Top 10 はプロンプトインジェクションを LLM アプリケーションに対する最上位の脅威として位置づけています。エージェントが処理するコンテンツに隠された悪意のある指示が、その動作を完全に乗っ取る可能性があるためです。

エンタープライズ向けのブラウザーエージェントは、リスクを最大化する3つの条件をしばしば併せ持つため、特に危険にさらされます。具体的には、機密データへのアクセス、不特定（信頼できない）コンテンツへの曝露、そして外部と通信できる能力です。

研究者は、悪意のあるカレンダー招待、ドキュメント、または埋め込まれたWebコンテンツが、意図しないエージェントの動作を引き起こし得ること、またローカルまたはクラウドのデータを「クリック不要」で流出させる（ゼロクリック）ケースも含まれることを示しました。

8つのプロンプトインジェクション防御アプローチに関する学術的評価では、すべてが回避可能であることが判明し、published research により、強固に対策された防御に対しても高い攻撃成功率が報告されています..

2. 外部 AI エンドポイントへの機密データの流出

多くの組織では、従業員が承認された企業向けツールと並行して、無料枠または個人アカウントの AI ツールを使用しており、その利用の一部には機密データや規制対象データが含まれていることがあります。

多くの GenAI アクセスがブラウザ経由で流れるため、データはセキュリティスタックが通常のWebトラフィックとして扱う経路を通じて外部の AI エンドポイントに到達する可能性があります。

従来の shadow AI controls は承認済みのアプリケーション一覧に重点を置いており、このパターンを構造的に検知できません。

3. 自律的なアクションによって業務が中断され、データが失われる

ブラウザーエージェントは破壊的な権限（たとえば削除や取り返しのつかない変更操作）を継承でき、タスクが誤解されたり、範囲設定が不適切だったり、敵対的なコンテンツの影響を受けたりした場合に、それらを機械の速度で実行してしまうことがあります。

また、マルチエージェントのセットアップでは、ツール間およびセッション間の継承パターンによって、ユーザーに明確な可視性がないまま下流ツールで不正な操作が可能になることがあります。

これらのインシデントには共通の根本原因があります。エージェントに、特定の意図されたタスクに権限を限定しないまま、ユーザーと同等の権限が付与されているのです。

4. 認証情報の窃取、セッションハイジャック、横方向への移動

コーネル大学の研究 は、プロンプトインジェクションが、従来のマルウェアキャンペーンを模した5段階攻撃へ進化していることを示しています。つまり、初期アクセス、特権昇格、エージェントのメモリ内での永続化、接続されたサービス間での横方向への移動、そして実行です。

これらのマルチホップ攻撃は、エージェントが複数のサービスにまたがって同時に認証済みセッションを維持するという事実を悪用します。攻撃者が指示を正常にインジェクトできると、ユーザーのアクセス範囲全体にまたがる認証情報の連鎖（credential chain）を得ることができます。

5. ガバナンスされていない AI 導入による、静かなコンプライアンスの逸脱

既存のフレームワークは自律型システム向けに設計されていません。HIPAA の監査管理（audit controls）要件（45 CFR §164.312(b)）の下で、統一されたログがない状態で複数のシステムにまたがって動作するブラウザーエージェントは、直ちに違反を引き起こします。

GDPR Article 22 のもとで、人の監督なしにデータアクセスに関する自律的な判断を行うエージェントは、自動化された意思決定に対する保護に違反する可能性があります。より広く言えば、シャドーAIは標準的なログ記録、保管（retention）、およびアクセス管理（ガバナンス）制御を回避することが多いため、侵害や監査への影響を大きくする可能性があります。

環境におけるブラウザーエージェントのセキュリティリスクを評価する方法

コントロールを適用する前に、組織は3つの側面にまたがるベースライン（基準）を用意する必要があります。つまり、エージェントがどこにデプロイされているか、どのデータに到達（アクセス）できるか、そして権限継承の状態がどのようになっているか、です。

ステップ 1：ブラウザーのAIと拡張機能の利用状況を棚卸しする

DLP tools を設定して、AI トラフィックのパターンを特定し、主要な AI サービスへの接続に関するプロキシログを取得し、OAuth 認可ログを確認します。 Microsoft Defender Vulnerability Management は、追加費用なしで Edge、Chrome、Firefox にまたがってネイティブのブラウザー拡張機能インベントリを提供します。

によると LayerX Security の 2025 Browser Security Annual Report 、企業向けブラウザ拡張機能のかなりの割合が高い権限、または重大な権限を持っており、GenAI 拡張機能は標準の拡張機能よりも広い権限スコープを要求します。

ステップ 2：データの露出状況をマッピングし、エージェントがアクセスできるものを把握する

見つかった各エージェントについて、到達可能な認証済みセッションがどれかを記録してください。Netwrix 1Secure Platform の Data Security Posture Management（DSPM）機能は、アクセス権を持つアイデンティティと関連付けながら、機密データを継続的に特定して分類します。First National Bank Minnesota がセキュリティを強化するために Active Directory を再構築する必要があったとき、最初に機密性の高い顧客データを発見し分類できたことにより、当初6か月と見積もられていたプロジェクトをわずか3週間で完了できました。

エージェントが実際に何にアクセスできるか分からないですか？ Netwrix 1Secureは機密データをマッピングし、アクセス権を持つIDと関連付けます。 デモをリクエスト エージェントがギャップを検出する前に。

ステップ 3：アイデンティティと権限の継承を分析する

多くの企業では、ユーザー、サービスアカウント、OAuth 接続済みアプリにまたがって特権が拡散（privilege sprawl）している状態が、すでに存在しています。ブラウザのエージェントはその拡散を継承し、機械の速度でそれを行使できます。エージェントの展開を開始する前に、必要な権限状態と実際の権限状態の差（ギャップ）を文書化してください。

ステップ 4：ベンダーのセキュリティ態勢と標準搭載の制御を評価する

各エージェント ベンダーが文書化しているセキュリティ アーキテクチャを確認します。エージェントがアクセスできるデータ、処理が行われる場所、プロンプトと応答がどのように保存されるか、そして利用可能なエンタープライズ制御を把握してください。

ステップ 5：承認済み・制限付き・ブロック対象の利用ポリシーを定義する

許容される利用（Acceptable use policy）ポリシーには、どの AI ツールが認められているのか、各ツールで許可されるデータ分類、ユーザーの責任、禁止される行為、および施行（執行）メカニズムを明確に含める必要があります。新しいエージェントの機能がリリースされるたびに、ポリシー要件は急速に変化します。中には、1四半期の間に AI の許容される利用ポリシーを複数回更新している組織もあり、各改訂でエージェントのアップデートによって導入された新しい例外（エッジケース）に対応しています。

生産性を止めずにブラウザー エージェントのセキュリティ リスクを低減する方法

すべてのブラウザー AI をブロックすることは、ほとんどの組織にとって現実的なセキュリティ態勢ではありません。以下のコントロールは、実装コストに対する影響度の大きさに基づいて並べ替えています。

リスク分類と、最小権限（least privilege）に基づく是正は前提条件です。残りのコントロールは、それらが確立するアクセス衛生（access hygiene）を土台として構築されます。

リスク階層によってエージェントを分類します：承認（approved）、制限（restricted）、またはブロック（blocked）

各ブラウザー エージェントのユースケースを、次の4つの観点で評価します：データの機密性（data sensitivity）、運用への影響（operational impact）、規制上のリスク（regulatory exposure）、および意思決定の自律性（decision autonomy）。さらにブラウザー固有の要素として、資格情報へのアクセス範囲、セッションの境界、外部サービスとの統合、そしてエージェントの操作を監視して取り消せるかどうかを追加で考慮してください。

• 低リスク（承認）： 公開データのみ、企業の資格情報は使わない、標準的な監視で十分。
• 中リスク（制限）： 非機密の企業データに対して ロールベースのアクセス制御 が必要。読み取り専用の状態を優先し、監視と DLP のカバレッジを強化し、四半期ごとに再認証を実施します。
• 高リスク（ブロックするか、補償的なコントロールで統制する）： 規制対象データ、認証クレデンシャル、本番システム、または自律的な意思決定能力が該当します。あらゆるデプロイの前に、完全なセキュリティ評価、継続的な監視、そして専任のガバナンスレビューが必要です。

エージェントが既存の露出を拡大する前に、最小権限を徹底する

今日ユーザーが過剰な権限を持っている場合、ブラウザーエージェントはそのすべてを継承し、機械のスピードでそれらを実行します。エージェントの導入前に過剰に付与されたアクセスを是正することは、利用可能な準備の中で最も回収効率が高いアクションです。

Netwrix Privilege Secure は常駐特権をゼロにした just-in-time のアクセスを強制します。つまり、管理対象アカウントの下で動作するエージェントは、悪用されるのを待つ継続的な高権限アクセスを保持しません。すべての特権操作は監査証跡内の特定のアイデンティティに紐づけられ、コンプライアンスフレームワークが求めるフォレンジック可視性を提供します。

たとえば、ペネトレーションテスターが過剰にプロビジョニングされた管理者アカウントを繰り返し悪用したとき、Eastern Carver County Schools は、常時の特権をなくす just-in-time アクセスモデルを導入しました。IT リソースに限りがある学区にとって、このレベルの制御を「数か月ではなく数日で」実装できることは、9,300 人の生徒のデータを確保するうえで極めて重要でした。

管理されたブラウザー プロファイルと拡張機能の許可リストを使用する

Microsoft Edge for Business は、仕事用と個人のブラウジングそれぞれに対して別々のセキュリティコンテキストを作成し、3 つのセキュリティレベルをユーザーのリスク プロファイルに対応付けます。Chrome Enterprise では ポリシー競合の検出 により、BYOD デバイスで重要なポリシーが非準拠として検出された場合に、企業アプリケーションへのアクセスを自動的にブロックします。

デフォルト拒否（default-deny）の姿勢で拡張機能の許可リストを運用することは、追加コストが最も低い状態で得られる、最も効果の大きい制御です。Microsoft Edge では、ExtensionSettings ポリシーで既定であらゆる拡張機能をブロックし、リスク評価プロセスをクリアした各ツールについてのみ明示的に承認した例外を許可できます。

データ分類と AI 対応 DLP を適用して、機密データの露出を抑制する

従来の DLP では、GenAI のインタラクションパターンに追いつけません。Data classification どのデータが重要かを制御（コントロール）に伝えることが、その前提条件です。

感度レベルごとに差別化された保護を設定します。受限制データは、ユーザーの役割に関係なく、どの外部 AI ツールにも貼り付けできません。一方で公開データは制限なく流通します。

Netwrix 1Secure Platform は、機密データの検出と分類を Identity Threat Detection および Netwrix Endpoint Protector's DLP 機能と統合します。ハイブリッド環境全体で感度ラベルを継続的に維持し、データがエージェントのワークフローを通じて移動する際にも保護を適用できるようにします。

Microsoft Edge Protected Clipboard は、クリップボードのレベルでポリシー駆動型の保護レイヤーを追加し、機密性の高いアプリケーションからのコピー＆ペーストによる情報流出を防ぎます。

ブラウザーおよびアイデンティティ活動における AI 主導の異常を検知

ブラウザーエージェントは、人間のユーザーとは異なるパターンを示します。例：高速なAPI呼び出し、大量データへのアクセス、勤務時間外の活動、短い時間枠内でのアプリケーション間でのデータ集約。

Defender for Cloud Apps は、サインイン イベント中のブラウザー アクティビティのパターンを分析して脅威を特定します。エージェントは正当なユーザーと同じプロトコル、資格情報、チャネルを共有しているため、アイデンティティに基づく異常検知が、今日利用可能な中で最も技術的に実行可能なメカニズムです。

エージェントのアクティビティを区別する振る舞い（速度、範囲、タイミング）は、identity threat detection が統制されたアイデンティティのベースラインに対して検出してくる信号です。

Netwrix がブラウザー エージェントのセキュリティ リスクをガバナンスする方法

ブラウザーエージェントは、アイデンティティとデータの交差点に存在します。組織のアイデンティティを使って認証し、組織のデータにアクセスし、これまでのすべての既存コントロールが正当なものとして扱うチャネルを通じて動作します。片方の次元だけを守ってもう片方を守らないと、エージェントが機械の速さで悪用できるギャップが残ります。

Microsoft中心のハイブリッド環境を運用しているミッドマーケット組織にとって、根本的な問いは「どのエージェントをブロックするべきか」ではありません。問題は、あなたの identities が到達できる範囲を正確に可視化できているか、そしてそのアクセスが現在も適切であるかどうかです。この基準（baseline）がない状態では、ブラウザーエージェントのガバナンスは推測に頼ることになります。

Netwrix 1Secure がその基準（baseline）に正面から対応します。Data Security Posture Management（DSPM）は、機密データを継続的に特定・分類し、それに到達できる identities と関連付けます。ただし、可視化（visibility）だけでは、agents が継承する攻撃対象領域（attack surface）を減らすことはできません。

Netwrix Privilege Secure は、常駐アクセス（standing access）を「常駐権限ゼロ（zero standing privileges）」と「必要なタイミングでの昇格（just-in-time elevation）」により解消します。管理アカウント（managed accounts）で動作する agents は、セッション間で継続的に昇格した権限を保持しません。

Identity Threat Detection & Response は、エージェント主導の活動を通常のユーザーのパターンと見分ける行動上の異常を可視化し、既存のブラウザーやネットワーク制御では提供できない検知レイヤー（detection layer）を提供します。

デモを依頼する agents がそれを増幅する前に、Netwrix が環境全体で identity exposure と機密データへのアクセスをどのようにマッピングするかをご覧ください。