Vercelの内部システムにサードパーティAIツールが密かにアクセス可能に

2026年4月19日、クラウド開発プラットフォームVercelがセキュリティインシデントを公表しました。これは、特定の内部システムへの不正アクセスが発生したものです。同社の公式発表とCEO Guillermo Rauch氏の続報では、2026年にすべてのCISOがSaaSサプライチェーンリスクを再考すべき攻撃チェーンが語られています。

主なポイント

1. 侵害の発端はVercelではなくAIツール。攻撃者はVercel社員が利用していたサードパーティAIプラットフォームContext.aiを侵害し、同プラットフォームのGoogle Workspace OAuthアプリを利用してVercelの内部システムへ侵入しました。
2. OAuthアプリは新たな「信頼された」IDプロバイダー経路。従業員が承認する「Googleでログイン」は、永続的なアクセスチャネルとなります。多くの組織はこれらを監査したことがありません。
3. 「非機密」環境変数が実際は非常に機密性が高かった。Vercelは現在、すべての非機密変数のローテーションを顧客に要請しています。攻撃者がこれらを列挙し、本来はより高い機密区分で管理すべきシークレットを抽出したためです。
4. サプライチェーンリスクはAIツール層に移行。過去18か月のAIツールブームにより、SaaS連携の承認基準が下がりました。攻撃者はこの動向を把握しています。
5. ベンダー侵害時、コントロールプレーンがポイントソリューションを凌駕。シークレットが統合されたガバナンス層で一元管理されていれば、ローテーションや影響範囲の封じ込め、証跡生成が数時間で完了します。

攻撃の発端はVercelではなく、Context.aiというVercel社員が自社知識でエージェントを構築するために利用していたサードパーティAIプラットフォームでした。Context.aiにはGoogle Workspace OAuthアプリ統合が展開レベルのスコープで付与されていました。Context.ai自体が侵害されると、攻撃者は社員のGoogle Workspaceアカウントへの特権的な足がかりを獲得し、そこからVercelの環境へと侵入しました。

侵入後、攻撃者はVercelのダッシュボード上で「機密」とマークされていない環境変数を列挙しましたが、その多くにはAPIキー、トークン、データベース認証情報、署名鍵などが含まれていました。Vercelは現在、これらのシークレットのローテーションを顧客に要請しています。これらは機密区分下位で管理されていましたが、攻撃者の列挙によってリスク対象となったためです。同社は、攻撃者について「極めて高度な技術力とVercelシステムへの詳細な知識を持つ」と評価しています。

これはVercel固有の話ではありません。2026年のSaaSサプライチェーン侵害の典型例です。中央のセキュリティチームが把握していないAIツール経由で初期アクセスが発生し、誰も監査していないOAuth権限を通じてラテラルムーブメントが行われ、影響はプラットフォーム上にシークレットを持つすべての下流顧客に波及します。Vercelインシデントは単なる一例であり、このパターン自体が教訓です。

クラウド開発・デプロイメントプラットフォームが高価値ターゲットとなる理由

クラウド開発やCI/CDプラットフォームは、攻撃者が一度認証情報を侵害すれば仕事が容易になるようなデータを集約しています。環境変数、デプロイトークン、リポジトリ連携、OAuth権限、ビルドアーティファクトなど、数千の下流顧客分が格納されています。プラットフォーム層での侵害は、それを利用するすべての組織の侵害につながります。

https://www.crowdstrike.com/en-us/global-threat-report/CrowdStrike 2026 Global Threat Reportでも、このパターンが2025〜2026年の主要トレンドとして記録されています。攻撃者はSaaSやCI/CD層を狙う傾向が強まっています。これらのプラットフォームはエンドポイントに比べて監視が不十分である一方、1回の侵害で得られる機密データ量はワークステーション単体よりも多いのです。同レポートでは、Salesloft/DriftのOAuthトークン窃取が同種攻撃の先例として挙げられ、npmのBeaverTailやShaiHuludキャンペーンもパッケージレジストリ経由のサプライチェーン侵害例として記録されています。

IBM 2026 X-Force Threat Intelligence Indexもこの傾向を具体的な数字で裏付けています。公開アプリケーションの脆弱性悪用から始まる攻撃が前年比44%増加しました。さらにVercel事例に関連して、IBMは2025年に約30万件のAIチャットボット認証情報が犯罪マーケットで売買されていたことを観測しています。AIプラットフォーム自体が認証情報ブローカー化すると、そこに紐づくすべてのOAuth権限が潜在的な攻撃経路となります。

世界経済フォーラム（WEF）Global Cybersecurity Outlook 2026は経営層の視点を加えています。サプライチェーン脆弱性は2年連続でCISOが最も懸念するサイバーリスクの第2位となっており、「継承リスク」（サードパーティのソフトウェア・ハードウェア・サービスの完全性を保証できないリスク）が現在サプライチェーン上位の懸念事項です。Vercelインシデントは、サードパーティAIツールのOAuth権限が誰にもレビューされていなかった場合の継承リスクの実例です。

