‏قسمت سخت گیت‌وی MCP، پروتکل نیست

میهای پارپاریتا از Sierra گزارشی از ساخت گیت‌وی داخلی MCP این شرکت منتشر کرده که الان ۸۹٪ کارمندهاشون رو از یه صفحه به ۴۵ سرویس مختلف وصل می‌کنه. مقاله‌ی WorkOS که این گزارش رو بررسی کرده می‌گه بخش نمایشی و جذاب ماجرا همین اتصال‌هاست، ولی بخش واقعاً سخت که زیر آب مونده، هویت، دسترسی به ازای هر ابزار، رضایت کاربر و لاگ حسابرسیه؛ چیزهایی که به MCP ربط چندانی ندارن.

طبق گزارش Sierra، چیزی که راه‌اندازی گیت‌وی رو ممکن کرد، سیستم کنترل دسترسی و حسابرسی زیرش بود، نه خود گیت‌وی. برای جلوگیری از دیدن داده‌ی مشتری‌ها توسط همدیگه، یه سیستم چندمرحله‌ای ساختن: یه فاز قطعی مشتری‌های احتمالی رو پیشنهاد می‌ده، یه مدل سریع لیست رو کوچیک می‌کنه، و یه مدل کندتر تصمیم می‌گیره داده مال کدوم مشتریه و چقدر حساسه. همه‌ی این‌ها با یه لاگ حسابرسی همراهه که از دسترسی هم‌زمان به داده‌ی دو مشتری تو یه سشن جلوگیری می‌کنه.

بقیه‌ی سیستم استانداردتره: هویت کاربر به هر فراخوانی ابزار می‌رسه، مجوزها به ازای هر ابزار (نه هر سرور) چک می‌شن، و هر کوئری بر اساس سازمان فیلتر می‌شه. طبق قانون Sierra، کارهای تعاملی با هویت خود کاربر اجرا می‌شن، ولی کارهای زمان‌بندی‌شده یا مشترک باید با سرویس‌اکانت‌هایی اجرا بشن که فقط دسترسی لازم رو دارن -- چون وگرنه یه اتومیشن ممکنه بعد از تغییر نقش یه کارمند، همچنان با دسترسی قدیمیش کار کنه.

یه نکته‌ی جالب دیگه اینه که Sierra برای GitHub و AWS به‌جای پراکسی کردن کل سرور MCP، مستقیم از CLIهای gh و aws استفاده کرده، چون مدل‌های زبانی از قبل این ابزارها رو خوب می‌شناسن. برای این‌که این کار امن بمونه، یه توکن گیت‌هاب جداگانه با دسترسی فقط‌خواندنی به ریپوهای خاص ساختن؛ یعنی حتی وقتی از پروکسی رد نمی‌شی، بازم باید یه جایی محدودیت دسترسی رو اعمال کنی.

نویسنده نتیجه می‌گیره که بازار گیت‌وی‌های MCP دارن روی بخش آسون یعنی وصل کردن سرویس‌ها تمرکز می‌کنن، در حالی که بخش سخت -- هویت، مجوز به ازای ابزار، رضایت و حسابرسی -- همونیه که هر تیمی باید واقعاً روش سرمایه‌گذاری کنه. پیشنهادش اینه که بخش اختصاصی خودتون رو خودتون بسازین، ولی زیرساخت هویت و حسابرسی رو به‌جای بازسازی از صفر، از یه پلتفرم آماده بخرین.

نکات کلیدی:

• گیت‌وی MCP داخلی Sierra الان ۸۹٪ کارمندهای این شرکت رو به ۴۵ سرویس مختلف وصل می‌کنه
• بخش سخت پروژه هویت، مجوز به ازای ابزار، رضایت و حسابرسی بود، نه خود پروتکل MCP
• برای جدا نگه‌داشتن داده‌ی مشتری‌ها یه کلاسیفایر چندمرحله‌ای با لاگ حسابرسی ساختن
• کارهای تعاملی با هویت کاربر و کارهای زمان‌بندی‌شده با سرویس‌اکانت کم‌دسترسی اجرا می‌شن
• برای GitHub و AWS از CLI اصلی استفاده کردن، با توکن‌های محدودشده به‌جای پراکسی کامل
• نسخه‌ی جدید اسپک MCP، ثبت پویای کلاینت (DCR) رو به نفع Client ID Metadata Documents کنار گذاشته