# How v0 authenticates to Snowflake without exposing the user's OAuth token

DevFeed: [How v0 authenticates to Snowflake without exposing the user's OAuth token](<https://devfeed.tech/articles/how-v0-authenticates-to-snowflake-without-exposing-the-user-s-oauth-token-753.md>)

Original publisher: [Read original article](<https://vercel.com/blog/how-v0-authenticates-to-snowflake-without-exposing-the-users-oauth-token>)

Author: Nicolás Montone

Published: 2026-08-20T04:00:00Z

Content type: article

Language: en

Sources: [Vercel News](<https://devfeed.tech/sources/vercel-news.md>)

Topics: [AI-assisted coding](<https://devfeed.tech/topics/ai-assisted-coding.md>), [AI Chat](<https://devfeed.tech/topics/ai-chat.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [api](<https://devfeed.tech/tags/api.md>), [app](<https://devfeed.tech/tags/app.md>), [applications](<https://devfeed.tech/tags/applications.md>), [firewall](<https://devfeed.tech/tags/firewall.md>), [oauth](<https://devfeed.tech/tags/oauth.md>), [sandbox](<https://devfeed.tech/tags/sandbox.md>), [sandboxes](<https://devfeed.tech/tags/sandboxes.md>), [secrets](<https://devfeed.tech/tags/secrets.md>), [tls](<https://devfeed.tech/tags/tls.md>), [vercel](<https://devfeed.tech/tags/vercel.md>)

## AI overview

The article explains how v0 lets AI-generated applications access Snowflake through a proxy without exposing a user's OAuth token to unreviewed generated code.

## Source excerpt

AI-generated applications often need to authenticate to external services on behalf of their users. That creates a problem: generated code shouldn't have access to the user's credentials. We faced that decision when building the v0 Snowflake integration. It lets users connect Snowflake, inspect schemas, query data, and generate applications that run against their warehouses. That generated code has to authenticate to Snowflake, but it is written by a model and runs without human review, and prompt injection can steer it into exfiltrating whatever it can read, so the user's OAuth token should never enter the environment the code runs in. We solved this with a Snowflake request proxy for v0 sandboxes, built on the Vercel Sandbox firewall. The sandbox can run normal Snowflake clients, but the real credential is resolved at request time in a server proxy outside the sandbox runtime. This lets existing Snowflake clients work inside the sandbox without exposing the user's credential to generated code. The harder problem was deciding where the proxy could safely inject the credential. The obvious implementation, replacing a placeholder token wherever it appears, introduces another credential leak. Isolation doesn't protect secrets v0 runs generated applications in isolated sandboxes. Isolation protects the rest of the system from untrusted code, but it doesn't protect secrets inside the sandbox. If a generated app can read a token from the filesystem, that token can be copied into logs, returned in an API response, embedded into generated client code, or sent to another host. Sandbox isolation limits what the application can access, but it does not help once the credential itself is available inside the sandbox. For Snowflake, the credential represents the Snowflake role the user connected with. v0 should be able to help the user explore and build with data they are authorized to access, but generated code should not receive raw provider credentials just because it needs o