الانتقال إلى المحتوى الرئيسي
خادم MCP تابع لطرف ثالث أو مهارة مثبَّتة هي تبعية في سلسلة التوريد. يبرز وضعا فشل:
  • التسميم — كان الخادم خبيثاً من اليوم الأول. بدا بيانه التعريفي حميداً؛ السلوك الخطر كان في تطبيق الأداة، لا في النطاقات المُعلَنة.
  • Rug-pull — أعطيته ثقتك، ثم تغيّر. ظهرت أداة جديدة أضافها مشغّل الخادم بهدوء، أو اختُطف إدخال في سجل مجتمعي وحُدِّث ليتصل بمضيف.
يشترك كلا التهديدَين في سبب جذري: بعد أن قلت “أثق بهذا الخادم”، يظل وكلاؤك يستدعون أدواته — حتى الجديدة أو المعدّلة منها — دون أي مراجعة إضافية.

​
1. كيف يصل تسميم أدوات MCP لوكلائك

كل tools/call يصدره وكيلك يسلك عبر مجموعة الأدوات المُعلَنة لخادم MCP. يستغل خادم مسموم أو تعرّض لـ rug-pull تلك الثقة بعدة طرق:
المتجهما يحدث
أداة غير مُعلَنةتظهر أداة جديدة في tools/list لم يُعلن عنها في بيان الخادم قط. يجدها وكيلك ويستدعيها.
إدخال سجل مخترقيُستولى على إدخال في سجل مجتمعي؛ تشير نقطة النهاية الآن لخادم يتحكم فيه المهاجم.
حصاد بيانات الاعتماديُرسل تطبيق الأداة المدخلات المجمَّعة لمضيف خارجي.
حقن المطالبة عبر نتيجة الأداةتُعيد أداة نصاً يتحكم فيه المهاجم يعيد توجيه الإجراء التالي للوكيل.

​
2. دفاعات OrcaRouter

​
2.1 كل tools/call يُقيَّم بجدار الحماية قبل تشغيله

تتصل خوادم MCP بوكلائك عبر بوابة Firewall MCP على /api/v1/firewall/mcp. لا تُوجِّه البوابة استدعاء أداة حتى يُقيِّمه محرك جدار الحماية مقابل سياستك. هذا يعني أن قائمة سماحك هي مصدر الحقيقة — لا بيان الأداة للخادم. إذا أضاف rug-pull أداة shell.exec وسياستك لا تحمل قاعدة تسمح بها، يكون الحكم deny ولا يغادر الاستدعاء البوابة. يتلقى النموذج خطأ أداة (firewall deny: …) ويمكنه التفاعل؛ الأداة التي أضافها المهاجم ميتة عند الوصول. الأحكام التي يستطيع المحرك إعادتها:
الحكمالأثر
allow / auditيُوجَّه الاستدعاء؛ audit يُسجِّل الوسائط إضافةً.
sanitizeتُعاد كتابة الوسائط قبل التوجيه.
denyيُحجب الاستدعاء؛ يتلقى النموذج خطأ أداة.
pending_approvalيُعلَّق الاستدعاء؛ إنسان يجب أن يوافق قبل المتابعة.
cap_costيُنفَّذ سقف التكلفة؛ يُحجب الاستدعاء إذا كان سيتجاوزه.

​
2.2 القدرات المُكتشَفة تلقائياً تُحجَر حتى المراجعة

عندما يثبّت وكيل قدرةً ذاتياً — أو عندما يُضيف rug-pull أدوات جديدة لم تكن موجودة عند تسجيل الخادم — يُكتشف جدار الحماية تلقائياً القدرة الجديدة خارج المسار الساخن، ويُنشئ بياناً تعريفياً، ويفحصه، ويُعيّن نطاق مخاطرة ووضع فرض. والأهم، تُحجَر القدرات المُكتشَفة تلقائياً دائماً بصرف النظر عن نتيجة الفحص: تُعلَّق في pending_approval حتى يراجعها إنسان. هكذا يُحتوى rug-pulls. لا يستطيع مشغّل إضافة أداة جديدة بهدوء وجعل وكلاءك يبدأون باستخدامها — تلك الاستدعاءات مُعلَّقة حتى تفحص وتوافق على القدرة الجديدة.

​
2.3 فحص المهارة يُعيّن نطاق مخاطرة ووضع فرض

كل قدرة قابلة للتثبيت — سواء سجّلتها أنت أو اكتشفها جدار الحماية تلقائياً — تمر عبر ماسح المهارة. يُجري الماسح تمريرات حتمية على البيان والنطاقات المُعلَنة:
  • prompt_injection — نص البيان الذي يحاول اختطاف التعليمات.
  • tool_creep — أدوات يستخدمها البيان لكن لم يُعلن عنها قط.
  • network_egress — مضيفون HTTP(S) خارج نطاقات الشبكة المُعتمَدة.
  • fs_write_unsafe — وصول للكتابة في نظام الملفات خارج /tmp.
