الانتقال إلى المحتوى الرئيسي
وكيل MCP وكيل ذو امتداد. كل خادم Model Context Protocol يتصل به مجموعة جديدة من الأدوات وبيانات الاعتماد والوجهات الشبكية لم يراجعها أحد — ويستطيع الوكيل جلب واحد جديد في منتصف التشغيل. تُظهر هذه الوصفة الحركات الأربع التي تحوّل إعداد MCP المتناثر إلى محكوم على البوابة المستضافة: بوابة MCP واحدة مدقَّقة، وحجز المهارات في الحجر، ورفض egress، ومصادقة خادم مشفَّرة. تضبط كل ذلك من وحدة التحكم (أو REST API) مقابل مساحة عملك. يستمر وكيلك في التحدث بـ MCP تماماً كما كان.

​
1. لماذا تؤمّن وكيل MCP

وجّه وكيلاً نحو خمسة خوادم MCP مباشرةً وستحصل على خمس حدود ثقة، وخمسة متاجر بيانات اعتماد، وصفر مسار تدقيق مشترك. يبدو tools/call الذي يقرأ سجل عميل والآخر الذي يشغّل أمر shell متطابقين للنموذج، ويمكن لخادم مجتمعي أن يطلب بهدوء shell.exec ونطاقاً شبكياً خارجياً أول مرة يُحمَّل فيها. الحل هو جعل OrcaRouter نقطة الاختناق الوحيدة التي يعبرها كل استدعاء. لـتأمين حركة وكيل mcp من طرف إلى طرف، توجّه كل إرسال MCP عبر بوابة MCP لجدار الحماية، بحيث يُقيَّم كل tools/call بالسياسة قبل أن يصل إلى الخادم الحقيقي — مع تسجيل مخاطر المهارات، وحكم egress، وتشفير بيانات الاعتماد في حالة السكون.
هذه وصفة — تخيط الميزات الموجودة في تمريرة تقوية واحدة ملموسة. للمرجع الكامل، اتبع الروابط إلى جدار الحماية، وخوادم MCP، والمهارات.

​
2. ابدأ من خط أساس الوكلاء الآمنين

قبل تأليف أي شيء مخصص، اضبط موقفاً. في وحدة التحكم افتح Firewall → Posture وطبّق مستوى الاستقلالية balanced مستوى الاستقلالية (دور Developer). في معاملة واحدة يدقّق استدعاءات الأدوات ويعلّم PII بينما يرفض أكثر الإجراءات تدميراً — تراقب قبل أن تفرض على نطاق واسع، مع تراجع بنقرة واحدة. عندما تبدو تغذيتا Events وRuns صحيحتين، انتقل إلى tight: حجب-افتراضي، الـ shell المدمّر مرفوض، egress على هيئة SSRF مرفوض، بالإضافة إلى فرض حاجزي PII Shield وSecrets Blocker. ذلك المفتاح الواحد هو الأرضية التي تبني عليها هذه الوصفة.
تفضّل التصاعد دون قلب مساحة العمل كلها؟ ألّف القواعد أدناه في سياسة مسمّاة واحدة وفعّل وضع الظل فيها — تقيّم وتسجّل لكنها تُخفّض كل حكم فارض إلى audit (السبب مسبوق بـ [shadow] would …) حتى تتأكد. انظر أوضاع الفرض.

​
3. وجّه كل tools/call عبر بوابة MCP واحدة

سجّل كل خادم MCP مرة واحدة؛ تجمّع البوابة أدواتها تحت اتصال واحد (بمساحة أسماء <server>.<tool>) وتشغّل كل tools/call عبر محرك جدار الحماية. سجّل خادماً من وحدة التحكم (أو REST API، Developer+): 
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-session-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'
ثم وجّه عميل MCP الخاص بك نحو البوابة — لا نحو الخوادم الأعلى — مستخدماً مفتاحاً مخصصاً ضمن نطاق بوابة جدار الحماية: 
https://api.orcarouter.ai/api/v1/firewall/mcp
الآن يظهر github.create_issue وshell.exec جنباً إلى جنب تحت اتصال واحد، ويُقيَّم كل إرسال قبل أن يعمل. يعود استدعاء محجوب إلى النموذج كـ خطأ أداة (firewall deny: …)، لا انهيار نقل، فيستطيع الوكيل التكيّف.
يحصل مفتاح ترحيل عادي على 403 على مسار البوابة /api/v1/firewall/mcp. اسكك رمز بوابة مخصصاً (is_firewall_gateway) لاتصال MCP؛ قراءة النص الصريح لمفتاح البوابة ذاك تتطلب Admin+.
قبل أن تتمكن من كتابة قواعد مقابل أدوات خادم، افحصه لاكتشاف أسمائها ومخططاتها: 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-token>"

​
4. احجز المهارات التي يجلبها الوكيل في الحجر

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

​
5. ارفض egress على هيئة SSRF

