セキュリティチームは今、二つのAI関連課題に同時に向き合っています。攻撃者はAIを活用してフィッシングキットを次々と改良し、おとりコンテンツを生成し、ブロックリストが追いつけないスピードでインフラを入れ替えています。一方、従業員はセキュリティチームが審査する間もなくAIツールを導入し、LLMに機密データを貼り付け、AIエージェントにOAuth権限を付与し、誰もチェックしていないAIブラウザ拡張機能をインストールしています。
どちらの問題も、同じ場所で起きています。それがブラウザです。最も効率的な対策は、ブラウザセッション内の動作を深いレベルで把握できる単一プラットフォームを導入することです。それぞれが半分しか見えない二つの別ツールを使うのではなく、一本化された視点が求められています。
従来の防御を超えるAI活用型攻撃
セキュリティは常に攻撃者と防御者のいたちごっこですが、AIによって攻撃側の速度が加速しています。フィッシングキットはかつてないスピードでフォークされ、改変され、市場に投入されています。AIは犯罪エコシステムの力を乗数的に増幅する存在であり、防御側の計算を三つの面で変えつつあります。
AIが攻撃ツール開発を劇的に加速：攻撃者はエンジニアと同じようにAIを活用し、成果物を何倍にも増やしています。PhaaS（フィッシング・アズ・ア・サービス）のツールやキットの開発・改良において、AIの積極的な利用が確認されています。
その典型例が、InstallFixやConsentFixといった新手法を取り込みながら急速に進化するClickFixです。また、デバイスコードフィッシングは正規のOAuthフローを悪用してMFAとパスキーを完全に回避する手法で、研究上の話題から産業化されたPhaaS製品へと急成長し、現在18以上のキットが実際に追跡されています。AitMとデバイスコードキットが単一プラットフォームに統合されつつある中、AIの積極的な活用の痕跡が見えてきています。ShinyHuntersやBlackFileが広く利用するDoko’s Panelおよびその派生キットの内部を調査した際にも、その傾向が確認されました。
IoCベースの検知が急速に形骸化：AIはすでに低コストだったフィッシングインフラ構築のコストをさらに引き下げています。説得力のあるフィッシングページを数分でバイブコーディングし、新しいドメインに展開して被害者を獲得し、評判サービスがフラグを立てる前にローテーションするという手口が可能になっています。
Spamhausによると、フィッシングドメインの89%は活動期間が2日未満です。ブロックリストやIOCフィードに依存している組織にとって、すべてのフィッシング攻撃は事実上のゼロデイです。過去に見たことがなく、次の攻撃も同じ姿では現れません。
さらに、フィッシングリンクのホスティングや配信に正規サイトが悪用されることと組み合わさり、ドメインやIPといった低レイヤーのIoCに頼るだけでは正常と悪意を見分けることが非常に困難になっています。最近では、正規のAIチャット共有機能を通じて悪意あるリンクをホストする事例も観測されており、私たちはこの手口をLLMShareとして検知しています。
AIがマルチチャネルキャンペーンの構築・運用を容易に：Pushの独自データによると、フィッシングのペイロードの約3件に1件はメール以外のチャネル経由で届いています。マルバタイジング、ソーシャルメディア、SEOポイズニングなどです。ClickFixはさらに顕著で、ペイロードの5件中4件が検索エンジンの結果経由で届いています。メールセキュリティは、最も急成長している配信チャネルに対して構造的に死角を抱えているのです。
LLMShareの事例もこの点で示唆的です。攻撃者は検索エンジン広告を通じてリンクをマルバタイジングしており、URLを見ただけでは見破ることがほぼ不可能です。メール以外の配信手段、正規サイトの悪用、AIツール自体の悪用が組み合わさることで、最大限の被害をもたらし得ることを示しています。
この三つのトレンドはいずれも、ペイロードの配信とアカウント乗っ取りが実際に発生する場所、すなわちブラウザセッションで収束します。検知はそのレイヤーで機能させる必要があります。ドメインをフィードと照合するのではなく、ページの挙動、スクリプトの実行、悪意ある仕組み（セッション窃取、悪意あるコピー＆ペースト、ファイルダウンロードなど）を分析することが不可欠です。特に、多くの攻撃が現在エンドポイントに触れることなくブラウザセッション内で完結しているためです。
制御されないAI導入という、もう一つの問題
従業員側では、AIの導入がガバナンスを上回るスピードで進んでいます。
競争力を維持するために組織全体でAIをより積極的に活用せよ、というトップダウンの命令があります。効率や生産性の向上を妨げる形でそのプロセスをブロックしたり、ボトルネックを作ったりするだけでは通用しません。セキュリティチームは、AIを安全かつセキュアに導入する方法を見つけなければなりません。
多くの組織でこの状況が制御不能に陥っていることは、各種データが示しています。2026年版Verizon DBIRによると、社用デバイスで定期的にAIを利用する従業員は45%に上り、そのうち67%が非法人アカウントを使用しています。Pushの独自テレメトリによると、平均的な組織では16種類のAIアプリ、17種類のAIブラウザ拡張機能、17種類のAI接続OAuth連携が存在しており、その大半が未承認です。AIツールへのファイルアップロードのうち38%は、組織アカウントではなく個人のシャドウアカウントから行われています。
リスクは急速に積み重なります。セキュリティチームが承認しておらず監視もできないAIツールへのクリップボード貼り付けやファイルアップロードを通じて、機密データが組織外に流出します。AIブラウザ拡張機能は社内アプリケーションの閲覧コンテキストを収集し、従来のDLPの外側で動作するデータ流出経路を作り出しています。
AIエージェントは組織データへのアクセスを求めてOAuth権限を要求し、あるシステムから情報を取得し、別のシステムで分析し、さらに別のシステムで提示します。現在はMCP接続によって永続的かつ権限付きのアクセスが生まれており、ほとんどの組織はその可視性と制御手段をほとんど持ち合わせていません。
2026年のVercel侵害事件は、この問題の行き着く先を示しています。侵害されたサードパーティAI SaaSプロバイダーのOAuth連携が、企業のGoogle Workspaceテナントへの侵入口となりました。ShinyHuntersによるSalesloft DriftおよびGainsightへのキャンペーンも、昨年同様のパターンを大規模に実証しました。
ブラウザが両側面を把握できる理由
両方の問題には共通の根本原因があります。セキュリティ上重要な活動が、ほとんどのツールでは観測できないブラウザセッション内で発生しているという点です。
こうした攻撃手法の多くはブラウザネイティブであり、従来の監視ツールはブラウザセッション内での検知・遮断に必要な可視性を持ち合わせていません。
同時に、ブラウザはAI利用の可視化と制御を実現するための最適な単一レイヤーでもあります。アプリ、OAuth権限付与、拡張機能、アカウントのコンテキストをすべて把握できるからです。そして、Claude、ChatGPT Enterprise、Microsoft Copilot、Gemini for Workspaceといったエンタープライズ向けAIツールは、エンタープライズプランでネイティブのプロンプトログとDLPコントロールをますます提供するようになっています。
この二つを組み合わせることで、ブラウザを使って従業員がアクセスできるAIツールを制限し、個人アカウントではなく企業テナントを利用していることを確認した上で、そのプラットフォームのネイティブコントロールによってその環境内の活動を管理できます。
ブラウザはプラットフォームコントロールを実効的なものにし、検知されないまま横行するシャドウAI利用を防ぎます。たとえば従業員が個人アカウントを使用している場合、確認できるエンタープライズ監査ログは存在しません。また、OAuthグラントを通じて動作し、ユーザーが直接操作しないAIエージェント、エージェント型ブラウザ、MCP接続ツールという急成長カテゴリに対しても、そのエージェントを認可する同意決定が下されるのはブラウザです。
ブラウザベースソリューション評価時の確認事項
この分野のプラットフォームを評価する際、真のセキュリティテレメトリを提供するツールと、調査価値の限られたコンプライアンスレポートしか提供しないツールを見分けるための四つの問いがあります。
ポリシー違反を引き起こさなかったAIインタラクションも記録されますか？エンフォースメント優先のツールが記録するのは、ブロックしたもの、つまりアップロードのブロック、未承認アプリの使用、フラグが立ったファイル名です。コンプライアンス上は有用ですが、最も重要なイベントはしばしば当時は正常に見えたものです。静かにパーミッションを更新した承認済み拡張機能、技術的には許可されていたが本来すべきでなかったOAuth同意付与、退職前に徐々に変化した行動パターンを持つユーザーなどがその例です。ツールが違反だけでなく、許可されたイベントのテレメトリも収集するかどうかを確認してください。
AIエージェントが組織データへのアクセスを要求する際の、完全なOAuthコンセントフローを記録しますか？エンフォースメント優先のほとんどのツールはOAuthをバイナリ、つまり承認済みアプリかブロック対象アプリかで扱います。OAuthグラントがIT管理の連携であった時代はそれで十分でした。しかし、ユーザー起点の同意付与が広いスコープでブラウザセッション内に発生し、セキュリティチームの認識なしに行われることが多いエージェント型AIには不十分です。適切なツールは、要求されたスコープ、承認者、権限を受け取ったアプリケーションを記録し、リアルタイムで警告またはブロックできる必要があります。
シグネチャが存在しない新しい攻撃手法が出現した場合、どのくらいの速さで検知できますか？攻撃者は数時間でインフラを入れ替え、AIを使って新しいおとりコンテンツを大量生成します。ブロックリストと既知の悪意あるインジケーターに依存する検知モデルは、構造的にあらゆる新手法より遅れます。脅威フィードにインフラが登場する前に発動した具体的な検知例をベンダーに示してもらうよう求めてください。
SIEMに届くテレメトリはアラートだけですか、それとも調査を可能にするセッションデータも含まれますか？ツールによっては、ポリシー違反、タイムスタンプ、関与したユーザーといったアラートメタデータのみを送信するものがあります。一方、認証情報の再利用、アプリログイン、拡張機能のインストール、新規導入アプリ、拡張機能の権限更新、ファイルのアップロード・ダウンロード、クリップボードアクティビティ、OAuthコンセントといった広範なテレメトリを転送するツールもあります。この違いが、SOCがSIEMイベントそのものから調査できるか、実際の証拠を得るためにベンダーのコンソールに戻る必要があるかを左右します。
実際の活用イメージ
Push Securityは、ブラウザベースの脅威検知・対応プラットフォームです。軽量なブラウザ拡張機能として導入でき、ブラウザの移行を必要とせず1時間以内に組織全体に展開できます。PushはAIの可視化とコントロールを、プラットフォームの基盤アーキテクチャから自然に拡張する機能として位置づけており、攻撃検知とAIガバナンスの両方を単一ツールで実現する深いブラウザレイヤーのテレメトリを提供しています。
Pushでできること：
-
AIを活用したフィッシングや急速に進化する*Fix型攻撃など、新興のブラウザベース攻撃手法の検知・阻止
-
顧客環境全体を継続的にハンティングして新興脅威を特定し、新しい検知ルールをリリースするPushのエージェント型検知パイプラインの活用
-
攻撃検知、新規インストールされたブラウザ拡張機能・新規導入アプリ、拡張機能の権限更新、ファイルのアップロード・ダウンロード、クリップボードアクティビティ、アプリログイン、認証情報の再利用、OAuthコンセントなど、多様なイベントのテレメトリをSIEMにストリーミング
-
ファイルのアップロード・ダウンロードのブロック
-
自分で定義した正規表現パターンによる、機密データのクリップボード貼り付けのブロック
-
ページのDOM要素、Webリクエスト・レスポンス、CookieなどのHTTPヘッダーを対象としたカスタムYAMLルールの作成
セキュリティチームは、AIを活用した攻撃の阻止とAI利用のガバナンスのどちらかを選ぶ必要はありません。それぞれ半分しか見えない二つのツールにコストをかける必要もありません。
