Google Cloud 於二零二六年十月二十八日在官方雲端網誌刊出技術指引，說明如何以 Google Agent Development Kit（ADK）與 Model Context Protocol（MCP），把 Gemini Enterprise 安全橋接至 Snowflake 數據倉：以自然語言提問，經 Snowflake Cortex Agent 產生並執行 SQL，並沿用登入用戶的 OAuth 工作階段與角色權限，查詢留在 Snowflake 管治邊界內。來源真實性已驗證：已對照 Google Cloud Blog 原文日期、作者與架構步驟，數字與產品名稱均來自該官方頁面，未另作臆測。

Google Cloud／官方：以 ADK 與 MCP 安全連接 Gemini Enterprise 與 Snowflake——OAuth 用戶層權限；SQL 經 Cortex 在倉內執行

企業 AI 若只停留在聊天介面，難以為業務產生可行動洞察；一旦代理要讀取數據倉，又必須守住身分、角色與資料管治。Google Cloud 工程師 Pankaj Bajpai、Abhilash Adavi 於同日發布的指引，示範以 Gemini Enterprise 作為工作入口、ADK 負責編排、Snowflake MCP 伺服器暴露受管 Cortex Agent，避免把原始 SQL 執行權直接暴露給客戶端。以下整理可核對要點、技術機制，以及對香港與亞洲企業數據 AI 落地的啟示。

一、核心事件：官方示範「代理問數、倉內執行」

產品與架構要點

據 Google Cloud Blog（二零二六年十月二十八日）：

場景：業務用戶可用自然語言提問，例如「上季德克薩斯州銷量最高的五件商品是甚麼？」
橋接元件：Gemini Enterprise ＋ Google ADK ＋ MCP；Snowflake 端以 Cortex Agent（CORTEX_AGENT_RUN）與 Cortex Analyst 語義視圖處理 text-to-SQL。
權限模型：採 OAuth 2.0 用戶模擬（user impersonation），而非以寬鬆的共用服務帳戶讓模型「一把鑰匙開全倉」。
執行邊界：SQL 產生與執行留在 Snowflake 管治邊界內，再把結構化結果交回 ADK 代理；官方強調此舉有助對應企業語義定義，並降低綱要幻覺或未驗證 SQL 外洩的風險。
模式取捨：文中示範屬進階／自訂編排，適合多代理、跨工具與 Gemini Agent Engine 等複雜流程；一般直接連接場景則指向既有的 Gemini Enterprise–Snowflake 聯合方案。
示範模型與套件版本（文中範例）：ADK 代理示例使用 gemini-2.5-flash；依賴示例列出 google-adk[mcp]==2.3.0 等套件。本文僅轉述官方代碼示例所載版本，不另行推斷生產強制版本。

二、技術原理深度解析

官方把風險核心寫得很直白：若以泛用服務帳戶授予模型寬鬆存取，等於讓終端用戶有機會繞過原有安全限制。對策是把「誰在問」與「能看甚麼」綁回 Snowflake 既有角色。

身分與權杖

在 Snowflake 建立機密型（CONFIDENTIAL）自訂 OAuth 用戶端；重新導向 URI 使用 Google Cloud 官方交接位址（vertexaisearch.cloud.google.com 的 oauth-redirect）。
重新整理權杖有效期示例設為 7,776,000 秒（九十日），文中註明此為 Snowflake 允許上限。
Gemini Enterprise 在授權後把用戶權杖注入 ToolContext；ADK 範例以固定 AUTH_ID（例如 snowflake_oauth_conn）對應主控台「Authorization name」，再以 Bearer 標頭呼叫 Snowflake MCP。

最小權限與語義層

另建專用 GenAI 角色，僅授與資料庫／綱要 USAGE、倉 USAGE、語義視圖 SELECT／REFERENCES，以及底層表（或 Secure View）的必要 SELECT。
官方警告：若只授語義視圖、未授底層實體表權限，執行時會出錯；若政策不允許直接授表，可在實體表上建 Secure View，再於其上建語義視圖——因視圖以 Owner's Rights 執行，GenAI 角色只需對 Secure View 與語義視圖有 SELECT。
OAuth 權杖會在授權當下綁定用戶的 DEFAULT_ROLE 與 DEFAULT_WAREHOUSE；授權前須先設好預設值，否則工作階段可能鎖在錯誤角色。

