النقاش حول MCP يتحرك بسرعة، لكن الإشارة البحثية أصبحت أوضح من الكلام التسويقي نفسه.

بحلول 28 مارس 2026 لم يعد السؤال المهم هو: هل يمكن إساءة استخدام agents المتصلة بالأدوات؟ الأدبيات تجاوزت هذه المرحلة أصلًا. السؤال الأهم الآن هو: هل تبني الفرق الـ host وطبقات الموافقة وسياسات الأدوات وهي تفترض أن الإساءة ستحدث فعلًا؟

الأدبيات تتقارب أسرع مما تتحرك به فرق المنتجات

إذا أردت أقصر قائمة جادة للقراءة، فابدأ من خمس صفحات أوراق على Hugging Face:

هذه الأوراق لا تستخدم المنهج نفسه، ولا تركز على السطح ذاته، لكن الرسالة التشغيلية المشتركة بينها واضحة: هيكلة البروتوكول مفيدة، لكنها لا تصنع السلوك الموثوق وحدها.

الاتفاق الأول: الأداة الخبيثة ليست هامشًا في القصة

من أكثر الأخطاء شيوعًا في تصميم الـ agents التعامل مع اختراق الأداة وكأنه شذوذ نادر. الأدلة البحثية لا تدعم هذا الاطمئنان.

MCP Safety Audit وضع الخطر في مكانه الصحيح: عندما يستطيع الوكيل قراءة الأدوات واستدعاءها عبر واجهة مشتركة، فإن أي حد هش بين نية الموديل وسياسة الـ host يصبح قابلًا للاستغلال. ثم جاءت ورقة Beyond the Protocol لتدفع الفكرة أبعد: المشكلة لا تتوقف عند Prompt ملوث أو Server واحد، بل تمتد إلى المنظومة نفسها عبر registries والموارد الخارجية وافتراضات الثقة التي تسافر أبعد مما تتوقعه الفرق.

وهذا مهم لأن كثيرًا من الفرق ما زالت تفكر هكذا:

  • أمّن الموديل
  • راجع الـ prompt
  • نظّف الاستجابة

لكن عنقود أبحاث MCP يقول إن هذا غير كافٍ. يجب أن تسأل أيضًا:

  • من أين جاءت الأداة؟
  • من يملك قناة تحديثها؟
  • ما الموارد الأخرى التي قد تؤثر في سلوكها؟
  • ماذا يحدث إذا كانت الأداة خبيثة لكنها تبدو صحيحة شكليًا؟

هذه ليست نظافة نظرية. هذه مسألة بقاء منتج.

الاتفاق الثاني: السياسة يجب أن تُفرض خارج الموديل

هنا تصبح الأدبيات متماسكة بشكل لافت.

الأعمال ذات الزاوية المؤسسية والتحليلات الأمنية الأوسع تتعامل مع التطبيق المستضيف بوصفه control plane الفعلي. الموديل قد يقترح استخدام الأداة، لكنه لا يصلح لأن يكون policy engine نهائيًا للأفعال عالية الخطورة.

وهذا يعني أن الحد الفاصل الجاد ليس “الأداة متاحة” أو “الأداة معطلة”، بل حد طبقي:

  1. ما الذي يُسمح للموديل أن يراه
  2. ما الذي يُسمح له أن يقترحه
  3. ما الذي يُسمح له أن ينفذه تلقائيًا
  4. ما الذي لا يتحرك إلا بموافقة بشرية صريحة

وهذا ينسجم مباشرة مع ما طرحناه سابقًا في دليل حدود الصلاحيات، لكن وجود هذا الأثر البحثي يجعل تجاهله أصعب بكثير. إذا كانت السياسة تعيش أساسًا داخل الـ prompt، فالنظام يظل هشًا. وإذا كانت السياسة تعيش في الـ host، فالنظام يستطيع الرفض فعلًا.

الاتفاق الثالث: Prompt Injection صار مشكلة منظومية

في كثير من النقاشات التقليدية حول Prompt Injection يجري التركيز على مستند ملوث أو سلسلة تعليمات واحدة. أوراق MCP توسع العدسة.

عندما تتصل الأدوات والموارد وأوصاف الخوادم والـ registries وworkflows الوكلاء في مسار واحد، يمكن للتعليمات الخبيثة أن تصل عبر أكثر من قناة. الأداة الخبيثة لا تحتاج إلى أن تبدو خبيثة بشكل ساذج إذا كان بإمكانها التأثير في فهم الوكيل للحدود أو الأولوية أو منطق الموافقة.

