企业 AI 要提供真实价值，不能只停留在聊天界面。Agent 必须能安全访问数据仓库，同时守住安全与数据治理边界。这篇文章介绍如何在 Gemini Enterprise 与 Snowflake 之间建立安全桥接，核心组合是 MCP 与 Google ADK。它演示的 ADK 架构属于高级/自定义编排模式，而不是简单的直连：对于标准企业基础场景，可以用文中提到的联合解决方案；而这个模式面向 Google Cloud 上的复杂多代理系统，比如把 Snowflake 洞察和外部企业工具、自定义推理循环或跨平台状态管理组合起来。

架构上，业务用户可以直接问“德州上季度销量前五的商品是什么”。ADK agent 不直接暴露 SQL 执行给客户端，而是把自然语言问题传给 Snowflake MCP server，触发 Cortex Agent（CORTEX_AGENT_RUN），并由 Cortex Analyst 语义视图支撑。Cortex Agent 在 Snowflake 内部把问题翻译成 SQL，用已认证用户的 OAuth 会话和角色权限直接执行，再把结构化结果返回给 ADK agent。这样 text-to-SQL 是确定性的、映射到企业语义定义，查询执行也留在 Snowflake 的治理边界内，降低了 schema 幻觉和未验证 SQL 执行的风险。

安全设计上，最关键的一点是避免给模型一个通用服务账号。文章采用 OAuth 2.0 用户模拟，在 Snowflake 建立机密 OAuth 客户端，并按最小权限原则为 agent 创建专用角色。一个重要坑：用户上下文必须在支撑语义视图的物理表上有 SELECT 权限，只授权语义视图会在运行时出错。如果安全策略不允许直接访问底层表，就在物理表上放 Snowflake Secure View，再在其上建 Semantic View。因为视图以 Owner’s Rights 执行，用户的 GenAI 角色只需要 Secure View 和 Semantic View 的 SELECT。另一个坑是 OAuth token 在授权瞬间绑定 DEFAULT_ROLE 和 DEFAULT_WAREHOUSE，所以要先设置默认角色和仓库，再让用户在 Gemini Enterprise 完成授权，之后可以恢复原默认值。

在 Snowflake 侧，用语义视图创建受治理的 Cortex Agent，再配置 MCP server，通过 CORTEX_AGENT_RUN 工具类型暴露。SQL 生成和执行都留在这个治理边界内，不要向外部客户端暴露 SYSTEM_EXECUTE_SQL 这类原始执行工具。然后需要授权访问 server，并通过查询拿到 MCP server 的端点 URL。

在 Google 侧，用 ADK 写 agent 代码，定义一个唯一标识符 AUTH_ID（比如 snowflake_oauth_conn）来提取用户凭据。这只是基础模板，实际部署要自行补充错误处理、结构化 schema、自定义 prompt 等。部署时用 Google Agents CLI（agents-cli），CLI 会打包代码、设置服务、处理部署，最后输出 resource path（如 projects/PROJECT_ID/locations/LOCATION/reasoningEngines/RESOURCE_ID），供注册使用。

最后在 Cloud Console 注册 agent：先从 Snowflake 查询 OAUTH_AUTHORIZATION_ENDPOINT 和 OAUTH_TOKEN_ENDPOINT；然后在 Gemini Enterprise 页面添加 custom agent。配置 Authorization 时，Authorization name 必须与 ADK 代码里的 AUTH_ID 完全一致，Client ID/secret 来自 SYSTEM$SHOW_OAUTH_CLIENT_SECRETS，Authorization URI 需要在端点后追加 &response_type=code 或 ?response_type=code。Snowflake Security Integration 名称只是数据库对象名，无需和 Google Cloud 的授权名称或 AUTH_ID 对齐。

整体思路是把 Gemini 的推理、ADK 的编排和 Snowflake 的治理数据层放在一起，让 Agent 在安全边界内生成并执行 SQL，为业务用户提供自然语言问数能力。