A Vercel úgy köti össze a v0-t a Snowflake-kel, hogy a token rejtve marad

A sandbox önmagában nem védi meg a hitelesítő adatot

A Vercel 2026. augusztus 20-án ismertetett megoldása a v0 Snowflake-integrációjához készült. A szolgáltatás lehetővé teszi, hogy a felhasználók összekapcsolják Snowflake-fiókjukat, megvizsgálják az adatbázis-sémákat, lekérdezzék az adatokat, majd az adattárházukon futó alkalmazásokat generáltassanak.

A létrehozott kód azonban modell által írt kód, amely emberi ellenőrzés nélkül fut. A Vercel szerint egy promptbefecskendezés ráveheti az alkalmazást arra, hogy mindent megpróbáljon kinyerni, amihez hozzáfér. Ezért a felhasználó OAuth-tokenje nem kerülhet abba a környezetbe, ahol a generált kód fut.

A v0 alkalmazásai elkülönített sandboxokban futnak. Ez az elkülönítés megakadályozza, hogy a nem megbízható kód a rendszer más részeihez hozzáférjen, de nem védi meg a titkot, ha az már a sandboxban van. A token fájlba, naplóba, API-válaszba vagy generált klienskódba másolható, illetve egy másik hosztra is elküldhető.

Minden Snowflake-kérés a külső proxyhoz kerül

A Vercel megoldása a v0 sandboxokhoz épített Snowflake-kérésproxyra támaszkodik, amely a Vercel Sandbox tűzfalán kívül fut. A sandbox közvetlenül nem kommunikál a Snowflake-környezettel. Amikor a benne futó kód kérést küld a felhasználó Snowflake-fiókjának hosztjára, a tűzfal a forgalmat a v0 proxyjához továbbítja.

A tűzfal sandboxonként egyedi hitelesítésszolgáltatóval zárja le a TLS-kapcsolatot. Így a proxy el tudja olvasni és át tudja írni az egyébként titkosított forgalmat, miközben a Snowflake SDK és parancssori kliens alapértelmezett tanúsítvány-ellenőrzése, az OCSP-vel együtt, változatlanul használható.

A proxy ellenőrzi a sandbox OIDC-tokenjét, megkeresi, melyik v0-beszélgetéshez tartozik a sandbox, visszaállítja az adott beszélgetéshez kötött felhasználói munkamenetet, majd friss Snowflake-hitelesítő adatot kér le. A célként használt Snowflake-fiók hosztját a proxy a szerveroldali hitelesítő adatból vezeti le, és elutasítja az érvénytelen címeket. Így a generált kód nem határozhatja meg szabadon, melyik fiókhoz használják a hitelesítést.

A helyettesítő token csak a kompatibilitás miatt marad

A Snowflake-kliensek többféle módon kezelik a hitelesítést. Egyes SQL API-kérések a Bearer-tokent az Authorization-fejlécben küldik, más folyamatok helyi tokenfájlokat olvasnak be, majd a tokent egy bejelentkezési kérés részeként továbbítják. A bejelentkezés után a további kérések Snowflake által kiadott munkamenet-tokeneket használnak.

A kompatibilitás fenntartása érdekében a v0 továbbra is ír egy tokenre hasonlító helyettesítő értéket a sandboxba. Ez egy rögzített, nyilvános, 72 bájtos karakterlánc, amely önmagában semmilyen hozzáférést nem ad. A valódi OAuth-token soha nem kerül a sandboxba, és a proxy nem a helyettesítő érték alapján engedélyezi a kéréseket, hanem a sandbox szerveroldali identitása és a v0-beszélgetéshez való kötése alapján.

A Vercel első megoldása még a valódi tokent írta a sandbox Snowflake-tokenfájljaiba. Ezt váltotta fel a proxy. A sandboxban ugyanakkor bejelentkezés után Snowflake-munkamenet-tokenek jelenhetnek meg. Ezek egyetlen hitelesített munkamenethez tartoznak, a generált alkalmazások Snowflake-segédje pedig minden lekérdezés után bezárja a kapcsolatot. A sandbox megszüntetése ezeket a tokeneket is eltávolítja, a Snowflake pedig alapértelmezés szerint négy óra tétlenség után szerveroldalon lejáratja a munkamenetet.

A proxy csak hitelesítési mezőkbe írhat tokent

A Vercel szerint a token vakon történő behelyettesítése biztonsági rést nyitott volna. Ha a proxy minden kérés törzsében lecseréli a helyettesítő értéket a valódi tokenre, akkor egy SQL-lekérdezés szövege is tartalmazhatja ezt az értéket. A csere ilyenkor a lekérdezésbe írná a valódi OAuth-tokent, amelyet az adatbázis válaszként visszaadhatna a sandboxban futó kódnak.

Az új működés a Snowflake-kérés típusától függ. SQL API-kérésnél a proxy az OAuth-tokent az Authorization: Bearer fejlécbe írja, a felhasználó által vezérelt SQL-törzset pedig nem módosítja. Ha a helyettesítő érték megjelenik az SQL-adatban, a proxy még a Snowflake elérése előtt elutasítja a kérést.

Bejelentkezési kérésnél a proxy feldolgozza a JSON-törzset, strukturáltan beállítja a tokent a bejelentkezési mezőben, majd újra szerializálja az adatot. Ha a helyettesítő érték máshol is megmarad a törzsben, a kérés meghiúsul. A bejelentkezés utáni, Snowflake által kezelt munkamenet-tokeneket használó kéréseknél nincs szükség újabb tokenbehelyezésre.

A proxy elutasítja a kérést akkor is, ha a sandbox nincs beszélgetéshez kötve, nem szerezhető felhasználói hitelesítő adat, nem vezethető le a Snowflake-fiók hosztja, vagy a strukturált kérés törzse nem dolgozható fel biztonságosan. A kérések méretét és feldolgozását előre korlátozzák. Minden proxyn átmenő kéréshez megfigyelhetőségi esemény készül az eredménnyel, az állapotkóddal, az időtartammal és a tokenbehelyezés helyével, titkok közzététele nélkül.

A felhasználó számára a folyamat változatlan marad

A tokenfrissítés nem támaszkodhat a böngészőben lévő munkamenet-sütire, mivel a proxykérések a sandboxból indulnak. A v0 ezért a felhasználói munkamenetet a sandboxhoz köti, a proxy pedig ebből a kötésből állít elő és frissít OAuth-hitelesítő adatokat.

A közzétételi folyamat a Snowflake CLI hasonló hitelesítési határát használja. A telepítés a helyettesítő értéket írhatja a hitelesítési fájlokba, a valódi tokent azonban nem. A telepített alkalmazás Snowpark Container Services környezetben saját szolgáltatásfelhasználóként hitelesít, a Snowflake által kezelt és automatikusan forgatott token pedig a /snowflake/session/token útvonalon érhető el. Ekkor a felhasználó OAuth-tokenje és a v0 proxyja már nem vesz részt a működésben.

A Vercel szerint a felhasználói folyamat ebből semmit nem érzékel: a felhasználó csatlakoztatja a Snowflake-et, megkéri a v0-t a sémák vizsgálatára vagy egy alkalmazás elkészítésére, megtekinti az előnézetet, majd telepíti az eredményt. A háttérben a hitelesítés az egyes végpontok kijelölt mezőire korlátozódik, így a generált kód meglévő Snowflake-klienseket használhat anélkül, hogy hozzáférne a felhasználó újrahasznosítható OAuth-credentialséhez.