تتجمع النتائج في نطاق مخاطرة (low / medium / high / critical) ووضع فرض:
الوضعما يحدث وقت التشغيل
allowلا تفرض المهارة شيئاً من تلقاء نفسها؛ قواعد سياستك تقرر.
quarantineأي حكم غير-deny يتصعّد إلى pending_approval. إنسان يجب أن يوافق على كل استدعاء أداة.
blockإجبار deny على جميع أدوات هذه المهارة، بصرف النظر عن قواعد السياسة.
مهارة بنطاق high تُحجَر تلقائياً؛ critical تُحجب. نتيجة error واحدة (مثل tool_creep لأداة shell.exec غير مُعلَنة) تكفي لحجب مهارة حتى لو بدت درجتها الرقمية منخفضة. الوضع لا يُخفَّف أبداً — الموافقة على مهارة لا تُرخي حجباً صادراً عن فحص جديد.

​
2.4 بيانات الاعتماد مُخزَّنة مشفَّرة

أسرار مصادقة الخادم مشفَّرة في حالة السكون بمفتاح أسرار مساحة العمل ومُحقَنة بواسطة البوابة وقت الإرسال. لا تصل أبداً للنموذج، ولا للوكيل، ولا لوسائط الاستدعاء. خادم مخترق لا يستطيع تسريب مفاتيح API الخاصة بك بقراءة auth_json الخاص به.
قائمة تحقق لفحص خادم MCP تابع لطرف ثالثقبل تسجيل خادم MCP خارجي:
  • تحقق من هوية الناشر — من يتحكم في عنوان URL لنقطة النهاية؟
  • اقرأ المصدر أو سجل التغييرات؛ ابحث عن أدوات جديدة أُضيفت بعد الإصدار الأولي.
  • تحقق مما إذا كان فحص المهارة يُعيد أي نتائج tool_creep أو prompt_injection عند التسجيل.
  • حدّد نطاق قاعدة جدار حماية بـ tool_name_glob: <server>.* على audit أو pending_approval حتى يكون لديك سجل استدعاءات.
  • راجع نتائج network_egress: هل يدّعي البيان أنه يحتاج مجالاً واحداً فقط بينما تذكر أوصاف الأداة مجالات أخرى؟
  • أعد استطلاع الخادم بعد أي رفع لإصدار أعلى (POST /api/workspace/firewall/mcp_servers/:id/probe) للكشف عن أدوات جديدة.

​
3. ما يجب فعله بعد rug-pull مشتبه به

  1. أوقف الخادم فوراً — خادم موقوف يُحذف من سجل وقت التشغيل ولا تُفكَّك تشفير بيانات اعتماده أبداً. استخدم PUT /api/workspace/firewall/mcp_servers مع "enabled": false.
  2. أعد الاستطلاع للكشف عن التغييرات — POST /api/workspace/firewall/mcp_servers/:id/probe يُشغِّل tools/list ويُعيد أي أدوات جديدة ظهرت منذ آخر استطلاع.
  3. أعد فحص سجل المهارة — POST /api/workspace/firewall/skills/:id/rescan يُعيد تشغيل الماسح مقابل البيان المحدَّث. إذا تراجع الحكم إلى flagged أو blocked، يُصدر جدار الحماية حدثاً في تغذيتك.
  4. راجع طابور pending_approval — أي استدعاءات مُعلَّقة منذ rug-pull موجودة في الطابور. افحصها وارفضها بدلاً من الموافقة عليها بالجملة.
  5. دقِّق في سجل الاستدعاءات — تحقق من مسار أحداث جدار الحماية لاستدعاءات مرّت قبل اكتشاف التغيير.

​
4. الجمع بين فحص المهارة وقواعد جدار الحماية

فحص المهارة وقواعد جدار الحماية متكاملان ويتركّبان:
  • قاعدة بـ tool_name_glob: community.* مضبوطة على pending_approval تضمن مراجعة كل استدعاء من خادم مصدره المجتمع، بصرف النظر عن نطاق المخاطرة.
  • مهارة محجورة تتجاوز قاعدة allow — حتى لو كانت سياستك تسمح بـ http.fetch بشكل عام، مهارة محجورة تمتلكها لا تزال تُعلَّق الاستدعاء.
  • استخدم skill_name_glob في قاعدة لتحديد سياسات أضيق على الخوادم غير الموثوقة دون التأثير على تكاملاتك المباشرة.
انظر جدار الحماية: خوادم MCP لنموذج البوابة الكامل وجدار الحماية: المهارات لمرجع الماسح ووضع الفرض.

​
5. التهديدات ذات الصلة

جدار الحماية: خوادم MCP

سجِّل خوادم MCP خلف البوابة، واستطلع أدواتها، وطبّق أحكاماً لكل استدعاء قبل وصوله للخادم الحقيقي.

جدار الحماية: المهارات

افحص ودرِّج مخاطر كل قدرة قابلة للتثبيت. احجر أو أوقف المهارات الخطرة قبل أن تتمكن أدواتها من العمل.