MCP 與編排

在 Snowflake 以語義模型設定 Cortex Agent，再建立 MCP Server，工具類型為 CORTEX_AGENT_RUN。
官方明確建議避免向外部客戶端暴露 SYSTEM_EXECUTE_SQL 一類原始執行工具，以免繞過 Cortex Agent 集中管治。
ADK 以 McpToolset 連接 MCP URL（由 DESCRIBE MCP SERVER 取得），部署可用 agents-cli deploy --deployment-target agent_runtime，再於 Gemini Enterprise 註冊自訂代理並對齊 OAuth 端點與 Client 憑證。

整體而言，這是「推理在 Google 側、語意轉譯與查詢執行在 Snowflake 側、權限跟用戶走」的信任邊界切分，而不是把整倉憑證交給單一聊天機械人。

三、日常應用場景

1. 開發者與技術團隊

若你正在以 ADK／MCP 組裝企業代理，可把此文當作管治清單：OAuth 用戶模擬、AUTH_ID 對齊、語義視圖與 Secure View、禁止原始 SQL 工具外露、Agent Runtime 部署路徑。重點不是複製貼上示例代碼，而是把「工具呼叫鏈」畫進威脅模型。

2. 企業與隱私敏感行業

金融、零售、醫療與控股公司若已在 Snowflake 落地倉儲，又希望以 Gemini Enterprise 作為員工入口，此架構提供一條可對外說明的路徑：查詢仍受角色與語義層約束，代理不必持有「超管服務帳戶」。採購與資安應一併檢查權杖壽命、預設角色鎖定、以及哪些問題允許進入 Cortex Analyst。

3. 一般用戶

對前線同事而言，體驗接近「用中文／英文問業務數據」；背後仍是企業帳號授權與倉內權限。用戶不應假設聊天介面等於已獲全部表的存取，亦不宜在提示中貼上密碼或未授權個資。

4. 香港與亞洲市場視圖

香港企業普遍同時使用公有雲分析棧與本地合規要求（客戶數據、跨境傳輸、審計軌跡）。此模式把「AI 編排」與「數據執行」拆開，有利於對照內部數據分類與最小權限政策；若機構更傾向數據不出境或私有模型，亦可把同一管治思路對照私有 LLM 與自建檢索／代理架構，而非只依賴單一公有聊天產品。

四、專業評價與潛在考量

優勢

來源為 Google Cloud 官方技術網誌，日期、作者、元件名稱與步驟可核對。
明確反對寬鬆服務帳戶，改以 OAuth 用戶層權限與 Cortex 管治邊界，對企業採購敘事清楚。
同時標示進階 ADK 編排與較簡單的聯合直連路徑，避免「只有一種接法」的誤導。

需要留意的地方

此文是架構與實作指引，並非一次性產品發表會；未公布客戶數、延遲基準或定價，本文不臆測。
示例依賴與模型版本屬文中代碼快照，升級 ADK／Gemini／Snowflake MCP 時須自行回歸測試。
OAuth 預設角色綁定、語義視圖與底層表權限若設定不當，會直接導致執行失敗或權限過寬——落地成敗在管治，不在示範截圖。
指引假設組織已能運維 Snowflake Cortex／MCP 與 Google Agent Runtime；中小團隊仍須評估維運成本。

結語

Google Cloud 以 ADK、MCP 與 Snowflake Cortex Agent，示範把 Gemini Enterprise 接到受管數據倉：自然語言進、SQL 在倉內出，權限跟 OAuth 用戶走。對正在規劃代理人式數據助理的企業，這比「把倉密鑰塞進提示」更接近可審計的工程做法。若你希望在香港以私有模型、資料不出境的方式打造企業 AI 與自動化流程，可參考 YSK Limited 的企業私有 LLM 全託管與 AI 自動化服務（年費由 HK$88,000 起）：https://ysk.hk/services/ai-automation

參考來源

Google Cloud Blog（Pankaj Bajpai、Abhilash Adavi，2026-10-28）：https://cloud.google.com/blog/products/data-analytics/bridge-gemini-enterprise-and-snowflake-with-google-adk/