أمان MCP: لماذا تجعل 200,000 نسخة معرّضة الوحدات المُحوكمة معيارًا للشراء

الإفصاح

في أبريل ومايو 2026، أفصحت OX Security عن ثغرة معمارية منهجية في تكوينات Model Context Protocol STDIO تُتيح حقن الأوامر وتنفيذ التعليمات البرمجية عن بُعد. يغطّي التقرير 10 ثغرات CVE عبر سلسلة توريد MCP — نحو 200,000 نسخة معرّضة، تلامس 150 مليون تنزيل. الثغرة ليست في حزمة واحدة. إنها في نمط التكوين الافتراضي الذي تُسلّمه معظم خوادم MCP المجتمعية.

عنونت Cloud Security Alliance ملاحظتها البحثية "أزمة أمان MCP: عيوب تصميم منهجية في بنية وكيل الذكاء الاصطناعي". أطلقت OWASP مشروع MCP Top 10 لتوثيق أكثر المخاوف الأمنية حرجة عبر دورة حياة الأنظمة المُمكَّنة بـ MCP. نشرت Aembit دليلًا يغطي مخاطر النقل وتهديدات سلسلة التوريد. ونشرت TrueFoundry دليلًا للمؤسسات حول مخاطر أمان MCP وأفضل الممارسات.

النمط المشترك بينها جميعًا: سطح الثغرة موجود لأن خوادم MCP المجتمعية تُبنى وتُنشَر دون طبقة الحوكمة التي تتطلبها أنظمة الإنتاج.

ما هي الثغرة فعلًا

تتواصل خوادم MCP مع عملاء وكلاء الذكاء الاصطناعي عبر نُقل. يمرّر نقل STDIO — الافتراضي للتطوير المحلي وكثير من عمليات نشر الإنتاج — الرسائل عبر الإدخال والإخراج القياسيين. حدّد إفصاح OX Security أن أنماط تكوين STDIO الشائعة تُتيح حقن الأوامر: مدخول مُصنَّع يستطيع تنفيذ أوامر اعتباطية على المضيف الذي يُشغّل خادم MCP.

هذا ليس مسار هجوم نظري. تعمل خوادم MCP على الآلة ذاتها التي يعمل عليها عميل الوكيل، بنفس أذونات العملية. خادم يقبل وينفّذ أوامر shell بناءً على مدخول يستقبله عبر STDIO هو سطح تنفيذ تعليمات عن بُعد بطبيعته. يعكس تقدير الـ 200,000 نسخة حجم تبنّي MCP المجتمعي — خوادم منشورة إلى سجلّات، ومنسوخة من مستودعات، ومنشورة بتكوينات افتراضية لم تُحصَّن أبدًا للإنتاج.

حدّدت Backslash Security بشكل منفصل ثلاثة أسطح هجوم جديدة أدخلها مرشّح إصدار MCP 2026-07-28 ذاته — المواصفة ذاتها التي تُنهى خلال 20 يومًا. القدرات الجديدة (واجهات يُولّدها الخادم، ومهام طويلة التشغيل، وتوجيه بالترويسات) تُنشئ نقاط دخول جديدة ما يزال مجتمع الأمان يرسمها.

لماذا الخوادم المجتمعية هي نقطة التعرّض

تُبنى معظم خوادم MCP المجتمعية لتُظهِر قدرة — ربط وكيل بأداة، وإعادة نتيجة. لا تُبنى لتُشغَّل. ضوابط الحوكمة التي تتطلبها أنظمة الإنتاج غائبة افتراضيًا:

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

هذه ليست متطلبات أمان غريبة. إنها الضوابط ذاتها التي يفرضها أي API إنتاجي. الفجوة أن خوادم MCP تُنشَر وكأنها أدوات تطوير، لا تكاملات إنتاج.

كيف تبدو الوحدات المُحوكمة

يُعرّف معيار كود وحدات MCP الذي ننشره طبقة الحوكمة التي تُعالج كل واحدة من هذه الفجوات. المعيار ليس إطار أمان — بل معيار كود يجعل الأمان قابلًا للإطباق. الضوابط ملموسة:

تسجيل التدقيق. يُسجّل كل استدعاء أداة الطابع الزمني، ومُعرّف الوكيل، واسم الأداة، وتجزئة الإدخال (لا الإدخال الخام — حد PII)، وحالة الإخراج، والمدة، والنظام العلوي. السجلات بصيغة JSON منظّمة تُرسَل إلى خط أنابيب المراقبة. عند وقوع حادث، يُعيد مسار التدقيق بناء حالة تدفق العمل الكاملة من وسائط الطلب والمقابض — دون مطابقة مع سجلات مخزن الجلسات.

