AIアプリがGoogle Workspaceの信頼を現代的な攻撃チェーンへと変える

Google Workspaceのセキュリティは、より強力なパスワード、多要素認証、フィッシング対策の改善が長年進められてきたにもかかわらず、転換点を迎えている。セキュリティチームにとって最新のGoogleニュースは、攻撃者が直接盗む必要のないアクセスに関するものだ。攻撃者は、承認済みのAIアプリケーション、侵害されたブラウザセッション、あるいは放置されたOAuthトークンを通じて、そのアクセスを引き継ぐことができる。

この違いは、防御における課題を変える。従来、セキュリティプログラムはログイン画面で攻撃者を阻止することに重点を置いてきた。だが現代の攻撃は、Googleがすでに正当と見なしているアクセスから始まるケースが増えている。

AIツールは、有用な回答を提供し、アクションを実行するために広範な接続を必要とするため、この緊張をさらに深める。アシスタントはGmailを読み、Driveを検索し、Calendarを確認し、その結果を別のサービスへ転送するかもしれない。接続の一つひとつが、パスワード変更後も存続し、明確なユーザー操作なしに有効であり続ける信頼関係を生み出す。

ここから得られる直接的な教訓は、すべてのAIツールが悪意あるものだということではない。認可そのものが、エンタープライズの境界の一部になったということだ。BleepingComputerを通じて広まったMaterial Securityの最近の分析は、多くの組織が依然としてこれを管理上の背景ノイズとして扱っていると指摘する。

2026年4月のVercelインシデントは、こうした対応がもはや十分ではない理由を示している。侵害をめぐる開示によると、攻撃者はまずサードパーティのAIプロバイダーを侵害した。その後、その承認済み接続を利用して、Vercel従業員のGoogle Workspaceアカウントに到達した。

この攻撃は、誰かがVercelのログイン防御を突破したという従来のストーリーには当てはまらない。信頼は、ユーザーが以前に承認した統合を介して組織の境界を越えた。

Googleニュースの焦点は盗まれたパスワードから継承されたアクセスへ移る

重要な変化はGoogleの新たな脆弱性ではなく、正当なアクセスをより効果的に悪用する手法にある。

OAuthは、あるアプリケーションが別のサービス内の選択されたリソースにアクセスできるようにする認可フレームワークだ。たとえば、スケジューリングツールはユーザーのGoogleパスワードを受け取ることなく、カレンダーを読み取れる。

この分離には実際のセキュリティ上の利点がある。ユーザーは接続するすべてのサービスに認証情報を共有する必要がない。管理者はアプリケーションを制限し、要求されたスコープを確認し、付与を取り消すこともできる。

同じモデルが、価値の高い標的を生み出す。OAuthトークンは、すでに承認プロセスを通過した権限を表す。そのトークンを盗む、または制御する者は、付与されたスコープの範囲内で、承認済みアプリケーションを通じて行動できる。

Material SecurityのOAuthリスクレポートは、本番環境のGoogle Workspaceを調査し、大規模で分散した認可の攻撃対象領域を見いだした。公開された調査結果では、企業あたりのOAuthアプリケーション接続数の中央値は1,807件とされている。

同レポートは、観測された付与の47.2%が90日以上使用されていなかったとも述べる。これらの休眠状態の付与のうち、1,526件は依然としてGmailへのフルアクセスを保持していた。

これらの数字は、すべてのWorkspaceテナントを代表する国勢調査ではなく、セキュリティベンダーの顧客データセットに基づくものだ。企業規模、業界、既存のセキュリティ成熟度はいずれも合計値に影響し得る。それでも調査結果は、古い認可が事業上の目的を失った後も有効なままであるという構造的な問題を浮き彫りにしている。

AIの導入は、この蓄積を加速させる。MaterialはAIおよび自動化カテゴリで356の公開アプリケーションを分類した。分析対象の環境で、そのうち325件が2024年1月1日以降に初めて確認されたとしている。

