ホーム / Critical Brief / No. 059

AI ツールに渡した「すべて許可」の OAuth が、ベンダー侵害でそのまま侵入経路になった

標準的に付与される広範・永続の OAuth が、行動ごとにスコープ・検証されない構造（Vercel / Context.ai）

Pillar 03 · エージェント権限証明 エージェント基盤 認証・認可属性証明バイパス
事案日
2026-04-19
公開日
2026-06-16
発行
Lemma Critical Team
関連 Pack
Pack AIncident Response

TL;DR

AI 生産性ツールを使い始めるとき、「あなたのメール・ドキュメント・カレンダーへのアクセスを許可しますか」という画面で「すべて許可」を押す——その一手が、押した本人の権限を、まるごとそのツールのベンダーへ（そして将来そのベンダーを侵害する攻撃者へ）渡すことになる。2026 年 4 月 19 日、Vercel は社内システムと一部顧客の認証情報への不正アクセスを開示した。発端は、同社従業員が AI エージェント基盤 Context.ai に企業 Google Workspace アカウントへの広範な OAuth を「すべて許可」で付与していたことにある。Context.ai 側が 2 月に infostealer（Lumma Stealer）に侵害され、3 月に攻撃者が OAuth トークンを掌握、4 月にそのトークンで Vercel 従業員の Workspace を経由して社内環境変数管理画面に到達した。読み取り可能なまま保存されていた環境変数（API 鍵・DB 認証情報）が露出し、ShinyHunters を名乗る攻撃者が BreachForums で約 580 名分の従業員記録を提示し、データを 200 万ドルで販売すると主張した。本事象は Pillar 03（エージェント権限証明）の agent-infrastructure における、AI ツールに付与される広範・永続の OAuth が、行動ごとにスコープ・認可・検証されないまま「立ったままの権限」として存在し続ける構造を示す事例であり、Brief 029（過剰スコープ OAuth トークンの窃取）・033（位置的信頼と保存認証情報による横展開）・047（送信者検証前にエージェントが動く）・006（資格情報の失効属性の検証ギャップ）に連なる。

事案概要

  • 開示: 2026-04-19、Vercel が社内システムおよび限定的な顧客認証情報への不正アクセスを開示（CEO Guillermo Rauch が同日 X で攻撃連鎖を説明）
  • 根本原因: 第三者 AI エージェント基盤 Context.ai の侵害。少なくとも 1 名の Vercel 従業員が、自身の企業 Google Workspace アカウントに対し Context.ai へ広範な OAuth 権限（「すべて許可」、Google Drive への full read を含む）を付与していた
  • Context.ai の性質: 40 以上の企業ツールに OAuth/API で接続し、組織データを処理してコンテンツを生成するエンタープライズ AI 基盤。製品の価値提案そのものが、企業 ID 基盤への広範なアクセスを前提とする（設計上、高権限の第三者）
  • 到達対象: Vercel のプロジェクト設定および環境変数管理画面。攻撃者は「sensitive」に分類されていない（=読み取り可能な形式で保存された）環境変数にアクセスした。「sensitive」指定の変数は UI からの取得を防ぐ暗号化が施されており、Vercel はそれらへのアクセスの証拠はないとしている。到達はチームスコープ単位で、プラットフォーム全体の一括露出ではない
  • 攻撃者の主張: ShinyHunters を名乗る攻撃者が 2026-04-19 頃に BreachForums へ投稿。内部 DB・API 鍵・GitHub/NPM トークン・ソースコード等を含むとし、証拠として約 580 名分の Vercel 従業員記録（氏名・メール・アカウント状態・活動タイムスタンプ）を提示、データを 200 万ドルで販売すると主張した。なお ShinyHunters は関与を否定しており（模倣または分派の可能性、技術的裏付けはなし）、Vercel は調査中で主張の全範囲は独立検証していない

