نموذج الثقة في MCP سمح لوكيل مسموم بالوصول إلى وكيل آخر

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

ذكرت Ars Technica في 5 أكتوبر أن باحثًا مستقلًا، سيد أنس محيي الدين، عرض فئة من الهجمات يسميها «التجوّل عبر البروتوكول» (protocol pivoting). الفكرة بسيطة. داخل الشبكة، يتحدث الوكلاء إلى بعضهم عبر بروتوكول سياق النموذج (Model Context Protocol) أو MCP. تكون الضوابط الأضعف عند النقطة التي يسلّم فيها وكيل مهمة إلى وكيل آخر، لأن الوكيل الثاني يثق بالأول افتراضيًا. ازرع تعليمة خبيثة في وكيل ترجمة أو تحليل بيانات يفتقر إلى تحقق صارم من المدخلات، وسيمرر التعليمة إلى الأسفل. ويطيع المتلقي، فلماذا يكذب زميل موثوق؟

امتد نموذج الإثبات لدى محيي الدين عبر خمس مؤسسات غير مرتبطة: Google، وJPMorgan Chase، وWeviate، وRapid7، والمديرية الرقمية المشتركة بين الوزارات في فرنسا، ووكالة فيدرالية أمريكية. لا تشترك هذه المؤسسات إلا في الاستخدام المكثف للوكلاء. وهذا هو المغزى. الضعف يكمن في البنية التحتية، وليس في أي منتج بمفرده.

ثغرتا CVE وفجوة في التقييم

الأخطاء الملموسة عادية، وهذا جزء مما يجعل القصة مقلقة. يحمل خادم MCP من Rapid7 الثغرة CVE-2026-97228، والتي أصلحتها الشركة في سبتمبر 2026 رغم أن العيب حصل على تقييم 2.7 من 10. جاءت مشكلة Google في مرتبة أعلى، بتقييم 8، وطالت googleapis/mcp-toolbox. كان عميل HTTP لديها يفتقر إلى سياسة CheckRedirect والتحقق من عنوان IP الهدف، لذا يمكن لمعامل مسار مُصمم أن يعيد توجيه طلب نحو نقطة نهاية داخلية. أضافت Google قوائم سماح وحظر لعناوين IP وجعلت صندوق الأدوات يرفض عناوين URL الأساسية غير الآمنة عند بدء التشغيل.

التفاوت في درجات الخطورة درس بحد ذاته. اكتشفت مؤسستان نقاط ضعف متقاربة في البروتوكول نفسه لكنهما قيّمتاها بشكل مختلف جدًا، ما يشير إلى أن القطاع لم يحسم بعد كم ينبغي أن تكون تكلفة فجوة الثقة بين وكيل وآخر.

لا يقبل الجميع «التجوّل عبر البروتوكول» كفئة جديدة. قال ماركوس فيرفير، باحث في X41 D-Sec، لـ Ars Technica إنه يقرؤها على أنها حقن أوامر غير مباشر، وهي التقنية نفسها التي تتبعها فرق الأمن منذ عامين. هذا التأطير منصف، كما أنه يزيد المشكلة العملية حدة: يفترض دليل الدفاع ضد حقن الأوامر أن المدخل يأتي من الخارج. وهنا يأتي من الداخل، وهو يرتدي اعتمادًا داخليًا.

الفجوة معمارية، وليست ترقيعًا

يدفع تقرير منفصل من شركة الأمن ClawSecure التحليل طبقة أعمق. اختبر باحثوها Linear وNotion وDropbox Dash ويرون أن العيب يقع في مواصفات MCP وليس في تطبيق أي بائع. في Notion وLinear، وجدوا خوادم MCP تجلب تلقائيًا روابط يتحكم بها المهاجم لحظة إنشاء المحتوى، دون وجود نموذج في الحلقة إطلاقًا. يمكن لأي شخص لديه صلاحية كتابة على مساحة عمل أن يحوّلها إلى قناة تسريب، متجاوزًا الحاجة إلى تعليمة مصاغة ببراعة.

أرقامهم صريحة. من بين 20 تقنية تمويه، تشمل Unicode بعرض صفري والحروف المتشابهة، نجت 17 من الرحلة ذهابًا وإيابًا. عبر 14 نموذجًا من خمسة مختبرات، لم يحجب أي منها التهديدات باستمرار؛ حتى الأفضل أداءً، Claude Opus 4.7، اتبع التعليمات الخبيثة نحو 26.7% من الوقت.