つまり、観測されたAIアプリケーションの91%が16か月以内に登場したことになる。これらのアプリケーションの半数以上が、機密または制限付きのスコープを保持していたと報告されている。

スコープは、アプリケーションがアクセスまたは変更できる対象を定義する。広範なスコープは、アプリにメールの閲覧、Driveコンテンツの確認、メッセージ送信、情報削除を許可する場合がある。

したがって、組織は難しい分類の問題に直面する。Driveアクセスの要求は、有用なリサーチアシスタントを支える可能性がある。一方で、アプリケーションが侵害された場合、同じ権限が契約書、戦略文書、認証情報、顧客記録を露出させる可能性がある。

この脅威は、当初から悪意あるアプリケーションを必要としない。正規のプロバイダーであっても、従業員端末、開発者アカウント、署名鍵、またはクラウド環境が侵害された後には、侵入口となり得る。

この可能性は、日常的なアプリ承認をサプライチェーン上の意思決定へと変える。ユーザーには同意画面が表示されるが、組織はプロバイダーの将来的なセキュリティ障害を引き受けることになる。

侵害されたAIツール一つで二つのセキュリティ境界を越えられる

Vercelインシデントは、攻撃者が最終標的を直接攻撃する代わりに、AIベンダーを経由して侵入できることを示している。

Vercelは2026年4月、侵害されたサードパーティAIツールと従業員のGoogle Workspaceアカウントに関わるセキュリティインシデントを開示した。公開報道では、そのプロバイダーはContext.aiと特定された。

入手可能な開示によると、Vercelの従業員は企業アイデンティティを使用してContext.aiのAI Office Suiteを接続していた。この接続には、広範なGoogle Workspace権限が付与されていた。

その後、脅威アクターがContext.aiによって保持されていた関連アクセスを制御下に置いた。このアクセスは、従業員のWorkspaceアカウント、さらにVercelの内部システムへと至る経路を提供したと報じられている。

この一連の流れは、連結した二つのサプライチェーン上の露出を生み出した。Context.aiは自社の従業員アイデンティティとインフラストラクチャに依存していた。そしてVercelは、Context.aiのOAuthアプリケーションの完全性に依存していた。

独立系研究者は、Context.aiへの初期侵害をインフォスティーラー感染によるものとした。インフォスティーラーとは、パスワード、ブラウザCookie、トークン、その他の認証情報を収集するよう設計されたマルウェアである。

報道は、この感染をRobloxのエクスプロイトとして提示されたソフトウェアに結び付けている。ただし、初期侵害のすべての詳細がVercelによって独立して確認されたわけではない。

エンタープライズの計画にとってより重要なのは、Vercelが確認した内容だ。サードパーティアプリケーションの既存の認可が、攻撃者による従業員の企業Workspaceアカウントへの到達を助けた。

攻撃者は、機密指定されていない環境変数にアクセスしたと報じられている。Vercelは影響を受けた顧客に対し、アクティビティを監査し、露出した認証情報をローテーションするよう助言した。

当時の報道によると、攻撃者は盗んだデータに対する支払いを求めた。VercelはMandiantを起用し、法執行機関へ通知するとともに、影響を受けた限定的な顧客グループに連絡した。

Vercelはまた、機密性の高い環境変数は保存時に暗号化され、アクセスされなかったと述べた。Next.jsやTurbopackを含む同社のオープンソースプロジェクトも、影響を受けていないと報じられている。

このインシデントを、OAuth自体が失敗したとの主張に単純化すべきではない。OAuthは、ユーザーと管理者が許可した認可を実行した。

失敗は、信頼チェーン全体から生じた。プロバイダーが侵害され、アプリケーションが広範なアクセスを保持し、そのアクセスが価値の高いエンタープライズアイデンティティに到達した。

従来のログイン防御がカバーしていたのは、その連鎖の一部分にすぎない。利用可能な認可が存在すれば、攻撃者は元の同意判断を繰り返す必要がなかった。