أداة MCP مخترَقة أو مرتبكة تصل إلى البيانات الوصفية للسحابة أو مضيف إنترانت هي مسار التسريب الكلاسيكي. طبقتان تغطيانه. أولاً، تتحقق البوابة من كل نقطة نهاية MCP بعيدة وعنوان IP المحلول الذي تطلبه مقابل سياسة SSRF عند التسجيل وعلى كل قفزة إرسال — تُرفض نطاقات الإنترانت وعنوان البيانات الوصفية للسحابة، ويُعاد فحصها لهزيمة إعادة ربط DNS. ذلك مدمج؛ لا تضبطه. ثانياً، يطرح مستوى الاستقلالية tight إعداد egress مسبق لـ SSRF يرفض أسماء الأدوات على هيئة جلب — http_fetch، web_search، fetch_url، request، وصيغها ذات مساحة الأسماء <server>.* — فتُوقَف أداة وظيفتها كلها “اذهب واجلب هذا URL” قبل أن تطلب. لحكم أين قد تصل الأدوات حسب الوجهة، ألّف قاعدة egress خاصة بك بقائمة رفض host/CIDR — ذلك هو السطح لتثبيت الامتداد الصادر: 
// firewall rule, egress stage — deny outbound to an internal range.
// egress_json is a JSON *string*: {"deny":[…],"allow":[…]} of hosts/CIDRs.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\",\"169.254.169.254\"]}"
}
لا يطرح أي إعداد مسبق قواعد egress بـ CIDR — يطابق إعداد SSRF المسبق أسماء الأدوات، لا الوجهات. ألّف قائمة رفض host/CIDR بنفسك عندما تحتاج تحكماً على مستوى الوجهة. انظر قوائم egress و أوقف التسريب.

​
6. أبقِ بيانات اعتماد الخادم مشفَّرة

auth_json لكل خادم MCP مشفَّر في حالة السكون ومقنَّع عند القراءة؛ تحقن البوابة بيانات الاعتماد وقت الإرسال، فلا تصل أبداً إلى النموذج أو العميل. قيم auth_mode المدعومة:
{ "token": "…" } — رمز bearer ساكن، يُرسَل كـ Authorization: Bearer.
{ "client_id": "…", "client_secret": "…", "token_url": "…" } — OAuth ببيانات اعتماد العميل؛ تجلب البوابة الرمز وتجدّده.
{ "username": "…", "password": "…" } — مصادقة HTTP Basic.
"" — خادم غير مصادَق. الافتراضي.
عند القراءة يُقنَّع السر؛ أعِد القناع عند التحديث للإبقاء على القيمة المخزَّنة. تخبرك حالة الخادم status (ok / degraded / down) من آخر فحص ما إذا كان قابلاً للوصول قبل أن تعتمد عليه.

​
7. أضف حاجز حماية للمحتوى على الطلب

يحكم جدار الحماية الإجراءات؛ قرِنه بـ حاجز حماية بحيث يُفحص النص المتحرك عبر وكيل MCP لديك أيضاً. يلتقط الإعداد المسبق Secrets Blocker بيانات الاعتماد في طلب قبل أن يراها النموذج — أو أي أداة — أبداً، ويقنّع PII Shield المعرّفات في طريق الدخول. يأتي كلاهما مع مستوى الاستقلالية tight، أو اربط حاجز حماية مسمّى بمفتاح ترحيل الوكيل عبر guardrail_id.
حكم sanitize لجدار الحماية ينقّح وسائط استدعاء الأداة، لا المحتوى الذي تعيده أداة أبداً. جرّد الأسرار من الطلب بحاجز Secrets Blocker؛ نقّح الوسائط التي يصدرها وكيل بقاعدة جدار حماية. يغطّيان نصفين مختلفين من التدفّق.

​
8. تحقّق وراقب

تأكّد أن السياسة تفعل ما تتوقّعه قبل أن تثق بها، ثم أبقِ عينك على التغذيات:

اختبر استدعاء أداة

شغّل تجريبياً عيّنة tools/call مقابل سياستك وارَ الحكم، والقاعدة المطابقة، والسبب — لا يُرسَل شيء، ولا يُسجَّل شيء.

الأدوات المكتشفة

كل أداة رأتها مساحة العمل، مُعلَّمة covered أو gap — ألّف القواعد مباشرةً من حركة MCP الحقيقية.

Events وRuns

كل إرسال، وحكمه، والسطح الذي اصطدم به، مجمّعاً لكل تشغيل وكيل.

تغذية الشذوذ

ارتفاعات المعدل/التكلفة، وحلقات إعادة المحاولة، ومسارات الأدوات الجديدة مقابل خط أساس متعلَّم.

​
9. إلى أين تذهب بعد ذلك

تسميم أدوات MCP

نموذج التهديد خلف الحجر وبوابة MCP.

الوكالة المفرطة

لماذا يهمّ الحجب-الافتراضي وHITL لاستخدام الأدوات المستقل.

وصفة الوكيل المستقل

قوِّ وكيلاً عالي الاستقلالية من طرف إلى طرف.

أوقف التسريب

أحكم إغلاق egress الصادر بعمق.