تبيع ClawSecure منتجات أمنية ولم يُعد إنتاج التقرير بشكل مستقل، لذا تعامل مع الادعاء المتعلق بطبقة المنصة بالحذر المناسب. لكن الظروف الكامنة سهلة التحقق. يسجل MCP أكثر من 500 مليون تنزيل شهري لـ SDK وما يقرب من 16,000 خادم عام، وبحسب إحصاء واحد فإن 8.5% فقط من تلك الخوادم تستخدم OAuth. سبق التبني عملية التحصين.

قدمت AWS دليلها الخاص في نشرة نُشرت في 2 أكتوبر. ثلاث عيوب في منصتها مفتوحة المصدر Loom لتنسيق الوكلاء قد تسمح بالاستيلاء الإداري دون مصادقة، وكشف بيانات اعتماد OAuth2، والوصول إلى خدمات داخلية. الأخطر، CVE-2026-103956، سمح لأي عميل شبكة بالوصول إلى مستوى التحكم بالوكيل في عمليات النشر دون مزود هوية مُهيأ. تسد إصدارات Loom 1.6.1 و1.7.0 هذه الفجوات.

لماذا افتراض الثقة الافتراضي هو الاكتشاف الحقيقي

إذا أزلنا ثغرات CVE، يبرز خيار تصميمي واحد. بُني الوكلاء للتعاون، لذا يوثّقون بعضهم بعضًا ثم يتصرفون كما لو أن اعتمادًا صالحًا يعني أيضًا طلبًا صالحًا. تقول الثقة الصفرية الكلاسيكية العكس: أثبت صحة كل طلب بذاته، حتى من داخل المحيط الأمني.

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

ما يمكن للفرق فعله هذا الأسبوع

الإصلاحات الفورية غير مبهرة ومتاحة الآن. تعامل مع أي تعليمة تصل من نموذج لغوي كمدخل معادٍ، بصرف النظر عن الوكيل الذي أنتجها. فرض معالجة صارمة لإعادة التوجيه وتحقق من عناوين IP الوجهة. اشترط مصادقة لكل وكيل قبل أن يفوّض وكيل مهمة إلى آخر، وسجّل التفويض حتى يمكن إعادة بناء سلسلة التسليمات لاحقًا.

على المدى الأطول، توقّع أن تضع هيئات المعايير «التجوّل عبر البروتوكول» كفئة تهديد مسمّاة، ما سيدفع البائعين إلى تضمين فحوصات الثقة الصفرية داخل MCP بدلًا من جواره. وسيتبع المدققون ذلك، وستبدأ أسئلة حول ضوابط الحماية بين الوكلاء بالظهور في مراجعات الامتثال كما ظهرت قواعد الجدار الناري قبل جيل.

الجزء المقلق في هذه القصة هو أن الحيلة تعمل بشكل أفضل بمجرد أن يثق الوكلاء ببعضهم. كل مؤسسة تتسابق لربط أدواتها عبر MCP تبني نسيج الثقة هذا الآن، ومعظمه يُبنى دون خطة لما يحدث عندما يتبين أن أحد أفراد الفريق يكذب.

لماذا ظهر هذا الآن

لا توجد تقنية كامنة جديدة. فقد كانت ثغرات تزوير الطلب من جانب الخادم والحقن على قائمة OWASP لسنوات. ما تغير هو مكان تشغيلها. منحت الوكلاء تلك الأخطاء القديمة طريق توصيل جديد، لأن الوكيل سيتصرف بسرور بناءً على جملة في مستند، أو حقل في صف قاعدة بيانات، أو سطر في مخرجات وكيل آخر. لا يلزم أن يكتب المهاجم التعليمة. يكفي فقط أن تصل إلى مكان يقرأه النموذج.

لهذا يمتد الكشف عبر بنك ومحرك بحث وبائع أمني ومديرية حكومية. لم يتشاركوا شيفرة أو بائعًا. لقد تشاركوا معمارية، وهذه المعمارية تحمل افتراضًا بأن كل مشارك موثوق. تحوّل MCP من فكرة جديدة إلى بنية تحتية حرجة في نحو عام، بتنزيلات تُقاس بمئات الملايين شهريًا، والمراجعة الأمنية التي ترافق عادة هذا النمو لم تحدث في الغالب.

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