パスワードを変更しても、一部のアプリケーション認可は維持される可能性がある。そのため、対応は認証情報のリセットとアクティブなブラウザセッションの終了よりも複雑になる。

チームは、どのトークンが存在するか、どのスコープを保持しているか、どの接続済みアプリケーションが依然として行動できるかを特定しなければならない。その後、必要な業務ワークフローを壊さずにアクセスを取り消す必要がある。

これが現代の攻撃チェーンにおける中心的な逆転だ。パスワード共有を減らすために設計されたアプリケーションが、パスワード中心の防御を迂回する永続的な経路になり得る。

AIエージェントは従来のOAuth記録の情報価値を下げる

AIエージェントは認可ログでは通常のように見えても、従来の統合よりはるかに予測しにくい振る舞いをする可能性がある。

従来のアプリケーションは、通常、限定的な機能セットを実行する。文書署名サービスであれば、ファイルを取得し、署名を集め、完成版を返すかもしれない。

その動作は変化し得るが、管理者は要求された権限を比較的安定した目的と照合できる。この種のサービスにとって過剰なGmailまたはCalendarアクセスは、不審に見えるはずだ。

AIエージェントは、同じ行動モデルに従わない。その次のアクションは、ユーザープロンプト、取得したコンテンツ、利用可能なツール、モデル出力、外部システムから与えられる指示に依存し得る。

認可レイヤーでは、こうした違いが見えなくなる可能性がある。AIアシスタントに付与された読み取り専用のDrive権限は、固定的な文書ユーティリティに付与されたものと似て見える場合がある。

Materialのエージェント分析は、セキュリティシグナルが付与から認可後の行動へ移行していると論じている。ベンダーのアイデンティティとスコープは依然として有用だが、汎用エージェントが実行するすべてを完全に記述することはできない。

一般にMCPと呼ばれるModel Context Protocolは、この不確実性を高める可能性がある。MCPは、AIシステムをツールや外部データソースと接続するための標準だ。

MCP接続されたエージェントは、Workspaceを検索し、選択したコンテンツを別のツールへ渡し、それを要約して、後続アクションを実行するかもしれない。一つのユーザー要求の中で、ワークフローが複数のサービスをまたぐ可能性がある。

これは、同意画面では答えられない複数のセキュリティ上の問いを生み出す。管理者は、エージェントが実際にどの情報へアクセスし、それをどこへ送信し、その活動がユーザーの意図に合っていたかを把握する必要がある。

プロンプトインジェクションが、さらに別の層を加える。プロンプトインジェクションは、信頼できないコンテンツがAIシステムの指示やツール利用を操作する際に発生する。

エージェントは、メール、共有ドキュメント、カレンダーエントリ、またはWebページの中で敵対的な指示に遭遇する可能性がある。そのコンテンツを指示として扱う場合、正当な権限そのものが有害な活動を実行する仕組みになり得る。

このリスクは、従来のマルウェアとは異なる。実行可能ファイルが必ずしもユーザーの端末に到達するわけではなく、AIプロバイダーが侵害されていない場合もある。

その代わりに、システムは敵対的なコンテンツを処理する過程で、有効なツールを誤用する可能性がある。セキュリティ制御は、承認済みの自動化と、危険な振る舞いをする承認済みの自動化を区別しなければならない。

これは、接続されたすべてのエージェントに対して、プロンプトやプライベートコンテンツの無制限な監視が必要だという意味ではない。過度な監視は、それ自体がプライバシー、コンプライアンス、ガバナンス上のリスクを生む。

組織に必要なのは、活動レベルの証拠である。有用なシグナルには、異常なダウンロード量、新たな転送動作、急速なメールボックス列挙、予期しないサービスの組み合わせ、ユーザーの通常パターン外でのアクセスなどが含まれる。

AIは、レビューを要する接続の数も増やす。従業員は、調達部門やセキュリティチームが評価する前に、アシスタントを直接導入できる場合が多い。

