7月3日、Unixi CTO・共同創業者のReuvein Vinokurovが「The Anatomy of a Shadow AI Supply-Chain Breach: Lessons from the 2026 Vercel Incident」と題した記事を公開した。この記事では、従業員が未審査のAIツールを業務利用したことを起点に発生した2026年4月のVercelサプライチェーン侵害の攻撃構造と、その対策について詳しく解説されている。
攻撃の起点は「ゼロデイ」ではなく「OAuth連携」だった
2026年4月に発生したVercelのセキュリティインシデントは、ゼロデイ脆弱性の悪用でも、クラウドの設定ミスでもなく、従業員が個人の判断で導入した未審査のAIツールから始まった。
Vercelの高権限開発者が、Context.aiというAIベンダーのコンシューマー向けツールを業務生産性目的で試用し、企業のGoogle Workspaceアカウントで認証・エージェントをインストールした。このとき、企業としての契約も、セキュリティ審査も一切行われていなかった。
その後、Context.ai側の従業員がLumma Stealerマルウェアを含む不正スクリプトをダウンロード。マルウェアはブラウザに保存されたOAuthトークン（※）やセッションCookieを窃取した。攻撃者はそのデータベースからVercel従業員のOAuthトークンを抽出し、Vercelの社内環境への侵入を果たした。
※ OAuthトークン：サービス間の認可を委任するベアラー（Bearer）資格情報。保持しているだけでAPIを呼び出せるため、パスワードや多要素認証（MFA）を迂回できる。
攻撃チェーンの全体像
攻撃の流れをMITRE ATT&CKのマッピングとともに整理すると以下のとおりだ。
| フェーズ | 手法 | 内容 |
|---|---|---|
| 初期侵害 | マルウェア実行（T1204.002） | ベンダー端末でInfostealerが実行 |
| 信頼関係の悪用 | Trusted Relationship（T1199） | 未管理のAIアプリブリッジを経由 |
| 認証情報取得 | OAuthトークン窃取（T1528） | ベアラートークンをDBから抽出 |
| 横移動 | 正規クラウドアカウント利用（T1078.004） | 開発者の企業アカウントに侵入 |
| 探索・収集 | 環境変数の列挙（T1213） | 暗号化されていない環境変数を読み取り |
| 影響 | 恐喝（T1657） | BreachForumsで200万ドルの恐喝要求 |
攻撃者はShinyHuntersの名義でBreachForumsに投稿し、コードリポジトリへの広範な侵害を主張したが、Vercelの公式調査ではコアコードベースへのアクセスは確認されず、被害は「sensitiveマーク」のついていない顧客の環境変数の流出に限定されたと報告されている。デフォルト設定で環境変数が暗号化されていなかった点が、被害拡大の要因となった。
表の各フェーズを通じて際立つのは、攻撃のどのステップにも「脆弱性の悪用」が存在しないという点だ。すべてのアクションが正規の認証フローの上で完結しており、従来型のEDRやSIEMが異常として検知しにくい構造になっている。Trusted Relationshipの悪用（T1199）とOAuthトークン窃取（T1528）の組み合わせは、ベンダーチェーンを経由するサプライチェーン攻撃の典型的なパターンとして近年増加傾向にある。
なぜ従来のセキュリティ対策では防げないのか
この種の攻撃が厄介なのは、既存のIDセキュリティの枠組みの外側で発生する点だ。
会議の議事録作成や文書要約といったAI生産性ツールは、機能を提供するためにMail.ReadやFiles.Read.Allといった広範なOAuthスコープを要求する。従業員が「すべて許可」をクリックした瞬間、企業データ層への恒久的・無監視のブリッジが生成される。
定期的な事後OAuthレビューは、ブリッジが確立・悪用された後にしかリスクを検出できない。対策としてこの記事が提唱するのは、ブラウザレベルでのインラインOAuthガバナンスだ。
具体的には以下のようなフローになる：
- 従業員が未審査のAI拡張機能にサインインしようとした時点でシステムが検知
- 対象ドメインを承認済みアプリケーションレジストリと照合し、未登録なら「シャドー利用」として分類
- 広範なワークスペーススコープを要求している場合、リスクエンジンが高リスクと判定
- 「すべて許可」をクリックする前に認証ワークフローを自動ブロック
このステップ3が機能していれば、OAuthトークンそのものが生成されず、上流ベンダーが侵害されても下流への侵入経路が存在しない状態になる。言い換えれば、Context.ai側の端末でInfostealerが実行されたとしても、Vercel従業員のトークンが存在しなければ攻撃チェーンはそこで完全に断ち切られていた。従来のゼロトラスト設計が「認証された通信を検査する」アプローチをとるのに対し、このモデルは「認証の発生前にリスクを評価する」という点で一段階手前に防御ラインを引く発想だ。
「シャドーAI」が「シャドーIT」より危険な理由
シャドーIT（未承認ソフトウェアの業務利用）はかつてから課題とされてきたが、シャドーAIは特有のリスクを持つ。AIツールが求める権限の広さが、従来のSaaSツールと比較にならないためだ。
コーディングアシスタントや会議要約ツールがGitHubやGoogle Workspace、Slackと連携するには、事実上その環境への読み取り権限のほぼ全てを必要とする。さらにMCP（Model Context Protocol）やブラウザ拡張機能経由での接続が普及するにつれ、この問題は構造的に悪化する。MCPはAIエージェントが外部ツールやデータソースと標準化されたインターフェースで通信するためのプロトコルであり、利便性の高さゆえに広範なシステムアクセス権を持つ接続が容易に生まれやすい。
Vinokurovは「セキュリティの境界はOAuth許可そのものに移行した」と結論付けており、シャドーAIの抑制は生産性の制限ではなく、サードパーティのアプリケーションへ信頼を委任する前に内部でその認可状態を検証するという原則に基づくべきだと主張している。この視点は、境界防御からID・認可管理への重心移動という、昨今のゼロトラストセキュリティの潮流とも一致している。
詳細はThe Anatomy of a Shadow AI Supply-Chain Breach: Lessons from the 2026 Vercel Incidentを参照していただきたい。