タイムライン

  • 2026-02: Context.ai 従業員が Lumma Stealer に感染（Hudson Rock によれば感染経路は同従業員による Roblox 関連スクリプト/ツールの個人ダウンロード）。Google Workspace・Supabase・Datadog・Authkit 等の認証情報が窃取され、Context.ai 自身の OAuth アプリ管理環境への管理者アクセスを含んでいた
  • 2026-03: Context.ai が AWS 環境への不正アクセスと、一部利用者の OAuth トークン侵害の可能性を後に開示。「すべて許可」で付与された OAuth アプリの認可基盤を攻撃者が掌握し、同意済みユーザーに代わって有効なトークンを生成・再利用しうる状態に
  • 2026-04: 攻撃者が侵害トークンで Vercel 従業員の Google Workspace を経由し、社内環境変数管理画面に到達
  • 2026-04-19: Vercel が公開開示。ShinyHunters を名乗る攻撃者が BreachForums に投稿、200 万ドルでの販売を主張

注: Context.ai 内部の感染経路・トークン掌握の詳細、および BreachForums のデータ主張の真偽は調査の進行に依存するため、本文では断定しない。

攻撃の経路：三段のサプライチェーン・エスカレーション

本事象は、AI ツールへ付与された広範・永続の OAuth が、ベンダー側の侵害を起点に下流へ連鎖する構造を示す。経路は明確な三段のホップを踏む。

  1. 第 1 ホップ — AI ベンダーのエンドポイント侵害: Context.ai 従業員が infostealer に感染。Google Workspace を含む複数の認証情報と、Context.ai の OAuth アプリ管理環境への管理者アクセスが窃取される
  2. 第 2 ホップ — OAuth トークンの掌握: 攻撃者が Context.ai の AWS 環境と OAuth 認可基盤を掌握。「すべて許可」で同意したユーザーに代わり、有効な OAuth トークンを生成・再利用できる状態になる。トークンはパスワード再入力を要さない、立ったままの（standing）アクセスを意味する
  3. 第 3 ホップ — 下流 Vercel への横展開: Vercel 従業員が Context.ai に企業 Workspace を広範な OAuth で接続していたため、攻撃者はそのトークンで従業員の Workspace ID を経由し、Vercel 社内システムへ。プロジェクト設定の環境変数管理画面に到達し、「sensitive」未指定で読み取り可能な API 鍵・DB 認証情報を取得した

補助的な要因として、シークレット分類の落差がある。Vercel の「sensitive 環境変数」指定はビルド実行時のみ読める暗号化を施すが、これはオプトインであり、既定では環境変数値は読み取り可能な形式で保存される。顧客が事前に「sensitive」を指定していなければ、プロジェクト権限を得た者——OAuth トークン侵害で到達した攻撃者を含む——に値が読まれる。Vercel は現在、本番/プレビュー環境の新規変数を既定で sensitive にするチーム方針をサポートしている。

構造的論点

本事象は Pillar 03（エージェント権限証明）の agent-infrastructure カテゴリに属する。中心的な失敗 primitive は、AI ツールに付与される OAuth が、行動ごとにスコープ・認可・検証される「動的な権限」ではなく、広範かつ永続の「立ったままの権限（standing authority）」として存在し続ける点にある。AI 生産性ツールは、その機能要件（メール・ドキュメント・社内ナレッジの横断的な読み書き）ゆえに、構造的に広範な OAuth スコープを要求する。ユーザーが企業 ID でそれを認可した瞬間、自分のアクセス姿勢をベンダーのインフラへ——そして将来そのベンダーを侵害する攻撃者へ——延長することになる。secondary に identity-auth（委任された権限の認可）と attribute-proof-bypass（権限属性の独立検証不在）を併記する。

