وقتی یک سرور MCP روی نصب چنددیتابیسی درست کار میکند، یعنی درخواست به دیتابیس درست رسیده — نه اینکه دادهی آن دیتابیس از بقیه ایزوله مانده. مقالهی قبلی مشکل رایج «هیچ دیتابیسی انتخاب نشده» را توضیح داد؛ اینجا سه لایهی دیگرِ انزوا را میبینیم که بعد از حل آن مشکل هنوز باز میمانند.
چرا مسیریابی درست، انزوا را تضمین نمیکند؟
فرض کنید درخواست درست به دیتابیس مستأجر A رسیده. سؤال بعدی این است: کلید MCP که این درخواست را زده، اصلاً به کدام کاربر وصل است، و آن کاربر در همان دیتابیس چه دسترسیای دارد؟ اگر کلید به یک کاربر سیستمی (superuser) وصل باشد، محدودیت رکورد اودو (record rule) هم دور زده میشود — مسیریابی دیتابیس هیچ ربطی به این لایه ندارد.
OWASP این خطر را چه مینامد؟
فهرست OWASP برای اپلیکیشنهای مبتنی بر مدل زبانی بزرگ، دو ریسک مرتبط را جدا نام میبرد: Excessive Agency (وقتی عامل هوش مصنوعی اجازهی بیش از نیاز واقعیاش دارد) و Sensitive Information Disclosure (نشت دادهای که قرار نبوده در دسترس همان مکالمه باشد). در یک سرور MCP چندمستأجر، این دو دقیقاً همانجایی به هم میرسند که مسیریابی دیتابیس تمام میشود.
سه لایهی دیگر که باید بسته شود
- هویت کلید = هویت کاربر واقعی. وصلکردن یک کلید MCP به کاربر سیستمی باید عمداً غیرممکن باشد، نه فقط توصیهشده. اگر ممکن باشد، دیر یا زود کسی همین کار را میکند.
- «همه ممنوع مگر مجاز» روی مدلها، جدا از ACL اودو. کاربر ممکن است در اودو به یک مدل حساس دسترسی داشته باشد (برای کار روزمرهاش)، ولی همان مدل نباید بدون تصمیم صریح، از مسیر MCP هم در دسترس دستیار هوش مصنوعی باشد — دو سطح تصمیم جدا از هم.
- مسیر اشتباه باید نشانی درست را اعلام کند، نه سکوت یا خطای عمومی. اگر درخواست به نود اشتباه برسد، پاسخ باید بگوید «فضای کاری شما اینجا نیست، اینجا برو» — نه فقط ۴۰۴ ساکت که کاربر را به تلاش دوباره با حدس وامیدارد.
روی اودو اینها چطور پیاده میشوند؟
هر سه لایه در سرور MCP ابرک جدا از مسیریابی دیتابیس پیاده شدهاند: کلید همیشه به یک کاربر عادی وصل میشود، فهرست مدلهای مجاز روی خودِ کلید تعریف میشود (نه استنتاج از دسترسی اودو)، و هر رد شدن — از جمله رد شدن مسیریابی — دلیل و لایهی دقیق را با explain_denial برمیگرداند.
