پاسخ کوتاه: در سرور MCP چندمستأجره، انزوای داده یعنی هر کلید فقط به دیتابیس همان مشتری وصل شود — نه «دیتابیس پیش‌فرض با فیلتر». فرقش در سرقت داده است: اگر کلید مشتری A بتواند مدل را به دیتابیس B هدایت کند، مسیر نشت داده باز است. معماری انزوا در ابرک در همین مقاله.
سه لایه انزوای داده در سرور MCP ابرک
- لایه ۱ — مسیریابی دیتابیس: کلید به شناسه مستأجر قفل است؛ سوییچ دیتابیس از درون کلاینت ناممکن است
- لایه ۲ — مدل دسترسی: هر کلید فقط مدل‌های تعریف‌شده را می‌بیند (جدول‌های حساس اصلاً در فهرست نیستند)
- لایه ۳ — لاگ: هر فراخوانی با کلید، کاربر و نتیجه ثبت می‌شود
سند معماری: خادم MCP من Abrak.
عندما يعمل خادم MCP بشكل صحيح على تثبيت متعدد قواعد البيانات، فهذا يعني أن الطلب وصل إلى قاعدة البيانات الصحيحة — لا أن بيانات تلك القاعدة بقيت معزولة عن غيرها. چرا اکثر سرورهای MCP روی ERP چندمستأجره خراب می‌شوند شرح المشكلة الشائعة «لم تُحدَّد أي قاعدة بيانات»؛ وهنا نرى ثلاث طبقات أخرى من العزل تبقى مفتوحة بعد حل تلك المشكلة.
لماذا لا يضمن التوجيه الصحيح العزل الكامل؟
لنفترض أن الطلب وصل فعلاً إلى قاعدة بيانات المستأجر A بشكل صحيح. السؤال التالي هو: بأي مستخدم يرتبط مفتاح MCP الذي أرسل هذا الطلب أصلاً، وما الصلاحيات التي يملكها ذلك المستخدم في قاعدة البيانات نفسها؟ إذا كان المفتاح مرتبطاً بمستخدم نظام (superuser)، فإن قيود السجلات في Odoo (record rule) تُتجاوز أيضاً — وتوجيه قاعدة البيانات لا علاقة له بهذه الطبقة.
كيف يسمّي OWASP هذا الخطر؟
تذكر قائمة OWASP الخاصة بتطبيقات النماذج اللغوية الكبيرة خطرين مترابطين بشكل منفصل: Excessive Agency (عندما يُمنح العامل الذكي صلاحيات أكثر من حاجته الفعلية) وSensitive Information Disclosure (تسرّب بيانات لم يكن من المفترض إتاحتها لتلك المحادثة). وفي خادم MCP متعدد المستأجرين، يلتقي هذان الخطران تماماً عند النقطة التي ينتهي عندها توجيه قاعدة البيانات.
ثلاث طبقات أخرى يجب سدّها
- هوية المفتاح = هوية المستخدم الفعلي. يجب أن يكون ربط مفتاح MCP بمستخدم نظامي مستحيلًا عمدًا، لا مجرد أمر مُوصى به. إن كان ممكنًا، سيفعله أحدهم عاجلًا أم آجلًا.
- قاعدة «الكل ممنوع إلا بإذن» على النماذج، منفصلة عن صلاحيات Odoo. قد يملك المستخدم في Odoo صلاحية الوصول إلى نموذج حساس (لعمله اليومي)، لكن هذا النموذج نفسه يجب ألا يُتاح لمساعد الذكاء الاصطناعي عبر MCP دون قرار صريح — مستويان منفصلان من القرار.
- يجب أن يعلن المسار الخاطئ العنوان الصحيح، لا أن يصمت أو يعطي خطأ عامًا. إذا وصل الطلب إلى عقدة خاطئة، يجب أن يقول الرد «مساحة عملكم ليست هنا، اذهبوا إلى هنا» — لا مجرد 404 صامت يدفع المستخدم إلى محاولة التخمين مجددًا.
كيف تُطبَّق هذه على Odoo؟
الطبقات الثلاث كلها في خادم MCP من Abrak مُنفَّذة بمعزل عن توجيه قاعدة البيانات: يرتبط المفتاح دائمًا بمستخدم عادي، وتُحدَّد قائمة النماذج المسموح بها على المفتاح نفسه (لا باستنتاجها من صلاحيات Odoo)، وكل رفض — بما فيه رفض التوجيه — يُرجع السبب والطبقة الدقيقة عبر explain_denial.