AIツールが攻撃ベクトルとなる新たなパターンの拡大

約18か月前まで、SaaSサプライチェーン攻撃はCRMプラグイン、メールセキュリティツール、マーケティング自動化など、よく知られたベンダーカテゴリ経由で発生していました。Vercel事例は、攻撃対象が新たなカテゴリ—OAuthで企業IDプロバイダーと連携したAIプラットフォーム—に拡大したことを示しています。多くのセキュリティチームはまだこの領域のガバナンスを構築できていません。

問題の規模も明らかになっています。DTEX 2026 Insider Threat Report（Ponemon Instituteと共同作成）は、シャドーAIが過失型インサイダーインシデントの主因であり、インサイダーリスクの年間コストは1組織あたり1,950万ドルに上ると推計しています。注目すべきは、92%が生成AIによって従業員の情報共有方法が変化したと回答した一方で、AI利用をセキュリティ戦略に組み込んでいるのはわずか13%にとどまる点です。AI導入とAIガバナンスのギャップこそが、Context.aiが突いた、あるいはContext.aiを通じて突かれた隙間でした。

Kiteworks 2026 Data Security and Compliance Risk Forecast Reportは、ガバナンス面を定量化しています。AIシステムでパートナーがデータをどのように扱っているか可視化できている組織は36%に過ぎません。AIデータゲートウェイを中央集約しているのは43%、残り57%は分散・部分的・未整備です。また、30%がサードパーティAIベンダーのデータ取り扱いを最大のセキュリティ懸念としていますが、そのリスクの可視性は全業界で依然として低いままです。

独立した学術研究もエコシステム全体のリスクを裏付けています。2026年IEEE Symposium on Security and Privacyの調査では、1万以上の公開ウェブサイトで使われている17種類のサードパーティAIチャットボットプラグインのうち15種類が、信頼済みコンテンツと未信頼コンテンツの区別ができず間接的なプロンプトインジェクションを許容していることが判明しました。OpenAIエコシステムの14,904個のカスタムGPTを分析した別の調査では、95%以上が十分なセキュリティ対策を欠いていました。これらのツールはすべて、従業員によってOAuthスコープを付与される可能性があり、どの権限も新たなContext.aiとなり得ます。

「非機密」環境変数は実際は非機密ではなかった

Vercelの開示で最も示唆的なのは、分類の失敗です。Vercelは「機密」フラグを環境変数に付与することで、保存時に暗号化しダッシュボードからの閲覧を禁止できます。「機密」とされていない環境変数も暗号化はされていますが、認証済みセッションから値が取得できるため、侵害されたOAuth権限を通じて攻撃者もアクセス可能となります。

実際には「非機密」分類が利便性のためのデフォルトとなっていました。開発者はAPIキー、データベースURL、決済トークン、署名鍵などを非機密変数に保存していました。なぜなら、毎回「機密」に設定するのは手間だったからです。攻撃者はこのウィンドウ期間中にそれらの値を列挙しました。Vercelは現在、関連するすべてのシークレットが調査完了までリスクに晒されていると顧客に伝えています。

これは「機能選択」に見せかけたガバナンスの失敗です。分類システムが存在しても、デフォルトが「気にしない」であれば、分類は機能しません。Kiteworks 2026 Data Security and Compliance Risk Forecast Reportでも、AIガバナンス全体で同様の傾向が指摘されています。63%の組織はエージェント認可に目的制限がなく、33%はAI運用の監査証跡がありません。制御が存在しても、デフォルトが緩い場合、実際の攻撃者には通用しません。

この教訓はVercel以外にも当てはまります。ユーザーに機密区分を自己申告させるプラットフォーム—環境変数、ファイル共有権限、パートナーフォルダアクセス、AIプロンプト文脈—では、ほとんどの場合デフォルトが選択されます。デフォルトのセキュリティこそが唯一生き残るセキュリティです。「機密」へ明示的に昇格させる手間が必要なデフォルトは、エンジニアが急いでいるとき（つまり毎日）必ず失敗します。

コントロールプレーンの解決策：統合ガバナンスが被害範囲を封じ込める理由

Vercelインシデントは、セキュアなデータ交換におけるコントロールプレーンモデルの教科書的な論拠です。シークレットやファイル、メール、SFTP、マネージドファイル転送、ウェブフォーム、AI連携が10種類のツールに分散している場合、それぞれが独自のポリシーエンジン・監査ログ・OAuth連携を持つため、1件の侵害が10件のベンダーサポートチケットへと波及し、インシデント対応が1週間単位で長引きます。これらのデータ交換チャネルが1つのガバナンスプラットフォームに統合されていれば、対応は数時間で済み、証跡も一元化されます。