تحديد المعدل. تُعلن كل أداة عن حد المعدل الخاص بها في استدعاء التسجيل. يفرض الهيكل الأساسي الحدود لكل وكيل، ولكل أداة، ولكل نافذة. عند بلوغ حد، يستقبل الوكيل استجابة 429 مع ترويسة Retry-After — لا يتعطّل ولا يُعيد المحاولة أعمى. لا يستطيع وكيل مخترق استنزاف حصص النظام العلوي لأن حد المعدل يُطبَّق عند حد الوحدة، لا عند API العلوي.

عقد الأخطاء المُنمّطة. تُطلق الوحدات استثناءات مُنمّطة — MCPAuthError، وMCPRateLimitError، وMCPTimeoutError، وMCPValidationError، وMCPUpstreamError — لا سلاسل مجردة. يلتقطها الهيكل الأساسي ويحوّلها إلى استجابات منظّمة يستطيع الوكيل التفكير فيها. يستطيع المشغّل تصنيف الحوادث برمجيًا لأن كل خطأ يحمل رمزًا.

معالجة حدود PII. تُعلن الوحدات عن حقول الإدخال التي تحتوي على PII. يُجزّئ الهيكل الأساسي هذه الحقول (SHA-256) قبل التسجيل ولا يُرسل PII خامًا إلى خط أنابيب التدقيق. لا يزال مُعالِج الأداة يستقبل القيمة الخام — تُطبَّق معالجة PII عند حد التسجيل، لا داخل منطق العمل.

تغطية الاختبارات. لكل أداة اختبارات طلب/استجابة وتغطية لمسارات الأخطاء. تُجرى اختبارات التكامل مقابل بيئات معزولة. تتحقق الاختبارات الوهمية من تسجيل الأدوات، وتعيين الوسائط، وتطبيع الاستجابات، وانتشار الأخطاء، وانتقالات الحالة. نمط الفشل الذي لم يُجرّب أبدًا في التطوير لا يُسلَّم.

نقطة إثبات الـ 38 أداة

هذه الضوابط ليست تطلّعية. إنها بنية mcp_hospirfq_processor — وحدة تُسجّل 38 أداة عبر دورة حياة RFQ الكاملة: إنشاء الطلب، وبحث الكتالوج، وتوليد عرض السعر، وطبقات التسعير، وحجز التوفّر، وسياسات الإلغاء، واكتشاف الحزم، وتسليم الطلب.

يُعرّف مُعالِج أخطاء الوحدة رموز أخطاء مُنمّطة لكل نمط فشل — GRAPHQL_QUERY_FAILED، وVALIDATION_FAILED، وHOLD_NOT_FOUND، وHOLD_ALREADY_EXPIRED، وAVAILABILITY_INSUFFICIENT، وPRICING_MODE_UNSUPPORTED. يحمل كل خطأ رمزًا وتفاصيل منظّمة. يُغلّف مُزيّن handle_errors كل método أداة، فلا تُعيد أداة استثناءً غير منظّم. يفرض مدير الحالة انتقالات صحيحة — يمكن تأكيد حجز أو تحريره أو انتهاؤه، لكن لا يمكن تخطّيه من الابتدائي إلى المكتمل.

هذا ما تبدو عليه الوحدة المُحوكمة في الممارسة: لكل أداة مخطط، ولكل خطأ رمز، ولكل استدعاء سجل، ولكل انتقال حالة مُتحقّق. الحوكمة في الكود، لا في مستند قد يقرأه أحد.

بنية مفتاح الإيقاف

تمتد طبقة الحوكمة إلى ما وراء الوحدة إلى الهيكل الأساسي للتنسيق. يُحدّد الملخص الهندسي الموقف التشغيلي:

• دليل تشغيل المشغّل. النشر، والتراجع، والاستجابة للحوادث، والعمليات الشائعة موثّقة. عندما تُسيء وحدة السلوك، يتبع المشغّل دليلًا، لا محادثة على Slack.
• مسارات احتياطية. تدهور لطيف عندما يكون الخادم الخلفي غير متاح. وحدة لا تستطيع الوصول إلى نظامها العلوي تُعيد خطأً منظّمًا، ويوجّه الوكيل إلى أداة احتياطية أو يرفع الأمر إلى إنسان.
• طرح بالأعلام الميزات. تُمكَّن الوحدات حسب البيئة. يمكن تعطيل وحدة دون المساس بالهيكل الأساسي للتنسيق — مفتاح الإيقاف تغيير تكوين، لا نشر كود.
• قابلية المراقبة. سجلات منظّمة، ومقاييس، وآثار تُرسَل إلى رصة المراقبة. سلوك الوكيل قابل للتدقيق من البداية إلى النهاية — الموقف ذاته الذي تُطبّقه المؤسسات على الضوابط المالية.