Brief 029（github.dev で過剰スコープの OAuth トークンが窃取された）と同じく、「トークンが行為の範囲にスコープされていない」構造である。029 が単一サービス内の過剰スコープだったのに対し、本事象は AI ツールという高権限の第三者を経由した、組織横断の standing token という別軸を加える。また Brief 033（F5 BIG-IP）が示した「位置的信頼＋保存された認証情報による横展開」と同型の問題が、ここではネットワーク機器ではなく AI SaaS 連携の OAuth 信頼面で再現している。共通するのは、ある主体のアクセスが、その都度の認可ではなく、過去に一度与えられた広範な信頼に依存していることだ。

AI ツールへの OAuth 付与は、調達時のベンダーリスク評価が詳細でも、OAuth 同意画面そのものは「日常的なオンボーディングの一手」として素通りされがちで、評価プロセスを迂回する ID ブリッジを作り出す。権限を与えた従業員が、雇用主に代わってその水準のアクセスを付与する権限を持っていたとは限らない。

検出と証明の落差

infostealer インテリジェンスフィード、OAuth 付与の監査、egress 監視、EDR は、本事案の各段で機能しうる層であり、本 Brief がそれらの役割を否定するものではない。実際、Hudson Rock は Context.ai 従業員の認証情報を公開開示の 1 か月以上前に自社フィードで特定していた。検出能力は存在した。

一方で、検出は「いまこのトークンで行われているアクセスが、本来の認可の範囲内か」を、アクセスの実行前に独立して立証する材料にはならない。攻撃者の操作は、同意済みユーザーに代わって発行された有効な OAuth トークンによる、形式上は正規のアクセスである。Workspace から Vercel への横展開も、付与済みの広範スコープの内側で起きるため、トークンの有効性検査では止まらない。Hudson Rock の事例が示すのは、欠けていたのが検出能力ではなく、インテリジェンスを「立ったままの権限の即時失効」へ接続するワークフローだったことだ。監査の観点でも、事後に「どのトークンが・どの認可の範囲で・どの行動を実行したか」を独立に示す証跡は、各サービスのアクセスログの突合以上には残りにくい。

事前証明（pre-execution attestation）は、AI ツールへの権限付与を「広範・永続の同意」ではなく、行動ごとにスコープされ独立検証可能な認可として扱う設計を採る（業界の標準化文脈でも、ユーザー OAuth のパススルーを避け、RFC 8693 のトークン交換で操作ごとにスコープされた・監査可能なトークンへ変換する方向が示されている）。proof が「この操作は付与者の認可の範囲内であり、現に有効である」ことを満たさなければ、アクセスは実行前に block される。検出と事前証明の関係は 「AI 時代のサイバー防衛に残された、最後の層」（Lemma、2026-05）を参照。

対応経緯と業界動向

  • Vercel: 4 月 19 日に開示し調査を継続。顧客に対し、活動ログの確認、シークレットの「sensitive」指定への即時移行、非 sensitive な値のローテーションを推奨。本番/プレビュー環境の新規変数を既定で sensitive にするチーム方針を提供
  • AI SaaS 連携の OAuth 監査: Google Workspace 管理コンソールで第三者 OAuth アプリの広範スコープ付与を棚卸しし、IT 管理外で従業員が個別に認可したアプリを優先的に見直す動きが推奨されている。広範スコープの付与は失効・再プロビジョニング（必要最小限のスコープでの再付与）の対象
  • 認証情報の運用: deploy 環境の長期間有効な静的シークレットを、AWS IAM ロール・GitHub OIDC フェデレーション・実行時取得のシークレットマネージャ等の時間/スコープ限定の認証情報へ置き換える方向。単一トークン窃取の被害範囲を構造的に狭める
  • 業界横断の論点: 本事案は、infostealer 感染 → OAuth トークン侵害 → 下流顧客への横展開という反復可能なパターンの一例であり（2024 年の Snowflake キャンペーンと構造的に同型）、AI 生産性ツールの広範・永続アクセスを、従来のクラウド事業者と同等のリスク区分で扱う必要性が論点になっている

AI ツールへの OAuth 付与を「立ったままの権限」ではなく「監視され失効可能な、行動ごとにスコープされた認可」として扱う設計の不在は、特定ベンダーの問題ではなく、AI SaaS を採用する組織横断の運用課題として残っている。

