Securely connecting Gemini Enterprise to Snowflake data
This guide explores how to build a secure bridge between Google Cloud’s Gemini Enterprise and Snowflake. By using the Model Context Protocol (MCP) and the Google Agent Development Kit (ADK), you can empower your agent to act as an assistant that understands natural language, generates precise SQL via Snowflake Cortex and executes queries with user-level permissions.
Choosing the right integration pattern
Direct Connection vs. custom orchestration
The Google ADK architecture demonstrated in this post represents the advanced / custom orchestration pattern. It is designed for developers building complex, multi-agent systems on Google Cloud, such as workflows that combine Snowflake insights with external enterprise tools, custom reasoning loops, or cross-platform state management in Gemini Agent Engine.
For standard enterprise basic use cases where you want to connect Gemini Enterprise directly to Snowflake use the joint solutions mentioned in this link.
The architectural approach
This architecture allows a business user to ask questions like, "What were our top 5 selling items in Texas last quarter?"
Rather than exposing raw SQL execution to the client, the agent delegates both query generation and execution to a governed Snowflake Cortex Agent exposed through the Snowflake MCP server:
* Governed translation: The ADK agent passes the user's natural language question to the Snowflake MCP server, which invokes the Cortex Agent (CORTEX_AGENT_RUN) backed by Cortex Analyst semantic view.
* Direct execution within the governed boundary: The Cortex Agent translates the question into SQL and executes it directly inside Snowflake using the authenticated user's OAuth session and role privileges, returning the structured results to the ADK agent.
This approach provides deterministic text-to-SQL translation mapped to your corporate semantic definitions, keeps query execution inside Snowflake's governed boundary, and reduces the risk of schema hallucinations or unvalidated SQL execution.
System architecture flow
The diagram below illustrates the trust boundaries and the numbered flow of execution between the Gemini Enterprise app and Snowflake ecosystems.
Detailed execution sequence
To highlight how the agent delegates natural language query translation and governed execution to the Snowflake Cortex Agent over MCP, see the sequence diagram below:
Step 1: Setting up the Snowflake security integration
A major risk in enterprise AI is granting the model broad access via a generic service account, which could allow users to bypass security restrictions. We solve this by using OAuth 2.0 to perform user impersonation.
First, establish a confidential OAuth client in Snowflake to protect the client secret. The snippet below configures the security integration inside Snowflake:
code_block
To retrieve the generated client credentials needed for the Google Cloud configuration, run the following command in Snowflake:
code_block
Step 2: Data governance and access control
Apply the principle of least privilege by creating a dedicated role for your agent inside Snowflake.
code_block
IMPORTANT
* The user context must have SELECT privileges on the physical tables backing the semantic view. Granting access only to the semantic view will cause runtime errors during query execution.
* If granting direct access to base tables is not permitted by your security policy, place a Snowflake Secure View over the physical tables and build the Semantic View on top of it. Because Snowflake views execute with Owner's Rights, the user's GenAI role only needs SELECT privileges on the Secure View and Semantic View rather than the raw tables.
* Snowflake OAuth tokens capture and bind to the user's DEFAULT_ROLE and DEFAULT_WAREHOUSE at the exact moment of authorization. If a user authorizes the connection before these defaults are configured, the session will be locked to the wrong role(role available at that time) and query execution will fail if the intended role will not have required privileges.
* Set defaults(as shown below) prior to authorizing in Gemini Enterprise.
* Authorize connection: Have the user perform the one-time OAuth authorization in Gemini Enterprise.
* (Optional) Revert defaults: Once authorized, the user can safely revert their default role and warehouse in Snowflake back to their standard operational preferences.
code_block
Step 3: Provisioning the Cortex Agent and MCP server inside Snowflake
Next, create a governed Cortex Agent in Snowflake using your semantic view, then provision an MCP server that exposes the agent via the CORTEX_AGENT_RUN tool type. This approach delegates both SQL generation and query execution to Snowflake while enforcing the caller's OAuth identity and role permissions.
code_block
NOTE: The Python snippet above represents a plain/vanilla version of the agent setup. Depending on your organization's specific requirements, you should add robustness on top of this template (e.g., custom error handling, structured schemas, custom prompts, configurations, and additional tool wrappers).
Step 6: Project structure and deployment
To deploy your ADK agent to Agent Runtime in Agent Platform, organize your files in the following directory layout:
code_block
* File details
* __init__.py: Exposes the root_agent object to the deployment CLI:
code_block
* .env: Declares environment configuration:
code_block
* requirements.txt: Specifies dependencies:
code_block
2. Deploying via the CLI
Rather than running complex custom Python scripts or manual container builds, you can deploy using the official Google Agents CLI (agents-cli). The CLI packages your code, sets up the server, and handles the deployment pipeline:
code_block
The CLI automatically handles the deployment lifecycle. Once complete, it outputs the unique project resource path (e.g., projects/PROJECT_ID/locations/LOCATION/reasoningEngines/RESOURCE_ID) which you will use to register the agent in the next step.
TIP: For more information and advanced configuration options for ADK agent deployment, refer to:
* ADK Agent Runtime Deployment Guide
* ADK Deployment Reference Documentation
Step 7: Registering the custom agent in Gemini Enterprise
Once the agent code is ready and deployed, register the agent in the Google Cloud Console. Here, you will link the agent configuration and map the OAuth parameters retrieved from your Snowflake Security Integration.
* Extracting the OAuth Endpoints from Snowflake
Run this query in Snowflake to extract the precise Token and Authorization endpoints:
code_block
In the results, locate the values for the following properties:
* OAUTH_AUTHORIZATION_ENDPOINT: Your Snowflake Authorization URI.
* OAUTH_TOKEN_ENDPOINT: Your Snowflake Token URI.
2. Registration steps in Google Cloud console
* Go to the Gemini Enterprise page in the console.
* Select the application you want to register the agent with.
* In the left navigation, click Agents, then click + Add agent.
* Select Add for Custom agent via Agent Platform. The Authorizations setup displays.
* Set up the Snowflake OAuth connection:
* Click Add authorization.
* Authorization name: Enter the exact ID you defined in your ADK code (e.g., snowflake_oauth_conn). This ensures the credentials map correctly to the code's AUTH_ID.
* Client ID & Client secret: Input the credentials you retrieved from Snowflake using the SYSTEM$SHOW_OAUTH_CLIENT_SECRETS query.
* Token URI: Input the exact token endpoint value extracted from DESCRIBE SECURITY INTEGRATION.
* Authorization URI: Take the authorization endpoint value extracted from DESCRIBE SECURITY INTEGRATION and append ?response_type=code at the end (along with your client ID and scope query parameters, for example):
code_block
IMPORTANT
Ensure the Authorization URI ends with &response_type=code (or ?response_type=code if there are no other parameters). This parameter is required by Google Cloud to trigger the OAuth 2.0 authorization code flow.
* Click Done, then click Next.
6. Configure the agent properties:
7. Click Create to complete registration.
Understanding identifier alignment
* ADK Code AUTH_ID Google Cloud Authorization Name: The AUTH_ID in your Python script must exactly match the Authorization Name/ID you input during console registration. Because we write code first, we reuse the code-defined identifier during registration.
* Snowflake Security Integration Name (e.g. ): This is purely a Snowflake-side database object name. It does not need to match the Google Cloud Authorization Name or the AUTH_ID in your ADK Python code.
Get started
By uniting the Gemini model’s reasoning capabilities, ADK's orchestration, and Snowflake's governed data layer, you can safely bring AI to your data. This architecture provides an agentic assistant that respects your security perimeters while delivering business value. 🔗 Google Data
https://cloud.google.com/blog/products/data-analytics/bridge-gemini-enterprise-and-snowflake-with-google-adk/?utm_source=dlvr.it&utm_medium=blogger