ولهذا تصبح جودة الوصف جزءًا من الأمن نفسه. كنا قد ناقشنا في تحليل أوصاف أدوات MCP أن وصف الأداة ليس metadata صامتة بل مدخل سلوكي فعّال. أوراق الأمن تعزز هذه النقطة من الجهة المقابلة: الحدود الضبابية تسهّل التلاعب بسطح الهجوم.

عمليًا هذا يعني أن الفرق يجب أن تراجع هذه الطبقات كما تراجع الكود:

  • أوصاف الأدوات
  • تعريفات الخوادم
  • إدخالات الـ registry
  • الموارد الخارجية المرتبطة
  • نصوص الموافقة التي يراها المشغّل

إذا كان أحد هذه الأسطح رخوًا، فأنت تطلب من الموديل أن يرتجل فوق عقد ضعيف.

الاتفاق الرابع: التقييم على المسار السعيد لم يعد كافيًا

من أهم مساهمات أوراق 2025 أنها تنقل النقاش من القلق النظري إلى التقييم الخصومي.

Systematic Analysis of MCP Security جعل مساحة الهجوم مقروءة. ثم جاءت ورقة Automatic Red Teaming LLM-based Agents with Model Context Protocol Tools لترفع الضغط أكثر عبر إظهار كيف يمكن استكشاف هذه المساحة آليًا وبشكل متكرر. والرسالة المشتركة بينهما مباشرة:

إذا كان تقييمك يختبر فقط قدرة الـ agent على إنهاء المهمة المقصودة، فاختبارك سهل أكثر مما يجب.

الفرق الجادة تحتاج على الأقل إلى أربع طبقات اختبار:

  • النجاح في المهمة الطبيعية
  • الفشل المنضبط عند تجاوز الحدود
  • سيناريوهات خصومية للأدوات والموارد
  • قابلية التدقيق بعد وقوع المشكلة

والنقطة الأخيرة مظلومة كثيرًا. النظام الجيد ليس فقط ما يمنع كل فشل، بل ما يترك traces كافية تجعل الفريق يفهم ما حدث وكيف حدث.

مقتطف شيفرة

json 

    {
  "toolDefaults": "read-only",
  "highRiskMutations": "explicit approval required",
  "thirdPartyServers": "scoped and reviewed",
  "registries": "audited before enablement",
  "incidentTraces": "replayable and retained"
}

ما الذي ما زالت الأوراق لا تحسمه؟

الإشارة البحثية قوية، لكنها لا تحسم كل شيء.

ما زالت هناك أسئلة مفتوحة حول:

  • الهوية والتفويض في الأنظمة متعددة الوكلاء
  • سياسة الثقة والتحديث في registries العامة
  • تصميم واجهات موافقة مفهومة لغير الخبراء
  • الكلفة الواقعية للـ red teaming المستمر داخل المنتجات الحية

وهذه نقطة مهمة لأن بعض الفرق قد تقرأ الأدبيات وتتصور أن checklist نظيفة تكفي. هذا غير صحيح. الأوراق الحالية ترسم خريطة أقوى للمشكلة، لكنها لا تقدم معمارية نهائية مغلقة.

ماذا تغيّر هذه الأدبيات في قرارات الإطلاق اليوم؟

لو كنت أراجع منتجًا مبنيًا على MCP اليوم، فسأعتبر هذه الافتراضات حدًا أدنى:

  • كل أداة جديدة تبدأ كقراءة فقط
  • الأفعال ذات blast radius عالٍ تُمنع أو تُربط بموافقة صريحة
  • الثقة في الخوادم والـ registries تُعامل كمسألة supply chain حية
  • أوصاف الأدوات تُراجع بصيغة contract لا كنص تجميلي
  • سجلات التدقيق تحفظ من وافق، وعلى ماذا، وأين، ومتى
  • الاختبارات الخصومية جزء من الجاهزية للإطلاق لا رفاهية مؤجلة

هذا ليس تهويلًا. هذا هو الحد الأدنى بعد أن بدأت الأدبيات تتقارب بهذا الوضوح.

الخلاصة

أهم درس تمنحه أوراق أمن MCP ليس أن الـ agents المتصلة بالأدوات مخيفة. هذا عرفناه منذ البداية.

الدرس الأهم أن الخطر صار مقروءًا: أدوات خبيثة، أسطح منظومية مسمومة، سياسات host رخوة، وتقييمات سطحية. هذه لم تعد مخاوف ضبابية، بل أنماط متكررة.

الفرق التي ستطلق بمسؤولية في 2026 لن تنتظر من البروتوكول أن ينقذها. ستبني السياسة والموافقة وإمكانية التتبع والاختبار الخصومي حول البروتوكول قبل أن تطلب من السوق أن يثق بها.