詳細を読む
Vercelは2026年8月20日、生成AIツール『v0』がSnowflakeに接続する際、ユーザーのOAuthトークンを生成コードに渡さない認証プロキシを公開しました。v0はSnowflakeのデータでアプリを自動生成しますが、生成コードは人間のレビューを経ず実行されるため認証情報が漏れる危険があります。Vercelはサンドボックス外で認証情報を処理する専用プロキシでこの問題を解決しました。
v0は生成したアプリケーションを隔離されたサンドボックス内で実行しますが、隔離はシステム全体を守る仕組みであり、サンドボックス内にある秘密情報そのものは守れません。もしトークンがファイルとして読み取れれば、ログへの記録やAPIレスポンスへの混入、外部ホストへの送信を通じて流出しかねません。この課題を解決するため、v0はSnowflakeへのリクエストをすべて専用プロキシ経由にしました。
サンドボックスはSnowflakeへ直接通信できず、すべてのリクエストはファイアウォールを経由してプロキシへ転送されます。プロキシはサンドボックスごとに異なる証明書でTLS通信を終端して内容を検証し、サンドボックスのOIDCトークンを確認したうえで、そのセッションに紐づくユーザー本人の新しい認証情報を発行します。接続先のSnowflakeアカウントもサーバー側の情報から決まるため、生成コードが指定したホストへ誤って送信される心配もありません。
互換性を保つため、v0はサンドボックス内に実際のトークンの代わりとなる72バイトのプレースホルダーを書き込みます。当初はこの文字列をリクエスト全体から検索し、本物のトークンに置き換える方式を採用していましたが、SQL文などユーザーが自由に書ける部分にプレースホルダーが含まれていた場合、本物のトークンがクエリの一部として書き換えられ、サンドボックス内に漏れ出す恐れがあることが分かりました。
そこでプロキシは、Snowflakeへのリクエストの種類ごとに認証情報が入るべき場所をあらかじめ定義し、そのフィールドだけにトークンを注入する方式に切り替えました。プレースホルダーが認証用のフィールド以外に現れた場合や、サンドボックスがユーザーのセッションに紐づいていない場合には、プロキシがリクエストを拒否して記録に残す仕組みも備えています。
この仕組みは本番投入から15日間で約1万3000件のリクエストに認証情報を付与し、プレースホルダーの誤用による拒否は一件も記録されませんでした。VercelはSnowflake以外の外部サービス連携にも同じ設計思想を広げる考えを示しており、v0のSnowflake連携は現在ベータ版として提供されています。