知名度のあるブランド名でも、同意画面に表示されるアプリケーションがそのブランドのものだとは限らない。Materialのレポートは、正規のGammaプレゼンテーションサービスに似た「gamma.com.ai」というアプリケーションについて説明している。

Materialによると、その発行者はGammaとは無関係で、複数のクライアント環境にまたがるアクセスを求めていた。レポートはこの事例を、視覚的な親しみやすさが承認を促すOAuthなりすましとして提示している。

認可画面には依然としてドメインと要求権限が表示されていた。人間の判断が失敗したのは、見慣れた名前によって精査が弱まったためだ。

この攻撃経路では、偽造されたパスワード入力ページは必要ない。ユーザーを誘導し、本来とは異なる相手に正当な認可を与えさせる。

MFAが保護するのはログインであり、その後のすべての判断ではない

多要素認証は依然として不可欠だが、ログイン成功後に続くすべてのトークン、アプリケーション、ブラウザ操作を検証できるわけではない。

MFAは、盗まれたパスワードだけでは不十分なため、多くのパスワードベースの攻撃を阻止する。パスキーやハードウェアセキュリティキーを含むフィッシング耐性のある手法は、リアルタイムの認証情報リレーに対してより強力な保護を提供する。

GoogleはWorkspace全体でパスキー対応と管理者向けコントロールを拡充している。これらの対策は、従来型のアカウント乗っ取りへの露出を抑える。

しかし、OAuthの同意は認証後に行われることが多い。ユーザーは正しくサインインし、MFAを完了したうえで、アプリケーションを承認する。

生成されたトークンには、認可済みの判断が記録される。そのトークンを再利用しても、同じ認証チャレンジが再び発生しない可能性がある。

ブラウザセッションの窃取も、これに関連するギャップを生む。セッションCookieは、サービスが以前に認証されたブラウザを識別するためのデータだ。

攻撃者が有効なCookieを盗めば、その認証済み状態を引き継げる可能性がある。Googleは、不審なセッションの調査と強制サインアウトのためのセッションCookie対応手順を文書化している。

アプリケーショントークンとブラウザセッションは同一ではない。どちらも、ログインイベントだけではセキュリティ境界全体を定義できないことを示している。

攻撃者は、AiTMとして知られる中間者攻撃型フィッシングも利用し、ライブの偽造セッションを通じて認証情報と第2要素をリレーする。この手法では、MFA成功後に生成された認証済みセッションを窃取できる。

フィッシング耐性のある認証は、認証情報が正規サイトに暗号学的に結び付けられているため、攻撃の難度を高める。それでも組織は、マルウェア、侵害されたアプリケーション、盗まれたトークンが別の侵入経路を作り得ることを前提にすべきだ。

Microsoftは、信頼されたIDプロバイダーURLを悪用するOAuthリダイレクト悪用を文書化している。これらのキャンペーンは、プロトコルパラメータや接続済みアプリケーションを操作し、被害者を攻撃者管理下の送信先へ誘導する。

この広範なパターンはGoogleに限らない。Microsoft 365、Salesforce、クラウド開発プラットフォーム、データサービスはいずれも、トークンとサードパーティ統合に依存している。

複数の大規模キャンペーンが、こうした関係を標的にしてきた。Salesloft Driftに関連するインシデントは、盗まれた統合トークンが顧客環境への下流アクセスを提供し得ることを示した。

この比較は重要だ。Google固有の説明を排除できるからである。エンタープライズソフトウェアは、委任された信頼のグラフとして動作する度合いを増している。

防御側はMFAを維持しつつ、モデルを拡張しなければならない。認証は、あるIDがログイン要件を満たしたかを問う。認可は、そのIDまたは接続されたアプリケーションがその後に何をできるかを問う。

セキュリティチームは永続性も考慮する必要がある。1つのブラウザセッションを無効化しても、アプリケーションの付与権限まで無効化されるとは限らない。ユーザーを停止しても、別途調査が必要な接続済みアクセスが残る場合がある。

