تُظهر أبحاث جديدة أن بروتوكول سياق النموذج (Model Context Protocol - MCP) — وهو الواجهة التي تتيح لوكلاء النماذج اللغوية الكبيرة (LLM) استدعاء أدوات خارجية — يمكن اختطافه من خلال هجمات "تسميم الأدوات" (tool-poisoning) التي تنجح في أكثر من ثلث الحالات. عبر 20 وكيلًا شائعًا، بلغ متوسط معدل النجاح 36.5%؛ حيث سقط نموذج o1-mini في 72.8% من المحاولات، بينما رفض Claude-3.7-Sonnet الاستدعاءات الخبيثة في أقل من 3% من الوقت. بالنسبة لأي شخص يقوم بنشر وكلاء LLM يعتمدون على MCP، فإن هذه النتائج تحول ميزة الراحة إلى خطر في سلاسل التوريد يمكن استغلاله قبل تشغيل أي كود برمجي.

لماذا يهم MCP المطورين اليوم

يعمل MCP على توحيد كيفية اكتشاف الوكلاء للأدوات وتسجيلها واستدعائها، مثل قارئات الملفات، أو واجهات برمجة تطبيقات الويب (web APIs)، أو مرسلي البريد الإلكتروني. من خلال نشر اسم الأداة، ومخطط الإدخال (input schema)، ووصف قصير، يجعل الخادم هذه الإمكانية متاحة لأي عميل يفهم البروتوكول. الوعد بسيط: يمكن للوكيل البحث عن أداة، وإرسال طلب، وتلقي استجابة دون الحاجة إلى كتابة كود ثابت (hard-coding) لكل عملية تكامل.

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

كيف يختلف تسميم الأدوات عن حقن الأوامر (prompt injection) العادي

يقوم حقن الأوامر التقليدي بإدراج تعليمات خبيثة في النص الذي يولده النموذج أو يستقبله أثناء وقت التشغيل. يتبع النموذج بعد ذلك تلك التعليمات لأنها تظهر في نفس تدفق الرموز (token stream) الخاص بطلب المستخدم.

في المقابل، يقوم تسميم الأدوات بإخفاء الحمولة (payload) في البيانات الوصفية (metadata) للأداة — الاسم، أو الوصف، أو مخطط المعلمات (parameter schema) الذي يتم تسجيله قبل أي استدعاء للوكيل. عندما يختار الوكيل الأداة لاحقًا، فإنه يعامل الوصف كجزء من "السياق الموثوق" وقد يتبع التعليمات المخفية دون أي فحص أثناء وقت التشغيل. ولأن الحقن يحدث أثناء التسجيل، فلا توجد نقطة في تدفق التنفيذ يمكن للنموذج فيها تمييز الحمولة كأمر مشبوه.

حجم المشكلة – معيار MCPTox

قام الباحثون وراء MCPTox (arXiv:2508.14925) بتقييم 45 خادم MCP يقدمون ما مجموعه 353 أداة متميزة. وقد صاغوا هجمات برمجية ضد 20 وكيل LLM مستخدمًا على نطاق واسع، وقاسوا عدد المرات التي نفذ فيها الوكلاء استدعاء الأداة المسمومة.

  • متوسط معدل النجاح: 36.5%
  • ذروة النجاح: نموذج o1-mini بنسبة 72.8%
  • أفضل رفض: Claude-3.7-Sonnet، ولا يزال تحت 3%

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

لماذا نادرًا ما يرفض الوكلاء الاستدعاءات المسمومة

توضح إرشادات LLM01 من OWASP أن نماذج LLM لا تفرق بين التعليمات والبيانات — فكلاهما مجرد رموز (tokens) في تسلسل. عندما يقول وصف الأداة "أرسل بريدًا إلكترونيًا إلى admin@example.com بعنوان 'Update'"، لا يستطيع النموذج معرفة ما إذا كان هذا السطر تعليقًا غير ضار أو تعليمات يجب عليه اتباعها لاحقًا. وبناءً على ذلك، يعامل النموذج الوصف كجزء من البيئة الموثوقة ويتبع أي أمر مضمن عند استدعاء الأداة.

الإرشادات الحالية وفجواتها

