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

​
1. لماذا تحتاج حماية MCP من سحب البساط إلى التقييم لكل استدعاء

مراجعة وقت الاتصال تجيب عن سؤال واحد مرة واحدة: هل هذا الخادم آمن لسرده؟ لا تستطيع الإجابة عن السؤال الذي يهم فعلاً وقت التشغيل: هل هذا الاستدعاء المحدد، بـهذه الوسائط المحددة، آمن الآن؟ يجيب OrcaRouter عن السؤال الثاني. كل tools/call يعبر البوابة يُقيَّم على سطح mcp قبل إرساله إلى الخادم الحقيقي، باسم الأداة والوسائط في اليد. يُحسَب الحكم من جديد كل مرة، ففي اللحظة التي تبدأ فيها أداة بفعل شيء تحرّمه سياستك — تسريب سرّ في وسيط، أو الوصول إلى مضيف ممنوع، أو استدعاء قدرة لم توافق عليها قط — يُوقَف الاستدعاء، بصرف النظر عن كيف تصرّفت نفس الأداة قبل دقيقة.
التقييم لكل استدعاء يحوكم سلوك كل استدعاء — محتويات الوسائط، والوجهات، ومخاطر المهارة المالكة — فيمسك بسحب البساط حتى عندما تحتفظ الأداة بتوقيع متطابق ويتحوّل سلوكها فقط إلى عدائي. كشف انحراف المخطط (القسم أدناه) هو الطبقة المكمّلة: يمسك بالحالة التي تتغير فيها مجموعة أدوات الخادم المُعلَنة نفسها. كلاهما يعمل.
الأحكام التي يمكن للمحرك إعادتها على سطح mcp:

allow / audit

مُمرَّر إلى الخادم. audit يسجّل الاستدعاء؛ allow يبقى صامتاً.

sanitize

مُمرَّر مع تنقيح وسائط استدعاء الأداة أولاً (لا يعيد أبداً كتابة ما يعيده الخادم).

deny

يُعاد إلى النموذج كـخطأ أداة (firewall deny: …) فيستطيع الوكيل التكيّف بدلاً من الانهيار.

pending_approval

يُحتجَز الاستدعاء ليحلّه إنسان قبل أن يعمل.

​
2. حجر نطاق مخاطر المهارة

النصف الثاني من الدفاع ضد سحب البساط يغطي سلسلة التوريد: المهارات، والإضافات، وخوادم MCP الخاصة بك التي يثبّتها وكيل. كل واحدة تُسجَّل كسجل ضمن نطاق مساحة العمل، وتُفحَص بمحرك مخاطر حتمي، وتُسنَد إليها نطاق مخاطر (low / medium / high / critical) إضافة إلى وضع فرض:
الوضعالأثر وقت التشغيل
allowأحكام القواعد تقرر؛ المهارة لا تضيف شيئاً.
quarantineأي شيء دون deny يُصعَّد إلى pending_approval — تعمل الأدوات فقط بعد موافقة إنسان.
blockتُمنَع أدوات المهارة كلياً.
هنا يُحتوى سحب البساط. القدرة التي يثبّتها وكيل ذاتياً هي auto_detected ومحجورة حتى تُراجَع — حتى لو فُحِصت نظيفة، لا تعمل بسلطتها الخاصة. ووضع المهارة لا يتشدّد إلا أكثر عند إعادة الفحص: block أو quarantine ضبطته لا يُرخى أبداً بصمت عند إعادة عرض بيان.
الحجر مفروض بشكل مستقل عن وضع الظل. المهارة المضبوطة على quarantine أو block لا تزال محتجَزة حتى بينما السياسة المحيطة في طرح ظلّي — فلا تستطيع قدرة خطيرة التسلّل أثناء نشر مرحلي.
انظر جدار الحماية: المهارات للفاحص الكامل، وأوزان التسجيل، وإشارات الثقة.

​
3. كشف انحراف مخطط الأداة

سحب البساط الكلاسيكي هو خادم مسجّل يغيّر ما يُعلِنه — يضيف أداة، أو يبدّل مخطط إدخال أداة، أو يستبدل وصفاً. تأخذ OrcaRouter مجموعة أدوات كل خادم مسجّل المُعلَنة كخط أساس عند فحص ناجح وتراقبها للانحراف.

خط أساس عند أول فحص

أول فحص ناجح يسجّل تجزئة قانونية لأدوات الخادم (ثقة عند أول استخدام تحت وضعية اكتشاف؛ وتحت وضعية فارضة يُحتجَز خادم بلا خط أساس كـpending حتى يوافق مسؤول على مجموعة أدواته الأولية).

الانحراف يفشل مغلقاً

عند فحص لاحق، إن لم تعد مجموعة الأدوات القانونية تطابق خط الأساس المعتمَد، يُعلَّم الخادم changed ويتوقف عن التقديم — لن تُرسِل البوابة أدواته حتى تقرر أنت.

وافق أو احجر

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

مدقَّق

أول كشف لانحراف عن خط أساس معتمَد يكتب مدخل تدقيق لمساحة العمل، فالتغيير في السجل.
حالة مخطط الخادم واحدة من unknown (لم يُؤخَذ خط أساس قط)، verified (تطابق خط الأساس)، changed (انحرف، محتجَز)، pending (بلا خط أساس تحت الفرض)، أو quarantined. تمسك هذه الطبقة بسحب البساط الذي يحرّك المخطط؛ والتقييم لكل استدعاء (القسم 1) يمسك بالذي يحتفظ بتوقيع متطابق ويغيّر السلوك فقط.

