Vercel 2026年4月セキュリティインシデント完全解説｜AI エージェント時代の OAuth 脅威モデル
AI Beat（エーアイビート）編集部です。
2026 年 4 月、ホスティング基盤として広く採用されている Vercel が、サードパーティ統合に関連するセキュリティインシデントを公表しました。発端となったのは、Vercel 連携アプリの一つである Context AI が保持していた OAuth トークンが攻撃者に奪取され、Vercel の一部顧客プロジェクトへの不正アクセスに転用されたという報告です。
このインシデントが衝撃的だったのは、Vercel 本体のシステムが直接侵害されたわけではなく、AI エージェント側に預けられたトークンが侵害経路になった点にあります。AI エージェントを業務に組み込む企業が増えるなかで、認証情報をどこに置き、誰に渡すべきかという設計判断が、従来の SaaS 連携とは別次元の重要度を持つことを突きつけられた事例と言えます。
編集部としても、Computer Use や MCP server を活用したエージェント検証を重ねていますが、認証境界の曖昧さに肝を冷やす場面が増えています。実際にローカルで MCP server を試した際、開発端末上の credential が想定外のスコープでツールへ渡る挙動を確認し、本番運用に持ち込む前に設計を見直しました。
本記事では、Vercel の公式アナウンスと OAuth 関連の RFC、OWASP の Top 10 for LLM Applications を一次資料として整理しながら、Context AI 経由の侵害経路、MCP server や Computer Use 経由の認証奪取リスク、Vercel が打ち出した再発防止策、そして開発者と SaaS 提供者がいま実装すべき防御策 7 つまで踏み込んで解説します。
2026年4月 Vercel インシデントの概要
2026 年 4 月の Vercel インシデントとは、サードパーティ統合 Context AI の OAuth トークン漏えいに起因し、Vercel 顧客プロジェクトへの不正アクセスが発生した事象を指します。
発生から公表までのタイムライン
Vercel の公式セキュリティアナウンスによると、最初の異常検知は 2026 年 4 月の上旬で、特定 IP からの API 呼び出しパターンに不審な集中が観測されたところから始まりました。Vercel 側はトラフィックメタデータの相関分析で外部要因の関与を疑い、Context AI 側に連絡を取って侵害の有無を確認したと公表しています。
その後数日のうちに Context AI が自社環境の侵害を認め、漏えいしたトークンの失効と Vercel 側からの強制ローテーションが連携で行われました。Vercel は同月内にステータスページとセキュリティ通知の双方で詳細を公表し、影響範囲・対応・再発防止策を整理しています。
注目すべきは、Vercel 自身のシステム侵害ではなく 連携先の侵害が顧客環境に伝播した という構造を、Vercel が早期に明示した点です。ユーザーが取るべき行動を曖昧にせず、トークン再発行と監査ログ確認の必要性を即座に告知した姿勢は、SaaS 事業者として参考にしたい対応でした。
影響を受けた顧客と機能領域
Vercel の公表ベースでは、影響対象は Context AI 連携を有効にしていた一部顧客に限定されています。デプロイメント Webhook の起動、環境変数の参照、プロジェクト構成の読み取りといった、Context AI の権限スコープ範囲で実行可能な操作が侵害アクセスで観測されたと報告されました。
連携を有効化していなかった大多数の顧客は今回の事象の直接影響を受けていません。ただし「使っていない連携が、知らない誰かによって有効化されている」リスクは、認可フローの設計上どの SaaS でも起こり得ます。組織として連携アプリの棚卸しが必要になる契機ではあります。
コミュニティと業界の反応
X（旧 Twitter）や Hacker News では「AI エージェントに渡したトークンが新しい攻撃面になっている」「OAuth scope を最小化していなかった反省」「MCP server の認証境界をどう設計すべきか」という議論が連日盛り上がりました。AI エージェントを実運用に組み込む企業が増えたことで、認証情報の取り扱い設計が新たな共通課題として浮き彫りになっています。
セキュリティ研究者からは、今回の事象を「AI エージェント時代のサプライチェーン攻撃の典型例」と評する声も多く、従来のサプライチェーン攻撃に加えて新しい脅威モデルが必要だという指摘が広がりました。
Context AI 経由で認証が奪取された経路
このセクションでは、Vercel 公式アナウンスと Context AI 側の事後説明を突き合わせて、認証奪取の経路を技術的に整理します。
Context AI が保持していたトークンの性質
Vercel は OAuth 2.0 ベースの統合フレームワークを提供しており、サードパーティアプリは Vercel API を呼び出すために OAuth アクセストークンとリフレッシュトークンを保持します。Context AI は Vercel のデプロイ情報や環境変数をコンテキストとしてユーザーに提示する AI アシスタント機能を提供しており、その実現のために幅広い参照スコープのトークンを保持していました。
ここで重要なのは、Context AI のトークンが 長期保持される long-lived token であった点です。これは AI エージェントが継続的にコンテキストを取りに行く設計上、致し方ない側面もありますが、トークンが盗まれた瞬間から長時間にわたり攻撃者に有効なアクセス権を与えることを意味します。
攻撃者がトークンに到達した手口
Context AI 側の説明によると、開発者向けインフラの認証管理に使われていた内部システムへの不正アクセスが起点であり、そこから Vercel OAuth トークンを含む顧客接続情報の一部が抽出されたと報告されています。具体的な侵入手法は調査中の部分が含まれますが、外部公開された設定ミスと、内部認証情報のローテーション間隔が長かった点が問題視されています。
攻撃者は奪取したトークンを使って Vercel API を叩き、対象プロジェクトのメタデータや環境変数の取得を試みました。Vercel 側で観測された不審なアクセスパターンは、この自動化された API 呼び出しに由来するものです。
通知から封じ込めまでのフロー
Vercel と Context AI は侵害確認後、以下の順序で対応を進めたと公表しています。
- 影響範囲の特定。Context AI 側が侵害と疑われるトークン群を Vercel に共有
- 強制ローテーション。Vercel 側で該当トークンを一括失効、ユーザーに再認証を促す通知
- 監査ログの提供。影響顧客に対して該当期間のアクセスログを開示
- 公開アナウンス。事象・対応・再発防止策をまとめて公開
連携先の侵害が起きた際に、SaaS 事業者がトークンを能動的に失効する権限を持っていることが、被害拡大の抑制に決定的に効いた事例です。
OAuth トークンが AI エージェントに渡る一般的な経路
今回のインシデントを横展開で理解するために、AI エージェントへ OAuth トークンが渡る代表的な経路を整理します。
Authorization Code Flow + PKCE
最も一般的なのが OAuth 2.0 Authorization Code Flow に PKCE（RFC 7636）を組み合わせた経路です。ユーザーがブラウザでアプリを許可し、認可コードを受け取った AI サービスがバックエンドでアクセストークンに交換します。
サードパーティ AI アプリ（Context AI のような統合）はほぼこの方式を採用しています。ユーザーから見れば「使っているサービスにログインして同意ボタンを押す」だけで連携が完了するため、UX としては自然ですが、トークンの保管責任はそのサービスに完全に移譲されます。
Device Code Flow
CLI ツールや IoT 機器など、ブラウザを完結させにくい環境で使われるのが Device Authorization Grant です。Claude Code のような CLI 型エージェントが SaaS と連携するときに採用されることが増えています。
Device Code Flow は短時間でユーザーが認可コードを承認する設計のため、UX 的に制限はあるものの、ユーザー側の意思を都度確認しやすい性質があります。エージェントに「都度承認」を求めるかどうかは、後述する防御策の設計判断に直結します。
Personal Access Token と Service Account
GitHub の PAT のように、ユーザー側で発行した長期トークンをエージェントに直接渡すパターンもあります。設計者が手早く統合を実現したい場合に使われがちですが、スコープがユーザー全体の権限になりやすく、漏えい時の影響が広範囲に及びます。
サービスアカウントを使う場合は、原則として最小権限のロールを割り当て、ローテーション運用とセットで使うべきです。ここを甘くすると、AI エージェントが扱うクラウドリソース全域が攻撃対象になり得ます。
トークンの保管場所が脅威モデルの起点
このセクションのポイントを整理します。
| 経路 | 保管場所 | 主なリスク |
|---|---|---|
| Authorization Code Flow | サードパーティのサーバー | 連携先の侵害（今回の Vercel 事例） |
| Device Code Flow | ユーザー端末・CLI | 端末侵害、ターミナル盗聴 |
| Personal Access Token | ユーザーが任意の場所に保管 | コードリポジトリへの誤コミット |
| Service Account Key | クラウド KMS / 平文ファイル | 鍵管理の不備、過剰スコープ |
「どの方式を選んだ瞬間に、どこが攻撃面になるのか」を意識しないまま AI 連携を増やすと、組織は気付かないうちに攻撃面を広げます。Vercel と Context AI のケースは、Authorization Code Flow を採用しつつ連携先のトークン保管が侵害された典型例です。
MCP server と Computer Use 経由のリスク
OAuth 経由の正規連携だけでなく、MCP（Model Context Protocol）server や Computer Use を介した経路も、AI エージェント時代の新しい攻撃面として注目されています。
MCP server の権限境界
MCP server は AI モデルが外部ツールやデータソースに安全にアクセスするためのプロトコル仕様で、Anthropic を中心に各社が対応を進めています。実装次第ですが、ローカル端末上で動く MCP server が OS のシークレットストアや環境変数、ブラウザ拡張のクッキーなどを読み取り、モデルに渡す構成も可能です。
ここで気を付けたいのは、MCP server が読める情報の境界 = AI モデルが読める情報の境界 になるという構造です。便利だからといって権限を絞らずに繋げると、本来モデルに渡すべきでない credential が容易にコンテキストに混入します。MCP server の構成は組織のセキュリティポリシーに合わせた設計が前提です。
詳細な実装パターンは Claude Code の MCP サーバー設定完全ガイド でも整理しているので、運用前に確認をおすすめします。
Computer Use 経由のスクリーンキャプチャ
Computer Use は Anthropic Claude が画面操作を代行する機能で、ブラウザやアプリを操作してタスクを完了させます。便利な一方で、エージェントが操作する画面には認証画面・パスワード入力・MFA コードといったセンシティブ情報が映り込む可能性があります。
スクリーンショットや DOM 情報がモデルにフィードバックされる仕様上、ユーザーが意識せずに credential を AI に共有してしまうリスクが構造的に存在します。Anthropic 自身もガイドラインで慎重なスコープ設計を推奨しています。
プロンプトインジェクションと連動した攻撃
OWASP Top 10 for LLM Applications でも繰り返し警告されているのが、プロンプトインジェクションを介した認証情報の引き出しです。AI エージェントが Web ページの内容を読み込む過程で、攻撃者が仕込んだ指示文が実行され、保有しているトークンや credential を外部 URL に送信させる攻撃が成立します。
MCP server や Computer Use と組み合わせると、被害の拡大経路はさらに広がります。Vercel と Context AI の事例は OAuth トークン保管の侵害でしたが、エージェントの動作経路そのものを突く攻撃も今後増える前提で防御を考える必要があります。
💡 ワンポイント MCP server を本番に組み込む前に、必ず権限境界とコンテキスト混入経路を図に書き起こしましょう。書けない構成は運用できないと割り切るのが安全です。
Vercel が打ち出した対応と再発防止策
Vercel は今回のインシデントを受けて、複数の再発防止策を公表しています。要点を整理します。
トークン失効と監査ログ提供
最初の対応は、影響顧客に対するトークン強制失効と、該当期間のアクセスログ提供です。SaaS 事業者として連携先のトークンを能動的に管理できる権限を持つことが、被害拡大を最小化する鍵になりました。
Vercel は影響顧客向けに、ログイン履歴・API 呼び出しログ・環境変数アクセスログをまとめた監査ビューを一時的に拡張提供したと報告しています。組織内のインシデント対応プロセスでも参考にできる動きです。
連携アプリの審査基準強化
Vercel Marketplace に登録されるサードパーティ統合の審査基準を見直し、保管するトークンの種類・保管場所・ローテーション間隔・侵害時の通知 SLA を申請時の必須項目として追加すると公表しました。連携アプリ側のセキュリティ要件をプラットフォーム側で底上げする方向性です。
連携先の運用品質をプラットフォームが管理する動きは、AWS Partner Network や Google Cloud Marketplace でも見られる流れで、AI エージェント連携が増える今後はさらに重要になります。
トークン寿命の短縮と自動ローテーション
Vercel API 経由のアクセストークンについて、デフォルトの寿命を短縮し、リフレッシュトークンの強制ローテーションを段階的に標準化する計画も示されました。長寿命トークンが生む攻撃面を、構造的に縮小していく方針です。
短命トークン化は API 開発側に追加実装の負担を強いますが、漏えい時の被害時間を物理的に短くする最も効果的な手段の一つです。AI エージェントとの連携を前提とする SaaS は、この方向への追従が避けられません。
顧客への透明な通知運用
Vercel は影響顧客に対して、ステータスページ・メール通知・ダッシュボード内バナーの 3 経路で同時通知を行いました。顧客が情報を見落とさない通知設計と、対応の進捗を継続的に開示する姿勢は、SaaS 事業者の事故対応の手本として評価できます。
開発者と SaaS 提供者の防御策 7 つ
ここからは、AI エージェント時代に組織が実装すべき防御策を 7 つの観点で整理します。
1. OAuth スコープを最小化する
AI エージェントに付与する OAuth スコープを「とりあえず広め」で渡すのをやめます。エージェントが使う API の範囲を明文化し、スコープを最小化したアプリ登録を行うことが第一歩です。スコープが過剰であるほど、漏えい時の被害は深くなります。
2. トークン寿命を短くする
長寿命のアクセストークンは攻撃者にとって最大のごちそうです。アクセストークンの寿命を 1 時間以内、リフレッシュトークンも数日〜数週間に抑え、ローテーション運用を徹底します。今回の Vercel の方針転換も、この流れに沿うものです。
3. シークレット管理を中央集約する
API キーやアクセストークンは、平文ファイルや環境変数に直接置かず、シークレット管理基盤に集約します。Infisical 完全ガイド 2026 でも整理した通り、AI 開発に特化したシークレット管理プロダクトの選択肢が増えており、検討価値があります。
4. AI エージェントごとに専用 ID を発行する
人間ユーザーの権限を AI エージェントに流用しないことが重要です。エージェントごとに専用のサービスアカウントやマシン ID を発行し、操作ログがエージェント単位で識別できる状態を作ります。事故時の影響範囲特定が格段に楽になります。
5. MCP server と Computer Use の権限境界を可視化する
MCP server を組み込む際は、サーバーが読み取れるリソース・実行できるコマンド・モデルに渡す情報を一覧化します。Computer Use の場合は、画面共有対象のアプリやウィンドウのスコープを限定する運用ルールを定めます。境界を図にできない構成は本番に乗せないと決め切るのが安全です。
6. 連携アプリの棚卸しを定例化する
OAuth で連携している外部アプリの一覧を四半期ごとに棚卸しし、利用していない連携を切る運用を定例化します。今回のように「連携先が侵害される」リスクは、連携を絞ることでしか減らせません。SaaS の管理画面から OAuth アプリの最終利用日が確認できる場合、休眠している連携の解除を組み合わせると効果的です。
7. 異常検知ログとアラート設計を整える
API 呼び出しのレートや IP 分布、操作時間帯の異常を検知できる体制を整えます。Vercel 側が今回早期に侵害を察知できたのは、トラフィックメタデータの相関分析が機能していたからこそです。SaaS 提供側だけでなく、API を呼び出す顧客側でも自社内の利用ログをモニタリングする習慣が必要になっています。
💡 ワンポイント 防御策はどれか一つだけでは足りません。スコープ最小化・トークン短寿命化・専用 ID 発行をセットで導入してはじめて、AI エージェント時代の攻撃面を意味のある単位で削減できます。
セキュアな AI エージェント認証アーキテクチャ
防御策を踏まえて、AI エージェントを安全に運用するためのアーキテクチャ要件を整理します。
ゼロトラストを前提とした設計
AI エージェントは「信頼された環境内で動く忠実なツール」ではなく、「外部から指示を注入され得る半自動主体」と捉えるのが現実的です。ゼロトラスト原則に従い、エージェントの全ての API 呼び出しに対して認証・認可・監査を要求する前提で設計します。
これは、社内の AI エージェントであっても例外ではありません。プロンプトインジェクションを介した内部リソースへの不正アクセスは、社外攻撃者の意図を社内のエージェントが代行する形で発生し得ます。
ポリシーエンジンでの中央制御
エージェントの API アクセス可否を、ポリシーエンジン（OPA など）で中央制御する構成が有効です。「どのエージェントが、どのリソースに、どの時間帯にアクセスして良いか」というルールを宣言的に管理し、コードベースの変更なしにポリシーを更新できる状態を保ちます。
ポリシーをエージェント実装にハードコードしないことで、インシデント時のスコープ縮小や、新しい統合の追加が機敏になります。
Just-in-Time な認可と短寿命トークン
長寿命のサービスアカウントトークンを置きっぱなしにせず、エージェントがタスクを開始した瞬間に必要なスコープのトークンを発行し、タスク完了で失効させる Just-in-Time（JIT）認可を採用します。
JIT 認可は実装コストはかかるものの、漏えいリスクの圧倒的な縮小効果があります。Vault や AWS STS の AssumeRole などを組み合わせれば、現実的に実装可能です。
エージェント識別と監査ログの分離
エージェントの行動ログを、人間ユーザーの行動ログと分離して保管します。エージェントの行動が異常を示した際、人間操作のログから切り出せれば、調査スピードが段違いに上がります。
Claude Code Security 機能 のように、AI 開発ツール側でも監査ログ機能の標準化が進んでおり、これらを活用するのも有力な選択肢です。
サンドボックス化された実行環境
特に Computer Use や CLI 系エージェントは、本番リソースに直接触れさせず、サンドボックス化された仮想環境で動かすのが基本です。ファイルシステムの書き込み権限・ネットワークの通信先・環境変数の参照を最小化した実行環境を用意します。
組織として「エージェントが触れる環境」を明示的に定義することは、認証情報の境界を引き直す最も実用的な手段でもあります。
AI Beat 編集部の見解
今回の Vercel と Context AI のインシデントを編集部としてどう受け止めているか、率直に書きます。
「便利な統合」が同時に攻撃面になる時代
Vercel の Context AI 連携は、開発者体験を底上げする良くできた統合でした。しかしその便利さの裏側で、Vercel 顧客が直接面識のない第三者システムに長寿命トークンを預けていた構図が、今回の侵害ではっきりと浮き彫りになりました。AI 統合の「便利さ」と「攻撃面の拡大」は完全にトレードオフです。
開発者・SaaS 提供者ともに、AI 連携を導入する際の合意形成プロセスを設計し直す必要があります。技術選定だけでなく、認証情報の保管・ローテーション・侵害時の通知まで含めた契約・運用ルールを、連携アプリごとに整備すべきフェーズに入っています。
MCP server と Computer Use の運用は「境界の可視化」から
編集部内でも MCP server と Computer Use を業務に組み込む実験を続けていますが、運用の堅牢さは「権限境界をどれだけ図にできているか」で決まると感じています。便利な機能から順に有効化していくのではなく、書き出した境界の中に収まる範囲だけ有効化するという順序が、現実的にもっとも事故を起こしにくい運用になります。
透明な事後検証が業界基準になってほしい
Vercel と Context AI の対応で印象的だったのは、責任の押し付け合いをせず、両社が連携して影響範囲を特定し、顧客への通知まで素早く回した点でした。AI エージェント連携が標準化する流れの中で、こうした透明な事後対応が業界の基準として根付くことを編集部は強く期待しています。一方で、開発側にも連携アプリ選定の質を高める責任が確実に増えていきます。インシデントは AI を使わない理由ではなく、AI とどう付き合うかを問い直すきっかけです。
まとめ
最後に、今回の Vercel インシデントから持ち帰るべきポイントを整理します。
押さえておきたい 3 つの要点
- 侵害は連携先で起きた。Vercel 本体ではなく Context AI 側の事故が顧客環境に伝播した
- 長寿命トークンが攻撃面を広げた。短寿命化と自動ローテーションは AI 連携時代の標準要件
- MCP server / Computer Use の権限境界を可視化することが、現場で最も効くリスク低減策
次に取るべきアクション
組織として、外部 AI 連携の棚卸し・OAuth スコープの見直し・シークレット管理基盤の導入検討を、今四半期のセキュリティロードマップに入れるのが現実的です。AI エージェントを安全に活かすための投資は、もはや先送りできない経営課題です。
※ 2026 年 4 月時点の情報です。Vercel および Context AI の対応は順次更新されているため、最新の状況はVercel Security Announcementsをご確認ください。
よくある質問
Q. 今回の Vercel インシデントで自社が影響を受けたか確認するには？
A. Vercel ダッシュボードの Audit Log と OAuth 連携アプリ一覧を開き、Context AI を有効化していたか、影響期間中に異常な API 呼び出しがなかったかを確認します。連携を有効化していなくても、過去に試して権限を残したままだったケースもあるため、棚卸しを兼ねたチェックがおすすめです。
Q. Context AI 以外の連携アプリも危険ですか？
A. 単独で危険な連携と決めつけることはできませんが、長寿命の OAuth トークンを保管する連携は構造的にリスクが高いと言えます。利用していない連携を切る、利用中でもスコープを最小化するという基本動作を、すべての連携アプリに適用することが現実的な対策です。
Q. MCP server を社内で運用しても問題ないでしょうか？
A. 問題なく運用できますが、サーバーが読み取れるリソースと、モデルに渡す情報の境界を明確に設計することが前提です。詳細な構成例は Claude Code の MCP サーバー設定完全ガイド でも整理しています。設計図が書けない構成のままで本番に乗せるのは避けましょう。
Q. Computer Use を業務利用するときの注意点は？
A. 操作対象のアプリを限定し、本番認証情報をエージェントが扱う画面に表示させない設計が基本です。スクリーンショットや DOM 情報がモデルにフィードバックされる前提を踏まえ、機微な情報を含むアプリは別環境で人間が操作する運用ルールを定めます。
Q. シークレット管理基盤はどれを選べば良いですか？
A. 既存のクラウドプロバイダがある場合はそのマネージドサービス（AWS Secrets Manager など）が無難ですが、AI 開発で MCP server や CLI 系エージェントを多用するチームには、開発者体験に振り切った Infisical 完全ガイド 2026 でも紹介しているような OSS 系プロダクトも有力な選択肢です。要件に合わせて 2 〜 3 製品を比較したうえで決めるのが現実的です。
Q. AI エージェント時代の OAuth 設計の参考資料は？
A. OAuth 2.0 RFC 6749、PKCE RFC 7636、Device Code Flow RFC 8628 の 3 本を押さえておくと、ほとんどのフローが読み解けるようになります。あわせて OWASP Top 10 for LLM Applications を組み合わせれば、AI 文脈での脅威モデリングも整理できます。