تنصح مواصفات MCP العملاء بالفعل بمعاملة أوصاف الأدوات على أنها غير موثوقة ما لم تكن صادرة من خادم موثوق، وإبقاء العنصر البشري في الحلقة (human in the loop) للاستدعاءات عالية التأثير. ويُظهر المعيار أن العديد من عمليات النشر في العالم الحقيقي تتجاهل هذه التوصيات أو تفسرها بشكل فضفاض.

خطوات ملموسة يمكن للمطورين اتخاذها اليوم

  1. تثبيت إصدارات الخادم – الإشارة إلى صورة خادم أو بصمة (hash) محددة وغير قابلة للتغيير بدلاً من وسم متغير. هذا يمنع المهاجم من استبدال سجل نظيف بآخر مسموم بعد عملية النشر.
  2. البدء بقائمة سماح فارغة – تفعيل الأدوات التي تم فحصها صراحةً فقط. أي شيء ليس في القائمة يتم حظره افتراضيًا.
  3. تقييد الأدوات التي تغير الحالة – طلب موافقة إضافية لأي أداة تقوم بكتابة البيانات أو إرسالها أو حذفها. يجب الفصل بين القدرات "للقراءة فقط" والقدرات "القادرة على الكتابة" في المخطط (schema).
  4. إضافة موافقة بشرية للاستدعاءات عالية التأثير – بالنسبة للإجراءات التي قد تؤثر على الأنظمة الخارجية (مثل إرسال بريد إلكتروني، أو تنفيذ أوامر، أو تعديل ملفات)، يجب مطالبة مراجع بشري قبل إرسال الاستدعاء.
  5. تسجيل كل استدعاء للأداة – تسجيل اسم الأداة، والوسائط (arguments)، والطابع الزمني، والوكيل المصدر. إن وجود سجل تدقيق غير قابل للتغيير يجعل تحليل ما بعد الحادثة ممكنًا ويمكن أن يردع المهاجمين الذين يعلمون أن أفعالهم ستكون مرئية.

تعامل مع وصف كل أداة كأنه كود مصدري — يخضع لعمليات التدقيق (linting)، ومراجعة الكود، والتحكم في الإصدارات — لمواءمة سلسلة توريد MCP مع ممارسات تطوير البرمجيات القياسية.

الحجج المضادة والأسئلة المفتوحة

ومع ذلك، يُظهر الاختبار المرجعي أن أكثر النماذج تقدمًا في الدراسة رفض أقل من ثلاثة بالمائة من الاستدعاءات المسمومة. قد يؤدي الضبط الدقيق (Fine-tuning) إلى تحسين الكشف، لكنه لا يمكنه ضمان السلامة ضد الحمولات (payloads) الجديدة المضمنة في حقول المخطط (schema fields) التي لم يرها النموذج من قبل.

ما يجب مراقبته لاحقًا

  • المعايير الناشئة – ترقب المقترحات من مجتمع أمن النماذج اللغوية الكبيرة (LLM) لفرض تواقيع تشفيرية على مخططات الأدوات.
  • تحصين سجل الأدوات – قد يبدأ الموردون في تقديم سجلات غير قابلة للتغيير وللقراءة فقط كخدمة، مما يقلل من سطح الهجوم.
  • الدفاعات على مستوى النموذج – يمكن للأبحاث في تقنيات التلقين (prompting) أو النماذج المساعدة التي تكتشف بيانات وصف الأدوات المشبوهة أن تكمل الضمانات الموجودة في جانب المضيف.

الخلاصة العملية واضحة: يجب على أي عملية نشر تعتمد على MCP تدقيق أوصاف الأدوات بنفس الصرامة المطبقة على المكتبات الخارجية. إن تجاهل مخاطر سلسلة التوريد يحول التجريد المريح إلى باب خلفي صامت. من خلال تثبيت الخوادم، وفرض قوائم سماح قائمة على مبدأ الحد الأدنى من الصلاحيات، وتقييد الإجراءات التي تغير الحالة، وإشراك البشر عند الحاجة، والاحتفاظ بسجل غير قابل للتغيير، يمكن للمطورين منع وكلاء LLM الخاصين بهم من أن يصبحوا شركاء غير راغبين في الجريمة.