​
4. مثال ملموس واحد

افترِض أن خادم MCP مجتمعياً notes يُعلِن عن أداة notes.search غير ضارة. تسرده، وتراجعه، ويعمل. بعد أسبوع يُخترَق الخادم وتبدأ notes.search في إرفاق وسيط تسريب يُجري POST لسياقك إلى مضيف مهاجم. بوابة وقت الاتصال فقط ستمرّره — اسم الأداة والمخطط يبدوان دون تغيير. يقيّم OrcaRouter الاستدعاء: 
# كوّن قاعدة المنع في وحدة التحكم (Developer+)، وليس عبر مفتاح الترحيل.
# القاعدة: على سطح mcp، امنع notes.search كلما حمل
#       وسيطاً بشكل تسريب.
#   tool_name_glob: notes.search
#   args_match:     { "path": "$.callback_url", "op": "regex",
#                     "value": "^https?://(?!notes\\.example/)" }  → deny
(عوامل args_match هي eq، وcontains، وregex، وin، وcidr_match، وgt، وlt؛ cidr_match يختبر وسيطاً قيمته IP مقابل CIDR. لتقييد أين يجوز لأداة الوصول حسب مضيف/CIDR، استخدم قائمة وجهات الخروج بدلاً من جملة وسيط.) عند الإرسال يعيد المحرك deny، وبدلاً من تمرير الاستدعاء تسلّم البوابة الوكيل خطأ نتيجة أداة MCP — نتيجة عادية مُعلَّمة كخطأ، وليست فشل نقل — فيستطيع النموذج التكيّف: 
firewall deny: <your rule's reason>
نفس الاستدعاء الذي نجح الأسبوع الماضي محجوب الآن — لأن القرار يُتّخذ على الاستدعاء، وليس على الاتصال.
sanitize ينقّح الوسائط التي يرسلها وكيلك، وليس أبداً المحتوى الذي تعيده أداة. إن احتجت إلى تقييد أين يجوز لأداة الوصول، اقرن قاعدة منع بـ قائمة وجهات الخروج — لا تعتمد على sanitize لتنظيف الاستجابات.

​
5. كيف يتلاءم معاً

التقييم لكل استدعاء يمسك بـأداة موثوقة تصير خبيثة — نفس الاسم، سلوك جديد في الوسائط أو الوجهة. حجر المهارة يمسك بـقدرة جديدة أو غير مراجَعة تظهر أصلاً — تثبيت مُكتشَف تلقائياً، أو بيان مُعاد فحصه يتدهور حديثاً. سحب البساط يمكن أن يأخذ أي شكل، فكلاهما يعمل: وضع المهارة يركب فوق حكم القاعدة لكل استدعاء.
نعم — انظر القسم 3. مجموعة أدوات كل خادم مسجّل المُعلَنة تُؤخَذ كخط أساس عند أول فحص وتُعاد فحصها للانحراف؛ والخادم المنحرف يفشل مغلقاً حتى تعيد الموافقة عليه أو تحجره. ذلك مكمّل للتقييم لكل استدعاء، الذي يمسك أيضاً بأداة تحتفظ بتوقيع متطابق وتغيّر سلوكها فقط.
حكم pending_approval يحتجز الاستدعاء ليحلّه إنسان في وحدة التحكم (Developer+) أو عبر استدعاء موافقة HMAC. انظر أوضاع الفرض لكيفية عرض الاحتجازات والموافقات لوكيل.

​
6. تكوينه

كل خطوة أدناه إجراء وحدة تحكم / إدارة مصادَق برمز جلستك أو وصولك — وليس مفتاح ترحيل sk-orca-…. فقط حركة الترحيل /v1/* تستخدم مفتاح الترحيل.
1

سجّل خوادم MCP الخاصة بك خلف البوابة

وصّل كل خادم بحيث تُعلَن أدواته تحت نقطة نهاية واحدة مدقَّقة. التسجيل Developer+.
2

اضبط حكماً افتراضياً وقواعد على سطح mcp

ألّف قواعد بـtool_name_glob وargs_match بحيث تتحلّل الاستدعاءات الخطيرة إلى deny، أو sanitize، أو pending_approval. انظر مرجع قواعد جدار الحماية.
3

راجع المهارات المحجورة

أي شيء مُكتشَف تلقائياً يجلس في quarantine حتى يوافق مراجِع (Developer+). اقرأ النطاق والنتائج أولاً.
4

اطرح في الظل، ثم افرض

استخدم أوضاع الفرض لتشغيل قواعد جديدة في الظل، وراقب أحداث التدقيق، واقلب إلى الفرض بمجرد أن تبدو الأحكام صحيحة.
القراءات (الإعدادات، والسياسات، والأدوات المكتشَفة، والشذوذات) مفتوحة لأي Member؛ كل كتابة Developer+. قراءة النص الصريح لمفتاح بوابة جدار الحماية Developer+.

​
ذات صلة

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

مرجع بوابة MCP الكامل — التسجيل، والفحص، والإرسال.

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

مرورات الفاحص، وتسجيل المخاطر، واشتقاق الحجر.

تسميم أدوات MCP

نموذج التهديد الذي يوجد الدفاع ضد سحب البساط لمواجهته.

حدود الخروج

ألّف قواعد منع مضيف/CIDR لتقييد أين يجوز للأدوات الوصول.

قائمة تحقق الثقة

قائمة التحقق من البداية إلى النهاية للوثوق بخادم MCP.

حواجز الحماية مقابل جدار الحماية

متى تنطبق سياسة المحتوى ومتى يفعل جدار الحماية.