Kiteworksはこのアーキテクチャを基盤としています。Kiteworksプライベートデータネットワークは、メール、ファイル共有、SFTP、マネージドファイル転送、ウェブフォーム、API、AI連携を単一の強化された仮想アプライアンスに統合し、1つのポリシーエンジン、1つの統合監査ログ、1つのセキュリティ体制で管理します。Kiteworks Secure MCP ServerとAI Data Gatewayは、このガバナンス層をAIプラットフォーム自体にも拡張します。サードパーティAIツールがデータを要求する際は、OAuth 2.0で認証され、ロールベース・属性ベースアクセス制御で評価され、リアルタイムでログ記録され、Vercelで発生したような大量列挙を防ぐためレート制限されます。

アーキテクチャ上の意味は明確です。コントロールプレーンモデルでは、AIプラットフォーム用トークンはOSキーチェーンやGoogle Workspace OAuth権限に放置されず、強化された分離環境でリクエストごとにポリシー評価されます。下流システム向けの環境変数やシークレットもデフォルトで分類・統一管理され、10種類のクラウドコンソールにバラバラに送られることはありません。Context.aiのようなインシデント発生時も、統合監査ログにより「誰が・いつ・どのチャネルで・どのOAuthスコープでアクセスしたか」が数時間で特定できます。また、すべてのデータ交換経路が同じポリシーエンジンで管理されるため、被害範囲の封じ込めも1つのポリシー変更で完了します。

これはWEF Global Cybersecurity Outlook 2026が業界横断で「可視性の限定」をサプライチェーン最大のサイバーリスクと指摘する理由です。可視性はアーキテクチャの問題です。ツールが分断されていれば可視性も分断され、統合されていれば可視性も統合されます。Vercelインシデントは、可視性がスキャンやアンケートの問題ではなく、アーキテクチャの問題であることを再認識させます。

今週すべての組織が取るべきアクション

まず、Google WorkspaceとMicrosoft 365の全サードパーティOAuthアプリを棚卸ししてください。両IDプロバイダーからOAuthアプリレポートを抽出し、Drive、Gmail、カレンダー、管理ディレクトリなど機密スコープを持つすべてのアプリを特定しましょう。多くの組織はこのレポートを一度も実施したことがなく、リストは想定より長くなるはずです。高価値スコープはユーザー主導ではなく明示的な許可リストに移し、四半期ごとの見直しサイクルを設けてください。Vercelのインシデント対応プレイブック（GitHub公開）は具体的な手順の参考になります。

次に、非機密環境変数も証明されるまで機密扱いしてください。APIキー、データベース認証情報、決済トークン、署名鍵を含む環境変数は、デフォルトで最上位の機密区分で管理すべきです。Vercelの曝露期間（2026年4月1日〜20日）にSaaSプラットフォーム上で非機密区分だったシークレットはすべてローテーションし、その作業をより広範なシークレット衛生プログラムの基準としてください。

三つ目に、従業員が使うAIツールにはOAuthスコープ最小化を必須としてください。AIプラットフォームは必要以上に広いスコープ（例：カレンダー閲覧だけで良いのにGmail全権限、ユーザープロファイルだけで良いのに管理ディレクトリアクセス）を要求しがちです。ツールの機能説明を超えるスコープ要求は拒否し、ベンダーが理由を説明できない場合は連携自体をブロックしてください。

四つ目に、すべてのAI連携を自社のコンプライアンスフレームワーク下のデータ管理者として扱ってください。自社がHIPAA、GDPR、サイバーセキュリティ成熟度モデル認証、PCI DSSなど正式なデータ処理者契約が必要なフレームワークの対象であれば、OAuth経由でIDプロバイダーと連携したAIプラットフォームはデータ処理者です。ベンダー管理台帳に記載し、DPA（データ処理契約）下に置き、高リスクデータの場合はDPIA（データ保護影響評価）も実施してください。Kiteworks 2026 Data Security and Compliance Risk Forecast Reportによれば、89%の組織がパートナーと共同インシデント対応演習を一度も実施していません。初回が本番対応にならないようにしましょう。

五つ目に、データ交換の攻撃面を統合してください。メール、ファイル共有、マネージドファイル転送、ウェブフォーム、AI連携ごとにポイントツールを増やすたび、OAuth権限・監査ログ・ポリシーエンジン・被害範囲の断片が増えます。2026年の方向性はデータ交換の統合コントロールプレーン化です。なぜなら、攻撃者の方向性はまさに分断が生み出す隙間の悪用に向かっているからです。

Vercelインシデントは2026年のAIツール経由初期侵害の最後の事例にはなりません。最大規模でもありません。むしろ、セキュリティチームがAIプラットフォームを「たまたまOAuth連携がある生産性ツール」としてではなく、「静かにデータ管理者となっている存在」として扱い始める転換点となるべきです。