Lemma による分析

本事象で露呈した検出と証明の落差（AI ツールへの広範・永続の OAuth が、行動ごとにスコープ・認可・検証されないまま立ったままの権限として存在する）に対して、Lemma は、ツールやエージェントの行動を「鍵の提示」ではなく「行動ごとにスコープされ独立検証可能な認可の証明」として裏づける設計を提示している。付与時の広範な同意ではなく、操作の実行前に「この行動は付与者の認可の範囲内か」「その認可は現に有効か」を証明として検証することで、ベンダー侵害が standing token を経由してそのまま下流の侵入権限に転化する連鎖を断つ。エージェント権限証明の設計思想は Pillar 03 — エージェント権限証明 を参照のこと。

Sources

Brief 配布について

Lemma Critical Brief は Lemma が発行する脅威インテリジェンス・ブリーフです。本資料は公開情報の構造化分析であり、特定の組織への監査・診断・推奨ではありません。意思決定の参考として用いる場合は、貴組織の Lemma Critical 担当に直接ご相談ください。

Discovery Call → ホワイトペーパー → ✉️ ニュースレター →

(c) 2026 FRAME00, INC. — Built for decisions that matter.

関連 Brief
エージェント基盤の全 20 件を見る
No. 064 · 2026-06-16

信頼された連携アプリの OAuth トークンが盗まれ、数百の Salesforce 環境が横断照会された（Salesloft Drift）

広範・永続の OAuth が、行動ごとにスコープ・失効検証されない構造（UNC6395）

エージェント基盤 認証・認可属性証明バイパス
Brief →
No. 062 · 2026-06-16

AI コーディングエージェントが、`[bot]` を名乗る 1 件の issue を信頼して特権実行した（Claude Code GitHub Action）

エージェントの起動者の権限と入力の出所が、実行の前に独立検証されない構造（GMO Flatt Security）

エージェント基盤 認証・認可AI 判断の完全性
Brief →
No. 058 · 2026-06-16

AI エージェントが自分の記憶（チェックポイント）を検証せず読み込み、サーバーを乗っ取られた

エージェントの永続状態が、ロードの前に来歴も完全性も独立検証されない構造（LangGraph）

エージェント基盤 認証・認可AI 判断の完全性
Brief →
No. 037 · 2026-06-09

AI コーディングエージェントが、リポジトリ同梱の設定ファイルを無検証で自動実行した

承認プロンプトや署名検査では届かない、エージェントの権限・来歴の落差

エージェント基盤 認証・認可
Brief →
No. 029 · 2026-06-06

github.dev で OAuth トークンが 1 クリックで窃取された

webview が合成イベントを信頼し、トークンは閲覧リポジトリにスコープされていなかった

エージェント基盤 認証・認可
Brief →
No. 027 · 2026-06-05

ユーザー指定の MCP URL からサーバーの秘密情報が漏れた（LibreChat）

2026 年 6 月 2 日、マルチプロバイダ対応の AI チャット基盤 LibreChat に CVE-2026-32625(CVSS 9.6、Critical)が公開された。0.8.3 以前の MCP サーバー統合は、ユーザーが指定する…

エージェント基盤 認証・認可
Brief →

Lemma Critical Monthly

実際に起きたリスク事案の構造分析(Critical Brief)を軸に、検出の先に必要な「証明」への視点を月 1 回お届け。

ニュースレターを購読
Cite this Brief

この Brief を引用する

Lemma Critical Team. (2026).
"AI ツールに渡した「すべて許可」の OAuth が、ベンダー侵害でそのまま侵入経路になった — 標準的に付与される広範・永続の OAuth が、行動ごとにスコープ・検証されない構造（Vercel / Context.ai）".
Lemma Critical Brief No.059. Lemma / FRAME00, Inc.
https://lemma.frame00.com/ja/critical/briefs/059-vercel-contextai-oauth/