この2ヶ月、私はVercelの侵害とComposioの侵害についてそれぞれ個別に記事を書いてきました。どちらも単独で学べる教訓があります。しかし両者を合わせて読むと、いつも同じ観察に行き着きます。これらは孤立した事件ではないのです。同一の攻撃が異なる標的に対して2度実行されたものであり、いずれもメールが侵入口ではありませんでした。そしてこのパターンをはっきりと見て取れるようになると、何を防御すべきかという考え方そのものが変わってきます。
また、私がずっと考え続けている、居心地の悪い疑問も浮かび上がります。ここで説明しているパターン——OAuth権限を使ってアカウントにアクセスし、メールやDriveから機密データを読み取り、そのアクセス権を使ってワークスペースの先へと進む、というパターンは、攻撃者の行動だけを表しているわけではありません。それは、AIエージェントが日々、設計通りに行っていることをますます正確に表すようになっているのです。
その議論に入る前に、まずワークスペースの攻撃チェーンを整理しておきましょう。
従来のメンタルモデル:危険はメールにあるという発想
この10年ほどの間、ワークスペースセキュリティにおいて支配的だったメンタルモデルは、おおよそ次のようなものでした。メールは危険な経路であり、Google Workspaceのそれ以外の部分は比較的安全だ、という考え方です。
攻撃者が主にフィッシングを通じて認証情報を盗もうとしていた時代には、このモデルは理にかなっていました。しかし今ではもはや通用しません。攻撃者は受信箱から侵入するだけでなく、ワークスペース内を次々と連鎖的にたどっていく術を身につけたからです。
多くのセキュリティチームにとって馴染み深いモデルは、次のようなものです。
- メールが侵入口: 悪意あるメール(フィッシングリンク、武器化された添付ファイル、説得力のある口実、AIエージェントを誤誘導するために仕組まれたプロンプトなど)が、ほとんどの攻撃の出発点です。
- 認証情報が盗まれる: 攻撃の結果、有効な認証情報が盗まれ、アカウント乗っ取りが発生します。
- GmailとDriveの機密データへのアクセス: 乗っ取りが起きると、攻撃者はGoogle Workspace内の連携アプリへ容易に飛び移ります。
- 横方向への展開: 受信箱の中に入り込んだ攻撃者は、パスワードをリセットしたり、マジックリンク経由で別のアプリにアクセスしたりできます。
- 永続化の確立: 攻撃者は検知されないままアカウント内に何日も、何週間も、何ヶ月も潜み、複数のシステムをまたいで静かにデータを窃取し続けます。
これらを総合すると、一般に広く認識されている悪夢のシナリオ、すなわちアカウント乗っ取り(ATO)が浮かび上がります。ワークスペースの攻撃チェーンは、メール経由のID侵害から始まり、そこから拡大していくのです。
進化する攻撃チェーン:OAuthが侵入口になる
ワークスペース攻撃チェーンを構成する要素自体は変わっていませんが、攻撃が展開される順序は進化しています。私がVercel、Composio、そして現在追跡中の増加しつつあるインシデント群で目にしてきた一連の流れは、そもそもメールから始まりません。代わりに筋書きが逆転し、OAuthトークンがメールへの侵入口となるのです。その逆ではありません。
これらの攻撃は次のような形をとっていました。
- OAuthが侵入口: これらの攻撃は、盗まれたOAuthトークンを通じて永続性を確立することから始まりました。こうしたトークンはパスワードリセットを生き延び、有効期限がなく、観測が困難です。ユーザーからは見えず、アプリの挙動を監視していないセキュリティチームからもほとんど見えません。さらに恐ろしいことに、盗まれたトークンはサプライチェーン攻撃そのものです。サプライヤーが侵害され、その結果としてあなたの環境へのアクセスが生まれるのです。
- 機密データへのアクセス: 盗んだトークンを使い、攻撃者はGmailとDriveに保存されたデータにアクセスできました。
- メールアカウントの乗っ取り: ATOはメールではなくOAuthを使って最初に実行されます。メールへのアクセスによって、侵害された受信箱が、はるかに広範なインシデントへと転化するのです。
- 横方向への展開: Driveに保存された認証情報と、メール経由のパスワードリセットやマジックリンクを組み合わせることで、攻撃者は連携するシステム間を横方向に移動できます。
ワークスペース攻撃チェーンを構成する要素そのものは今後も一貫していると予想されますが、脆弱性を探り出し攻撃を拡大するためのAIツールを備えた攻撃者は、それらの要素を組み合わせ直す新たな方法を見つけ続けるでしょう。こうしたOAuth中心の攻撃は、その進化の一例にすぎません。
同じ攻撃チェーン、異なる行為主体
ここで、先ほど説明した4段階の流れを念頭に置きつつ、視点を切り替えてみましょう。
あなたの組織の従業員は、今この瞬間もAIエージェントをGoogle Workspaceに接続しています。それらのエージェントは権限を与えられており、正当なOAuth権限を使用しています。メールを読み、Driveを検索し、実際のユーザーに代わって実際の業務を行っています。ほとんどの組織では、これはセキュリティチームが把握できる速度を上回るペースで進行しています。
AIエージェントが予期せぬ振る舞いをするとき——指示が曖昧だったため、開発者が想定していなかった推論の連鎖をたどったため、あるいは環境内で遭遇したコンテンツを通じてプロンプトを与えられたため——そのエージェントは攻撃者とまったく同じ経路をたどりかねません。
- タスクに必要な範囲を超えて権限のスコープが広すぎたために、本来到達すべきではなかった受信箱やDriveフォルダにアクセスしてしまいます。
- メールスレッド内の認証情報や共有ドライブ内の機密文書といった機密コンテンツを読み取り、その情報を利用してしまいます。
- そのアクセスの延長線上で、メッセージの送信、リンクのクリック、別サービスへのリクエスト送信といった行動を取ります。
- アプリケーション間を横方向に移動し、機密情報が最終的に第三者へと流出してしまいます。
悪意ある行為者はいません。侵害された認証情報もありません。あるのは、それを止めるための統制が備わっていない環境の中で、運用者が意図していなかった行動をエージェントが取ってしまう、という状況だけです。
この視点が防御戦略にとって重要な理由
AIエージェントのセキュリティをめぐる議論の多くは、プロンプトインジェクションの防止、エージェントの挙動に対するレッドチーム演習、従業員が接続しているアプリの点検といった枠組みで語られます。これらは現実の問題であり、取り組む価値があります。
しかし、私がここで説明している脅威は、エージェントが武器化されるという話ではありません。エージェントが本来設計されたとおりに正確に動作しているにもかかわらず、そのような行為主体を想定してガードレールが設計されていない環境が存在する、という話なのです。過剰に権限を与えられた環境で行動する人間の担当者であれば、一般的には常識や社内規範・ポリシーへの理解を組み合わせて、この状況をうまく乗り切る術を心得ています。AIエージェントに付与されたOAuthトークンは、人間に付与されたトークンと同じアクセス権を持ちますが、エージェント自身は行動を起こす前に自分が過剰な権限を与えられていることを理解していません。単に、タスクを実行するために必要なことを淡々とこなすだけなのです。
ここで重要な統制とは、エージェントそのものに対する統制ではありません。エージェントが動作する環境に対する統制です。
メールとDrive全体で機密データがどこに存在するかを把握していれば、エージェント(あるいは攻撃者)がそこに到達する前にアクセスを制限するポリシーを実施できます。OAuth権限を精査していれば、攻撃者や暴走したエージェントの詮索の目にさらされる範囲を理解し、制限できます。パスワードリセットリンクを編集(レダクト)し、機密性の高い受信箱コンテンツを読める状態にする前に段階的な本人確認を要求できれば、そのコンテンツにアクセスしようとしている主体が攻撃者であろうと、意図したスコープを逸脱したエージェントであろうと関係ありません。
現代の攻撃チェーンを防御する対策範囲は、現代のエージェントリスクを防御する対策範囲でもあります。両者は姿形を変えているだけで、同じ問題なのです。
チェーン全体を見据えた防御のあり方
この攻撃チェーンの各段階にポイントソリューションを追加していくことが答えだとは、私は思いません。答えは、チェーンをチェーンとして理解し、メール、OAuth、Drive、アカウントの挙動全体で何が起きているかを見渡し、事態が3段階目や4段階目で悪化する前に点と点を結びつけられる、包括的な対策範囲にあると考えています。
それこそが、私たちMaterialが構築してきたものです。私たちの対策範囲が各段階にどう対応するかをご紹介します。
初期メールペイロードのブロック。当社のメールセキュリティは、ネイティブの統制機能では見逃されるもの——巧妙なフィッシング、レピュテーションベースのフィルタを回避するペイロード、中間者攻撃(AiTM)技術——を捕捉するよう設計されています。最も一般的な攻撃手法を発生源で食い止めることは、悪意ある脅威に対する最もレバレッジの高い介入であり続けています。
不審なOAuthの挙動の検出。Materialは、どのようなアプリが存在し、どのようなスコープを保持しているかを単に一覧化するだけにとどまりません。当社のプラットフォームは、アプリが実際に何を行っているか——何を読み取り、いつ読み取り、その挙動が時間とともにどう変化するか——を監視します。OAuthトークンが攻撃者によって使われているのか、意図したパラメータの外側で動作しているAIエージェントによって使われているのかにかかわらず、アクティビティ層における異常な挙動が危険を浮かび上がらせます。
保存データにおける機密情報の検出と保護。見えないものは守れませんし、存在すら知らないアクセスに対してポリシーを設計することもできません。Materialのファイルセキュリティは、メールとDrive全体で機密データがどこに存在するかをチームに可視化します。どの共有ドライブが広範なアクセス権を持っているか、どのメールスレッドに認証情報や個人情報(PII)が含まれているか、どのDriveフォルダが本来意図された対象範囲を超えて公開されているか、といった具合です。これは、人間であれ自動化された主体であれ、あらゆる行為主体に対して最小権限アクセスを徹底するための基盤となります。
パスワードリセット経由の横移動のブロック。Materialは、パスワードリセットリンクを含む機密性の高いメッセージ内容を編集(レダクト)し、そのコンテンツにアクセス可能になる前に段階的な本人確認を要求できます。リセットリンクが平文で入手できなければ、受信箱へのアクセス権を持つ攻撃者はそれを足がかりとして利用できません。何かに対して行動を起こそうと受信箱に到達したAIエージェントも、同じ制限に直面します。
このパターンは繰り返される
Vercel。Composio。このリストは今後も伸び続けると予想されますし、次に加わる事例が必ずしも「外部の攻撃者」というカテゴリーにきれいに当てはまるとは限らないでしょう。中にはAIエージェントが予期しない行動を取るケースもあれば、本来アクセスすべきでなかったデータにまで到達してしまう、過剰な権限を持つ連携アプリが関わるケースもあるはずです。その背景にある物語が異なっていても、仕組みそのものは見覚えのあるものになるでしょう。
正しい対応は、AIエージェントに警戒心を抱くことでも、導入のペースを落とすことでもありません。エージェントは真に有用であり、生産性向上という観点での導入根拠は確かなものです。正しい対応とは、これらのエージェントが動作するワークスペースには、OAuthで認証されたソフトウェア(権限があろうとなかろうと)が環境内の一級の行為主体であるという世界にふさわしい統制が必要である、と認識することなのです。
翻訳元: https://www.helpnetsecurity.com/2026/09/16/material-google-workspace-attack-chains/
