v0 проксирует Snowflake: OAuth остаётся за пределами AI-песочницы

v0 генерирует приложения под ваш Snowflake, но OAuth пользователя не попадает в песочницу, где крутится код модели. Vercel показала схему с серверным прокси на базе Sandbox firewall: в изолированной среде лежит 72-байтная заглушка без доступа, настоящий credential подставляется только при запросе снаружи.

Изоляция не прячет секреты

Песочница защищает остальную систему от недоверенного кода, но не спасает секрет, который уже лежит внутри. Токен может уехать в лог, ответ API или результат SQL. Инъекция промпта направляет модель туда, куда нужно злоумышленнику. Поэтому v0 не записывает пользовательский OAuth в sandbox.

Как работает прокси

Код в песочнице не ходит в Snowflake напрямую. Firewall перехватывает TLS с уникальным CA на каждую sandbox, прокси проверяет OIDC-токен, восстанавливает сессию чата v0 и подставляет свежий credential. Хост аккаунта Snowflake берётся с сервера, сгенерированный код не задаёт, куда уйдёт запрос с токеном.

Для SQL API прокси ставит OAuth в заголовок Authorization: Bearer. Для login-запросов токен попадает в поле token JSON-тела. Сессии после входа прокси пропускает без изменений; обновление OAuth идёт с сервера по привязке sandbox к чату, без cookie браузера из песочницы.

Почему не «найти и заменить»

Первая версия прокси искала заглушку в теле запроса и меняла её на реальный токен где угодно. Placeholder в SQL как строковый литерал превращался в утечку: Snowflake возвращал настоящий OAuth в результате запроса обратно в sandbox. Сейчас токен вставляется только в поля авторизации конкретного endpoint. Placeholder вне них означает отказ и запись в лог misuse.

За первые 15 дней в проде прокси подставил credentials server-side для 13 000 запросов, ноль срабатываний placeholder-misuse. После deploy приложение переезжает в Snowpark Container Services под отдельным service user; интеграция v0 со Snowflake сейчас в beta.

Источник: How v0 authenticates to Snowflake without exposing the user's OAuth token.