‏اتصال امن Gemini Enterprise به داده‌های Snowflake با ADK و MCP

تو این پست از بلاگ گوگل کلاد، نویسنده‌ها توضیح می‌دن چطور می‌شه Gemini Enterprise رو به Snowflake وصل کرد تا کاربر سؤالی مثل «۵ محصول پرفروش ما تو تگزاس فصل پیش چی بودن؟» بپرسه و جواب واقعی از انبار داده بگیره. ابزارهای اصلی Model Context Protocol (یعنی پروتکل استانداردی که ایجنت‌ها باهاش به ابزارها و داده‌ها وصل می‌شن) و Google ADK (کیت توسعه‌ی ایجنت گوگل) هستن. به گفته‌ی نویسنده‌ها این الگو برای سیستم‌های پیچیده و چندایجنتیه؛ برای وصل کردن ساده، راه‌حل‌های مشترک آماده‌ی دو شرکت کافیه.

نکته‌ی اصلی معماری اینه که ایجنت ADK خودش SQL نمی‌سازه و اجرا نمی‌کنه. سؤال کاربر از طریق سرور MCP مدیریت‌شده‌ی Snowflake به یه Cortex Agent داده می‌شه (ابزار CORTEX_AGENT_RUN). این ایجنت روی یه semantic view کار می‌کنه، یعنی لایه‌ای که تعریف‌های تجاری شرکت مثل «فروش» یا «منطقه» رو به جدول‌ها و ستون‌ها وصل می‌کنه. Cortex سؤال رو به SQL تبدیل می‌کنه و همون‌جا داخل Snowflake با سشن OAuth خود کاربر اجراش می‌کنه. نتیجه اینه که ترجمه‌ی متن به SQL قابل پیش‌بینی‌تره، مدل ستون‌های خیالی نمی‌سازه و کوئری هیچ‌وقت از مرز امنیتی Snowflake بیرون نمی‌ره.

به گفته‌ی نویسنده‌ها بزرگ‌ترین ریسک تو AI سازمانی اینه که به مدل از طریق یه service account عمومی دسترسی گسترده بدید، چون این‌طوری کاربرها می‌تونن محدودیت‌های امنیتی رو دور بزنن. راه‌حل اینه که با OAuth 2.0 کار user impersonation انجام بشه، یعنی ایجنت دقیقاً با هویت و نقش همون کاربر کوئری می‌زنه. برای این کار یه confidential OAuth client داخل Snowflake ساخته می‌شه و طبق اصل حداقل دسترسی یه role جدا برای ایجنت تعریف می‌شه. نویسنده‌ها صریحاً توصیه می‌کنن ابزارهای اجرای خام مثل SYSTEM_EXECUTE_SQL رو به کلاینت بیرونی ندید.

چند تا نکته‌ی عملی هم هست که اگه ندونید به خطا می‌خورید. اول، کاربر باید روی جدول‌های فیزیکی پشت semantic view دسترسی SELECT داشته باشه، وگرنه موقع اجرا خطا می‌گیره. اگه سیاست امنیتی اجازه نمی‌ده، می‌شه یه Secure View روی جدول‌ها گذاشت، چون viewها با دسترسی مالک اجرا می‌شن. دوم، توکن OAuth در Snowflake همون لحظه‌ی تأیید، DEFAULT_ROLE و DEFAULT_WAREHOUSE کاربر رو قفل می‌کنه. پس باید قبل از تأیید اتصال تو Gemini این پیش‌فرض‌ها درست تنظیم شده باشن؛ بعدش می‌شه برشون گردوند.

بقیه‌ی مسیر اینه: ساخت Cortex Agent و سرور MCP، پیدا کردن URL سرور، نوشتن کد ایجنت با ADK در پایتون، دیپلوی روی Agent Runtime با ابزار agents-cli و در آخر ثبت ایجنت تو کنسول Gemini Enterprise. موقع ثبت، اسم authorization تو کنسول باید دقیقاً با AUTH_ID تو کد پایتون یکی باشه. Authorization URI هم باید با پارامتر response_type=code تموم بشه تا جریان OAuth راه بیفته. اسم security integration تو Snowflake ولی لازم نیست با این‌ها یکی باشه.

نکات کلیدی:

• ایجنت ADK خودش SQL نمی‌سازه؛ تولید و اجرای کوئری به Cortex Agent داخل Snowflake سپرده می‌شه
• اتصال از طریق سرور MCP مدیریت‌شده‌ی Snowflake با ابزار CORTEX_AGENT_RUN انجام می‌شه
• کوئری‌ها با OAuth 2.0 و نقش خود کاربر اجرا می‌شن، نه با service account مشترک
• کاربر باید روی جدول‌های پایه‌ی semantic view دسترسی SELECT داشته باشه یا از Secure View استفاده بشه
• توکن OAuth نقش و warehouse پیش‌فرض رو لحظه‌ی تأیید قفل می‌کنه، پس اول پیش‌فرض‌ها رو تنظیم کنید
• AUTH_ID تو کد باید دقیقاً با اسم authorization تو کنسول Gemini Enterprise یکی باشه