This guide walks through building a secure bridge between Google Cloud’s Gemini Enterprise and Snowflake using the Model Context Protocol (MCP) and the Google Agent Development Kit (ADK). The target architecture is the advanced/custom orchestration pattern: an ADK agent that understands natural language, generates precise SQL through Snowflake Cortex, and executes queries with user-level permissions. For simpler enterprise use cases that need a direct Gemini Enterprise-to-Snowflake connection, the article points instead to joint solutions referenced in the original post.

In the demonstrated flow, a business user asks a question like “What were our top 5 selling items in Texas last quarter?” The ADK agent does not execute SQL itself; it passes the natural language question to the Snowflake MCP server, which invokes a governed Snowflake Cortex Agent (CORTEX_AGENT_RUN) backed by a Cortex Analyst semantic view. The Cortex Agent translates the question into SQL and runs it directly inside Snowflake under the authenticated user’s OAuth session and role privileges, then returns structured results to the ADK agent. Because translation and execution stay inside Snowflake, the approach yields deterministic text-to-SQL mapped to corporate semantic definitions, keeps queries within Snowflake‘s governed boundary, and reduces schema hallucinations or unvalidated SQL execution.

The setup starts with a Snowflake security integration: a confidential OAuth 2.0 client protects the client secret and enables user impersonation rather than a broad generic service account. Client credentials are retrieved with SYSTEM$SHOW_OAUTH_CLIENT_SECRETS. Data governance follows least privilege: create a dedicated GenAI role, but the user context must have SELECT privileges on the physical tables backing the semantic view; granting only semantic-view access causes runtime errors. If direct base-table access is not allowed, place a Snowflake Secure View over the physical tables and build the semantic view on it; because Snowflake views execute with Owner’s Rights, the GenAI role only needs SELECT on the Secure View and Semantic View. Also, Snowflake OAuth tokens bind to the user’s DEFAULT_ROLE and DEFAULT_WAREHOUSE at authorization time, so those defaults must be set before the user authorizes in Gemini Enterprise; they can be safely reverted afterward.

Next, provision a governed Cortex Agent in Snowflake and an MCP server that exposes it via the CORTEX_AGENT_RUN tool type. The article warns against exposing raw execution tools like SYSTEM_EXECUTE_SQL to external clients, since that bypasses Cortex Agent governance and widens the security surface. After granting access to the MCP server, retrieve its endpoint URL from Snowflake metadata. In ADK code, define an AUTH_ID (for example, snowflake_oauth_conn) that the agent uses to extract user credentials; the sample shown is a plain/vanilla version, and production deployments should add error handling, structured schemas, custom prompts, and extra tool wrappers.

Deployment uses the official Google Agents CLI (agents-cli), which packages the code, sets up the server, and handles the deployment pipeline, outputting a resource path such as projects/PROJECT_ID/locations/LOCATION/reasoningEngines/RESOURCE_ID. The final step registers the custom agent in the Gemini Enterprise console: extract OAUTH_AUTHORIZATION_ENDPOINT and OAUTH_TOKEN_ENDPOINT from DESCRIBE SECURITY INTEGRATION, create an authorization whose name exactly matches the ADK AUTH_ID, and set the Authorization URI with ?response_type=code (or &response_type=code) appended to trigger the OAuth authorization code flow. The Snowflake security integration name is a Snowflake-side database object and does not need to match the Google Cloud authorization name or the code’s AUTH_ID.

Taken together, the pattern combines Gemini’s reasoning, ADK orchestration, and Snowflake‘s governed data layer so the agent respects security perimeters while delivering business value.