Secure Gemini‑Snowflake bridge: OAuth‑driven governance with MCP and ADK

Google Cloud has introduced a pattern that replaces ad‑hoc chat‑to‑SQL pipelines with a tightly governed bridge between Gemini Enterprise and Snowflake. The change centers on using the Model Context Protocol (MCP) and the Google Agent Development Kit (ADK) to hand off natural‑language questions to Snowflake’s Cortex Agent, which translates and runs the SQL under the requesting user’s OAuth session.

Integration pattern shift

The guide distinguishes two ways to connect Gemini to Snowflake. A simple direct‑connection model is suitable for basic enterprise use cases, while the advanced pattern shown here relies on a custom orchestration built with the ADK. The custom approach is intended for multi‑agent workflows that combine Snowflake insights with other enterprise services, and it enforces a clear trust boundary between the Gemini app and Snowflake.

Secure OAuth integration in Snowflake

To avoid the risk of a generic service account with unrestricted privileges, the architecture creates a confidential OAuth client inside Snowflake. The client secret is stored in Snowflake’s security integration, and the integration is configured to issue refresh tokens that can live up to the platform‑allowed 90‑day limit.

USE ROLE ACCOUNTADMIN;
CREATE OR REPLACE SECURITY INTEGRATION 
  TYPE = OAUTH
  ENABLED = TRUE
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = 'https://vertexaisearch.cloud.google.com/oauth-redirect'
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE
  OAUTH_REFRESH_TOKEN_VALIDITY = 7776000;

After creation, the client ID and secret are retrieved with:

-- Retrieve OAuth Client ID and Client Secret
SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('');

Governed query flow

The runtime sequence is:

1. The user asks a natural‑language question to the Gemini Enterprise app.
2. The ADK agent forwards the question to the Snowflake MCP server.
3. The MCP server invokes the Snowflake Cortex Agent (CORTEX_AGENT_RUN) which uses a semantic view to produce SQL.
4. The generated SQL runs inside Snowflake using the OAuth session tied to the original user’s role, ensuring that only the permissions granted to that user are applied.
5. The structured result is returned to the ADK agent, which presents it to the user.

This flow keeps both translation and execution inside Snowflake’s governed boundary, eliminating the need to expose raw SQL to the client and reducing the chance of schema hallucinations or unauthorized data access.

Operational considerations

Practitioners need to manage the OAuth lifecycle, including token refresh before the 90‑day expiry. Role assignments in Snowflake must be audited to confirm that users only receive the privileges required for their queries. Monitoring should focus on the MCP server logs and Snowflake query history to detect anomalous patterns. Because the integration relies on a confidential client, secret rotation procedures should be defined and integrated with any existing secret‑management pipeline.

Related CloudNinjas coverage: Google Cloud.

What This Means For Practitioners

• Adopt the MCP + ADK pattern when you need fine‑grained, user‑level data access for AI‑driven analytics.
• Configure a confidential OAuth client in Snowflake and enforce short‑lived refresh tokens to limit exposure.
• Validate that user roles in Snowflake align with the data they are allowed to query through Gemini.
• Instrument logging on both the ADK side and Snowflake MCP server to maintain visibility into translation and execution steps.
• Plan for secret rotation and token renewal as part of your regular security operations.