ربط نموذج لغوي ببيانات حقيقية للأعمال — العملاء والفواتير والمخزون — مسألة أمنية جدية بطبيعة الحال. تفصّل هذه المقالة أربعة مخاطر حقيقية في MCP (Model Context Protocol)، وتبيّن كيف يسدّ كلَّ منها تنفيذٌ جادّ؛ لا للترويج لمنتج، بل كقائمة تحقّق يجب أن تقيّم بها أي خادم MCP (وليس خادم Abrak وحده) قبل ربطه.
الخطر الأول: يكتب النموذج شيئًا لم تُرده
قد يسيء النموذج اللغوي أحياناً فهم الأمر أو يتصرف بإفراط في «المساعدة» — فمثلاً يُلغي طلباً بدلاً من قراءته فقط. الحل الصحيح هو التأكيد على مرحلتين: في الاستدعاء الأول تُعيد كل أداة كتابة معاينة دقيقة للتغيير فقط (أي حقل، من أي قيمة، إلى أي قيمة)، ولا يُطبَّق شيء على قاعدة البيانات حتى يوافق المستخدم صراحة. ملاحظة تقنية مهمة: يجب أن تكون الموافقة موقّعة على نفس وسائط الاستدعاء الأول، وإلا أمكن للنموذج إرسال شيء آخر في المحاولة الثانية وتجاوز تلك الموافقة.
الخطر الثاني: المفتاح يرى أكثر مما يلزم
إذا كان لمفتاح MCP واحد صلاحية الوصول إلى جميع نماذج قاعدة البيانات، فتسرّبه خطر كبير. الحل هو مبدأ أقل الامتيازات على طبقتين: يرتبط المفتاح بمستخدم أودو واحد (فتُطبَّق دائمًا قوائم التحكم بالوصول وقواعد السجلات الخاصة بذلك المستخدم)، وطبقة ثانية مستقلة تحدد أي النماذج يمكن رؤيتها أصلًا عبر مسار MCP — حتى لو كان المستخدم يملك صلاحية الوصول إليها في أودو. طبقتان تعنيان أن خللًا في إحداهما لا يكسر الأخرى.
الخطر الثالث: في خدمة متعددة المستأجرين، يذهب الطلب إلى قاعدة بيانات خاطئة
مصدر قلق خاص ببيئات السحابة متعددة المستأجرين: إذا حدد خادم MCP قاعدة البيانات من ترويسة خاطئة، فقد تصل بيانات شركة إلى مفتاح شركة أخرى. السلوك الصحيح هو تحديد مساحة العمل من اسم مضيف الطلب — وإذا وصل الطلب إلى العقدة الخاطئة، يجب أن يُعيد الرد خطأً صريحًا (لا ردًا فارغًا يبدو «آمنًا» خطأً).
الخطر الرابع: لا أثر لما قام به النموذج
عندما يحدث خطأ، فأول سؤال هو: «من بالضبط، وبأي مفتاح، استدعى ماذا؟» وبدون سجل كامل لكل استدعاء (ناجحًا كان أو مرفوضًا، مع رمز الحالة وسبب الرفض) يبقى هذا السؤال بلا جواب. يجب أن يسجّل السجل الاستدعاء، ولكن ألّا يخزّن الرمز الحساس نفسه أبدًا.
قائمة تحقق قبل ربط أي خادم MCP
قبل منح أي مفتاح MCP لعميل ذكاء اصطناعي، اطرحوا هذه الأسئلة الأربعة: هل الكتابة على مرحلتين بتأكيد بشري؟ هل الصلاحية مقيدة بمستوى المستخدم والنموذج المصرّح به؟ هل يُصدر خطأً صريحاً في حالة تعدد المستأجرين بدلاً من استجابة صامتة؟ هل يُسجَّل كل استدعاء؟ تفاصيل تنفيذ هذه المبادئ الأربعة على أودو في صفحة تطبيق خادم MCP و دليل الاتصال وارد.
ماتریس ریسک؛ کدام تهدید چقدر جدی است
| تهدید | احتمال | شدت اثر | کنترل اصلی |
|---|---|---|---|
| نوشتن ناخواسته توسط مدل | متوسط | بالا | تأیید انسانی برای هر عمل نوشتن |
| دسترسی بیش از حد کلید | بالا | بالا | دامنهٔ حداقلی در سطح مدل و رکورد |
| رسیدن درخواست به مستأجر اشتباه | پایین | بحرانی | گره‌زدن کلید به مستأجر + خطای صریح |
| تزریق دستور از راه محتوا | متوسط | متوسط | محتوای خوانده‌شده داده است، نه دستور |
| نشت در لاگ | متوسط | متوسط | حذف کلید و داده‌ی حساس از لاگ |
تزریق دستور از راه محتوا؛ تهدیدی که کمتر جدی گرفته می‌شود
اگر ایجنت توضیح یک محصول یا متن یک تیکت را می‌خواند، آن متن را یک انسان بیرونی نوشته است. اگر سیستم آن را به‌عنوان دستور تفسیر کند، مهاجم می‌تواند با نوشتن یک جملهٔ ساده در فرم تماس، رفتار ایجنت را تغییر دهد. قاعدهٔ محافظ ساده است: هر چیزی که از دیتابیس خوانده می‌شود داده است و هرگز نباید مثل دستور اجرا شود — و ابزارهای نوشتن باید مستقل از متن ورودی، تأیید بخواهند.
حداقل کنترل‌ها پیش از اتصال به داده‌ی واقعی
- دسترسی خواندنی پیش‌فرض؛ نوشتن فقط با تأیید صریح.
- سقف نرخ روی هر کلید، تا حلقهٔ اشتباه به فاجعهٔ مالی تبدیل نشود.
- ثبت ممیزی کامل: چه پرسیده شد، چه خوانده شد، چه تغییر کرد.
- تست با دو مستأجر هم‌زمان، چون باگ‌های جداسازی با یک مستأجر ظاهر نمی‌شوند.
جزئیات احراز هویت در Bearer یا OAuth 2.1، معماری چندمستأجره در چرا سرورهای MCP خراب می‌شوند و چک‌لیست عملیاتی در امنیت کلیدهای MCP.
هوش مصنوعی و MCP؛ ادامهٔ مسیر
از مبانی MCP و انتخاب مدل تا کاربردهای عملی روی اودو.
- MCP (Model Context Protocol) چیست؟ راهنمای کامل برای کسب‌وکار ایرانی
- هوش مصنوعی در کسب و کار ایرانی؛ راهنمای عملی ERP + AI
- هوش مصنوعی اودو (Odoo AI) چیست؟ راهنمای کامل AI Agent و AI Composer
- GPT یا Claude یا Gemini برای کسب‌وکار شما؟
- OIDC یا SAML برای ورود یکپارچه ERP؟
- راهنمای کاربری تلفن ابری ابرک: از نصب تا اولین تماس