インシデント対応計画には、こうした措置を明示的に列挙すべきだ。そうしなければ、チームはパスワードをリセットし、セッションを閉じて、アクセスが終了したと誤って結論付ける可能性がある。

この拡張された対応は、運用面で負荷が大きい。大規模組織では、数千件の付与権限、サービスアカウント、委任権限、自動化ワークフローが存在し得る。

すべてを無効化することは、長期的に信頼できる方針ではない。生産性を妨げ、従業員が可視性の低い代替手段を探すことを促してしまう。

防御可能な目標は、選択的な信頼だ。チームはアプリケーションを特定し、発行者を確認し、スコープを制限し、挙動を監視し、その目的が失効した時点でアクセスを削除すべきである。

トレードオフは有用なAIと測定されない信頼の間にある

すべての統合をブロックすれば、エンタープライズAIを有用にする接続済みワークフローを破壊することで、1つのリスクは減らせる。

AIアシスタントが一般的な応答を超えるには、コンテキストが必要だ。顧客向け更新情報を作成するアシスタントには、メール、会議メモ、アカウント履歴、プロジェクト文書が必要になる場合がある。

空のチャットウィンドウに限定すれば、露出は減る。しかし同時に、従業員がエンタープライズAIに期待する価値の大部分も失われる。

したがって組織が直面するのは、二者択一のセキュリティ判断ではなく、トレードオフである。有用なアクセスを許可しながら、認可が無期限に蓄積しないようにしなければならない。

最初のステップは可視化だ。管理者には、アプリケーション、付与権限、ユーザー、スコープ、発行者、最近のアクティビティを対象とするドメイン全体のインベントリが必要である。

インベントリでは、公開されたサードパーティアプリケーションと内部ツールを区別すべきだ。また、退職者、契約社員、テストアカウント、非アクティブなプロジェクトに紐づく付与権限も特定する必要がある。

名称だけを確認しても不十分だ。チームは、発行者のID、アプリケーションドメイン、リダイレクト先、要求されたスコープ、そのツールが関連するプラットフォーム検証を完了しているかを確認すべきである。

検証は恒久的な保証ではない。正規のプロバイダーでも、承認後に侵害、買収、変更される可能性がある。

スコープ制御はもう1つの層を提供する。アプリケーションには、明確に定義されたワークフローに必要な最小限の権限を付与すべきだ。

文字起こしサービスに、明確な要件なしでGmail全体へのアクセスを与えるべきではない。選択したDriveフォルダだけを検索するアシスタントに、すべてのファイルへのアクセスを自動的に与えるべきでもない。

時間も重要だ。評価のために付与したアクセスは、その評価終了後に失効させるべきである。組織は一時的な実験を恒久的な認証情報に変えないようにすべきだ。

Google管理者は、サードパーティアプリケーションのアクセスを制限し、サービスを信頼済み、制限付き、ブロック済みとして分類できる。こうしたコントロールは、従業員の速度に合わせて運用できる承認プロセスに支えられる場合に最も効果を発揮する。

数週間を要するレビュー制度は、導入を地下化させる。権限を調べずに知名度のある名前を承認する制度は、認可の無秩序な拡大を招く。

行動監視は、承認では予測できない事象に対応する。チームは、アプリケーションが突如としてはるかに多くのデータを読み取り、通常と異なるユーザーにアクセスし、新たな操作を始めた場合を検知すべきだ。

これはAIエージェントにとって特に重要である。その汎用的な能力により、静的な説明は期待される挙動を示す指標として弱くなる。

Cloud Security Allianceの研究は、AI SaaS OAuthチェーンをエンタープライズにおける体系的な攻撃対象領域として位置付けている。その信頼チェーン分析は、Context.aiインシデントを他の下流トークン侵害と結び付けている。