بنية مفتاح الإيقاف هي الضابط الذي يكشف إفصاح OX Security أنه مفقود في 200,000 خادم مجتمعي. عند الإفصاح عن ثغرة، سؤال المشغّل الأول: هل أستطيع تعطيل هذه الوحدة دون إسقاط الوكيل؟ في نشر مُحوكَم، الجواب نعم. في نشر خادم مجتمعي، الجواب عادةً لا — الخادم موصول بقائمة أدوات الوكيل، وإزالته تتطلب تحرير الكود وإعادة النشر.

لماذا أصبح هذا معيار شراء الآن

وجد استطلاع PwC 2026 العالمي للرؤساء التنفيذيين (4,454 رئيسًا تنفيذيًا) أن 56% من المؤسسات لا تُبلغ عن فائدة مالية قابلة للقياس من الذكاء الاصطناعي. ووجد استطلاع WRITER لتبنّي الذكاء الاصطناعي في المؤسسات أن 35% من المؤسسات لا تستطيع سحب القابس من وكيل ذكاء اصطناعي بعد نشره. الجمع بينهما هو معيار الشراء: نظام لا يمكن تعطيله هو التزام، ونظام لا يُنتج فائدة قابلة للقياس هو كلفة. الحوكمة — سجلات التدقيق، وحدود المعدل، والأخطاء المُنمّطة، وبنية مفتاح الإيقاف — هي الضابط الذي يجعل وكيل الذكاء الاصطناعي آمنًا للنشر وآمنًا للإيقاف.

يتوقّع Gartner أنه بحلول نهاية 2026، ستتجاوز الدعاوى القضائية "الموت بالذكاء الاصطناعي" 2,000 دعوى بسبب حواجز حماية غير كافية من مخاطر الذكاء الاصطناعي. يصبح قانون AI للاتحاد الأوروبي ساريًا بالكامل في 2 أغسطس 2026 — بعد 25 يومًا من اليوم. قواعد الشفافية في المادة 50 تتطلب الإفصاح عن المحتوى المُولَّد بالذكاء الاصطناعي. يصبح تصنيف المخاطر، والتوثيق، وحفظ السجلات إلزاميًا للأنظمة عالية المخاطر. سجلات التدقيق وأدلة تشغيل المشغّل التي تُسلّمها الوحدات المُحوكمة بالفعل هي دليل الامتثال الذي سيتطلبه قانون AI للاتحاد الأوروبي.

مواصفة MCP 2026-07-28 تُنهى خلال 20 يومًا. عند إصدارها، سيرتفع حجم البحث والاستشهاد لـ "Model Context Protocol" — ويرتفع معه التدقيق في سطح الأمان. الخوادم المجتمعية التي لا تبلغ حد الحوكمة هي التي ستُعلَّم.

القرار

عندما يُقيّم فريق نشر وكيل قائم على MCP، لم يعد السؤال "هل يتصل؟". الخوادم المجتمعية تتصل. السؤال: عندما يسوء شيء، هل تستطيع رؤيته، وإيقافه، وإثبات ما حدث؟

الوحدات المُحوكمة تُجيب بنعم على الثلاثة. الخوادم المجتمعية، افتراضيًا، تُجيب بلا على الثلاثة. الـ 200,000 نسخة المعرّضة هي الدليل.

---

موزّع يُشغّل NetSuite وBigCommerce وثلاثة كتالوجات مورّدين يحصل على وكيل يستقبل RFQ بالبريد الإلكتروني أو البوابة، ويحلّ المنتجات والبدائل مقابل رسم الكتالوج، ويسعّر حسب طبقة العميل، ويحجز المخزون مع انتهاء صلاحية، ويكتب عرض السعر المقبول إلى NetSuite — مع تسجيل كل خطوة، وتحديد معدل كل أداة، وقابلية تعطيل كل وحدة بالتكوين. هذا البناء هو المرحلة 2-3 من المنهجية ذات الأربع خطوات ويُسلّم عادةً خلال 5-8 أسابيع.

اطلب بناءًا محدّد النطاق. اكتشاف في أسبوع واحد. تحصل على جرد نظام، وخريطة تدفق عمل، ونطاق ثابت — سواء بنيت معنا أم لا.