詳しい解説 · 読了目安 7 分
Vercel、エージェントの長期キーを権限を限定した短期IDへ移す計画
OIDCの設定支援、実行時のトークン交換、Marketplaceの予定ルールを組み合わせる。効果は信頼ポリシーとユーザー権限の正確さに依存する。
- 当サイトの公開日
- 原典の公開日
- 出典確認日
Vercel CTOのMalte Ublは2026年10月22日の技術記事で、繰り返し使う秘密情報から短命なサービスIDへの移行を説明した。AIエージェントのアクセス取得、提供側の検証、連携を変更する動機を一体で扱っている。
ニュースを聴く
この記事を読み上げるか、ニュースを続けて聴けます。
読み上げを準備中…
端末の音声
読み上げはブラウザーまたは端末が処理します。AISubHub は文章を音声 API に送りません。利用できる音声やロック画面での再生は端末によって異なります。
再開時に短い部分を繰り返す場合があります。
要点
- Vercelは1,000社超のSaaS提供企業の調査で、安全と定義した認証方式への対応が8.4%だったと報告する。業界全体の安全性スコアではない。
- 同社は2026年11月30日までのMarketplace警告表示と、2027年1月までの要件未達企業の掲載終了を計画している。実施済みの結果ではない。
1．短い有効期間が抑えるのは特定のリスク
複数サービスを呼ぶエージェントは、その作業に必要な範囲を超えるキーを受け取ることがある。盗まれたコピーは会話の終了後も有効になり得る。Ublはリポジトリ、チャット、侵害された依存関係、プロンプトインジェクションを漏えい経路として挙げる。保存時の暗号化だけでは、実行中のアプリが利用できる認証情報を悪意あるコードから守れない。権限の広さと存続時間の両方が問題になる。
1,000社超、8.4%という値はVercel自身の調査であり、記事は抽出方法や分類基準を代表性のある業界推計に十分なほど示していない。対応の報告値であって、侵害確率や実装品質ではない。同社が予防的キー更新に数千時間の開発工数を使ったという経験も、全顧客で測定された削減効果ではない。
2．有効なIDも受信先の境界と一致する必要がある
OpenID Connect、略してOIDCでは、信頼する発行者がアプリを識別する短期トークンに署名する。受信サービスは検証後に許可する操作を決める。プロジェクトと環境のルールは受け入れるデプロイを限定し、audienceは想定する受信サービスを示す。署名が正しいだけで、このAPIが受け入れるべきことや任意の操作を許せることにはならない。
漏れた短期トークンも、期限までは付与された権限内で利用できる。短命化はそのコピーの利用期間を抑えるが、漏えいや侵害された処理による再発行要求を防ぐものではない。Vercelによれば、AWS、Google Cloud、Azureの一時認証情報へ交換するフェデレーションは2024年から一般提供済みだ。Blob、AI Gateway、Sandboxも既存例であり、この記事当日の新規公開ではない。
3．ConnectとOIDC UIは交換の別々の側を担う
Vercel ConnectはデプロイIDを使い、実行時に提供企業のトークンを要求する。Linearの例はユーザー主体とread権限を指定する。設定済みでプロジェクトに関連付けたコネクター、接続済みのユーザーアカウント、提供側が対応するscopeが前提だ。関数を呼ぶだけで任意のアカウントへアクセスできたり、接続手順が不要になったり、各社の権限が統一されたりはしない。
API提供者向けのOIDC UIは、shadcn/uiレジストリとして信頼ポリシーのフォームとサーバー側の検証コードを用意する。確認した図では、発行者、チーム、プロジェクト、環境、audienceが分かれている。反復実装を減らせても、正しい信頼境界を決めるのは提供者だと当サイトは分析する。プロジェクトを広く許しすぎたりaudienceを誤ったりすれば、生成に成功してもポリシーの問題は残る。
4．処理の軽量化でもネットワーク交換は残る
記事は既存トークンの読み取りと交換を区別する。Vercel Functionsにはプラットフォーム発行のIDトークンがリクエストヘッダーで届き、SDKは再取得せずに読める。期限内のトークンを再利用し、Connectはプロセス内に提供側トークンをキャッシュして期限近くに更新する。一方、カスタムaudienceや提供側との交換にはネットワーク呼び出しが必要で、全認証の追加遅延ゼロを意味しない。
Cosmos DBの例では、AzureがVercelのプロジェクトと標準audienceを信頼し、ClientAssertionCredentialがVercelトークンを提示してAzureのアクセストークンへ交換し、CosmosClientがそれを使う。初回成功だけでなく更新時や提供側の稼働状況も考える必要がある。独立した遅延ベンチマークや、キャッシュで認証障害をなくせるという保証は示されていない。
5．Marketplaceの期限は予定された商業的誘因
Ublは設定の難しさ、リクエスト経路の遅延、提供側の動機不足という三つの壁を挙げる。最後の壁に対し、Vercelは2026年11月30日までに、VercelからのOIDC認証に対応せず長期秘密情報を使う企業の掲載に「Not secure」と表示する計画を示す。安全な認証を提供しない企業は2027年1月までに掲載終了とする方針だ。
これは自社エコシステム向けの将来要件で、執行済みの措置や世界共通の法律ではない。1月の具体的な日や時刻は記載されていない。Vercelは自社APIとネイティブ連携にも同じ基準を適用するとし、サービス接続時の自動設定は取り組み中と説明する。Marketplaceの接続すべてが既にフェデレーションを設定するとは考えず、個別の対応状況を確認したい。
6．移行では発行成功だけでなく認可を試す
あるユーザーのLinearタスクだけを読むエージェントを教材上の例とする。当サイトの提案は、長期キーを棚卸しし、サービス、デプロイ、ユーザー、必要権限を対応付けることだ。信頼と接続を設定後、想定の読み取りは成功し、別プロジェクト、環境、audienceや権限外操作は拒否されるか確認する。これは推奨する確認手順で、当サイトの実測やVercelの追加保証ではない。
旧キーを撤去する前に、失効、更新、キャッシュ、交換失敗を確認し、復旧手順を定める。トークン取得の成功が、過剰権限や不安定な更新を隠す場合がある。有用なのは、観察できる境界を持つ限定的で更新可能な権限への移行だ。エージェントから認証情報がなくなるわけでも、プロンプトインジェクションが解決するわけでも、全下流サービスの対応が保証されるわけでもない。
注目する理由
当サイトの分析では、デプロイIDは長期キーの配布を減らせる一方、受信側の対応と制限が不可欠だ。Marketplaceの誘因が対応拡大につながる可能性はあるが、設定とユーザー認可は残る。
制約と提供状況
公式記事と設定図に基づく分析で、独立した安全性監査や性能試験は行っていない。調査方法の開示は限定的で、予定期限を実施済みとは扱わない。アカウント、連携、運用設定は変更していない。
出典と根拠
原典の公開日: · 出典確認日:
AI を活用した編集記事を、記載した一次情報で確認しています。企業の主張は出典を明示し、掲載は推奨を意味しません。