同レポートは、企業がOAuthライフサイクル管理を第一級のセキュリティ機能として扱うべきだと主張する。これには、発行、インベントリ、監視、ローテーション、無効化、インシデント対応が含まれる。

セキュリティチームは、ベンダー統計を引き続き慎重に扱うべきだ。MaterialはWorkspaceセキュリティ製品を販売しており、その調査は同社プラットフォームが対処する問題を裏付けている。

それでも、そのデータセットはあらゆる組織に検証可能な問いを提供する。管理者は、自組織の付与権限数、休眠中の割合、機微なスコープ、AIアプリケーションの増加、無効化のギャップを測定できる。

最も強力な対応は、その企業自身のテナントから収集した証拠である。ローカル監査により、報告されたパターンが当てはまるか、また最もリスクの高い接続がどこにあるかを確認できる。

セキュリティチームが次に注視すべきこと

Workspaceの防御がAI時代の認可に適応しているのか、それとも単に別のダッシュボードを追加しているだけなのかを示すシグナルは3つある。

最初のシグナルは、Googleとセキュリティベンダーによる、付与後の可視性向上である。管理者に必要なのは、アプリケーションが特定のスコープを受け取ったことを示す記録だけではない。

アプリケーションのその後の活動について、実用的な回答が必要である。これには、どのリソースにアクセスしたか、パターンがどう変化したか、データが接続済みサービス間を移動したかが含まれる。

Googleはすでに調査およびアクセス制御機能を提供しているが、カバレッジはエディション、設定、利用可能なテレメトリーに依存する。重要な検証点は、複数の無関係なコンソールから証拠を組み立てることなく、チームがAIエージェントの行動を追跡できるかどうかだ。

アクティビティレベルの調査がより明確になれば、ここで述べたセキュリティモデルは実用的な裏付けを得る。ログが初期同意を中心としたままであれば、防御側は動的なエージェントを静的なメタデータで判断し続けることになる。

2つ目のシグナルは、AIプロバイダーがどのように権限を狭め、管理するかである。成熟した製品は、各スコープが必要な理由を説明し、より小さな認可フットプリントでも有用なワークフローを提供すべきだ。

選択的なデータソース、実用的な範囲での短期間アクセス、迅速な無効化、ツール活動の透明な記録をサポートすべきである。また、ユーザー向け自動化と高リスクの管理操作を分離すべきだ。

広すぎるデフォルトスコープは、市場が最近のインシデントから学んでいるという主張を弱める。より粒度の細かいコントロールは、ベンダーが認可を製品設計上の問題として認識していることを示すだろう。

3つ目のシグナルは、組織が日常的なセキュリティ業務でOAuthの露出を測定するかどうかである。年1回のレビューでは、従業員がAIツールを導入する速度に対応できない。

チームは、休眠中の付与権限、新しい発行者、機微なスコープ、オフボーディング済みユーザー、アプリケーション挙動の急変を追跡すべきだ。こうした指標は、定期的なIDおよびクラウドセキュリティレビューに含めるべきである。

インシデント演習では、サードパーティトークンの侵害もテストすべきだ。対応者は、影響を受けたユーザーの特定、付与権限の無効化、セッションの終了、下流シークレットのローテーション、証拠の保全を行う方法を知っていなければならない。

最新のGoogleニュースは、Workspaceが本質的に安全でなくなったことを示すものではない。ログイン保護を前提に構築されたセキュリティ上の想定が、エンタープライズデータに至る経路全体をもはやカバーしていないことを示している。

パスワードとMFAは依然として必要である。ただし、従業員がメール、ファイル、カレンダー、接続済みシステム全体でアプリケーションが行動することを認可した時点で、それらは最終的なコントロールではなくなる。

より難しい問いは、有用な業務を妨げずに、組織がその委任された活動を可視化し統制できるかどうかである。セキュリティリーダーは、直接的な測定から始めるべきだ。現在、何件の接続済みアプリケーションが会社データにアクセスでき、それぞれの判断を今も誰が所有しているのか。