الانتقال إلى المحتوى الرئيسي
تُطلق قاعدة جدار الحماية عند نقطة محددة في دورة حياة استدعاء الأداة. تلك النقطة هي مرحلتها — واحدة من أربعة أسطح فرض، كل منها يرى شريحة مختلفة من الاستدعاء. ثبّت قاعدة على المرحلة الخاطئة فترى البيانات الخاطئة: قائمة سماح egress على سطح inbound لا وجهة لها لتفحصها؛ وعبارة وسائط على inbound لا وسائط استدعاء لها بعد. هذه الصفحة هي الدليل المركّز لمراحل جدار حماية الوكيل الأربع: ما يرصده كل سطح، ومتى يجب أن تستهدفه قاعدة، والطريقة الملموسة الواحدة التي تُعبَّر بها نفس النية في مراحل مختلفة. لمفردات القواعد الكاملة، انظر قواعد جدار الحماية؛ ولنموذج السياسة حولها، جدار الحماية.

​
1. المراحل الأربع في لمحة

يُختَم كل تقييم بمرحلة واحدة بالضبط. قاعدة بلا مرحلة ("") تنطبق على كل المراحل؛ وقاعدة مثبّتة على مرحلة واحدة تُطلق هناك فقط.
المرحلةماذا يرى السطح
inboundالأدوات التي يعلن عنها الوكيل على الطلب
responseاستدعاءات tool_calls التي يصدرها النموذج في رده
mcpاستدعاء tools/call مُرسَل عبر بوابة MCP
egressمضيف / IP / CIDR صادر تصل إليه أداة
أسماء المراحل قيم enum ثابتة — تضبطها حرفياً في حقل المرحلة بمحرر القواعد، أو كخاصية stage عند التأليف عبر API.
المرحلة تحكم أي بيانات في النطاق، وليس مدى صرامة الحكم. الـ deny هو deny على أي مرحلة؛ ما يتغيّر هو ما إذا كانت القاعدة تملك الوسائط، أو اسم الأداة، أو الوجهة التي تحتاج المطابقة عليها.

​
2. inbound — الأدوات التي يعلن عنها الوكيل

السطح الأبكر. قبل أن يعمل النموذج أبداً، يرسل وكيلك قائمة تعريفات أدوات مستعد للسماح للنموذج باستدعائها. ترى مرحلة inbound تلك المجموعة المُعلَن عنها ويمكنها حجب أداة خطرة قبل أن يتمكن النموذج حتى من اختيارها. لا توجد وسائط استدعاء في هذه المرحلة — لم يقرر النموذج بعد كيف يستدعي أي شيء — فقواعد inbound تطابق على اسم الأداة (واختيارياً مهارتها المالكة)، وليس على args_match_json.
حكم sanitize على inbound لا شيء له لينقّحه (لا وسائط موجودة بعد)، فهو يتصاعد إلى حجب. ألّف قواعد inbound كـ allow / deny صريحة، واحفظ sanitize لمراحل التنفيذ.
استدعاء مرفوض هنا يعيد HTTP 400 برمز firewall_blocked، مسمّى باسم الأداة والسبب، ومعلّماً بـ skip-retry.

​
3. response — استدعاءات الأدوات التي يصدرها النموذج

بمجرد أن يرد النموذج، قد يصدر tool_calls واحداً أو أكثر — استدعاءات ملموسة بوسائط حقيقية. ترى مرحلة response تلك، فهذا حيث تنتمي القواعد على مستوى الوسائط: ليس “احجب shell.exec” بل “احجب shell.exec فقط عندما يكون الأمر rm -rf.” 
{
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
لأن الوسائط التي اختارها النموذج حاضرة، sanitize يعمل هنا — ينقّح السلاسل الفرعية المطابقة من وسائط الاستدعاء ويعيد توجيه الاستدعاء المنظَّف. (sanitize ينقّح وسائط استدعاء الأداة فقط؛ لا يلمس أبداً المحتوى الذي تعيده أداة.)

​
4. mcp — الاستدعاءات المُرسَلة عبر البوابة

عندما يصل وكيل إلى أداة عبر بوابة MCP في OrcaRouter، يُقيَّم كل tools/call على مرحلة mcp قبل إرساله إلى الخادم المسجّل. هذا هو السطح الذي يحكم حركة مرور Model Context Protocol — نفس مفردات glob / الوسائط / الحكم كـ response، مطبّقة على إرسال MCP. الحجب هنا يظهر كـ خطأ أداة (firewall deny: <reason>) بدلاً من فشل نقل، فيرى النموذج الرفض ويمكنه التفاعل — اختيار أداة أخرى، أو سؤال المستخدم، أو التوقف.
تقترن مرحلة mcp بالحكم لكل خادم: لكل خادم MCP مسجّل فحص صحة خاص به واعتمادات مشفّرة، والمهارات المحمّلة عبره تحمل نطاق مخاطرة ووضع فرض. انظر Firewall MCP و مهارات جدار الحماية.

​
5. egress — الوجهة الصادرة التي تصل إليها أداة

السطح الأخير. عندما تبلّغ أداة عن وجهة شبكية صادرة، تطابق مرحلة egress عليها — سطح SSRF وتسريب البيانات. قواعد egress لا تطابق على نمط اسم أداة وحده؛ بل تطابق على قائمة مضيف / IP / CIDR: 
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\"],\"allow\":[\"api.openai.com\"]}"
}
تطابق المدخلات كـ CIDR، أو حرف IP، أو اسم مضيف غير حسّاس لحالة الأحرف. تؤلّف قواعد منع المضيف وCIDR بنفسك — نقطة نهاية بيانات تعريف السحابة (169.254.169.254) ونطاقات RFC-1918 هي الأشياء النموذجية للمنع. انظر قواعد جدار الحماية §6 لقطبية السماح/المنع.
لا يشحن أي إعداد مسبق قواعد CIDR. موقف SSRF لمستوى الاستقلالية tight يحجب أسماء الأدوات بهيئة الجلب (مثل http_fetch وweb_search وfetch_url)؛ أما منع egress القائم على الوجهة فهو شيء تؤلّفه للمضيفين والنطاقات التي يجب ألّا يصل إليها وكلاؤك أبداً.

​
6. اختيار المرحلة الصحيحة

غالباً ما يكون لنفس الهدف الأمني مرحلة مثلى. طابق النية بالسطح الذي يحمل فعلاً البيانات التي تحتاجها:
إذا كان يجب ألّا يرى النموذج أداة أبداً، فارفضها على inbound. يهبط الحجب قبل استدعاء النموذج، فلا يكلّف أي رموز نموذج.
تحتاج عبارات الوسائط إلى الوسائط التي اختارها النموذج، والتي لا توجد إلا على response وmcp. ارفض على وسيطة خطرة، أو sanitize لتجريد سر أو قيمة PII وضعها الوكيل في وسيطة.
الاستدعاءات الموجَّهة عبر بوابة MCP تُقيَّم على mcp قبل الإرسال — نقطة الاختناق لأدوات كل خادم مسجّل.
القواعد القائمة على الوجهة — حجب IP بيانات تعريف السحابة، منع CIDR، إدراج مضيفيك المعتمدين في قائمة السماح — لا معنى لها إلا على egress.
قاعدة بلا مرحلة تعمل على الأربع جميعاً. استخدمها لقاعدة شاملة بأسلوب default_verdict، أو أداة ترفضها أينما ظهرت.

​
7. المراحل ووضع الظل

علامة shadow_mode للسياسة مستقلة عن المرحلة. شغّلها ويُخفَّض كل حكم فارض — على أي مرحلة — إلى audit ويُسبَق السبب بـ [shadow] would …، فيمكنك تأكيد أن قاعدة تُطلق على السطح الصحيح قبل أن تغيّر حركة المرور الحية. انظر وضع الظل و أوضاع الفرض.

​
8. أين تقع المراحل في الصورة الأكبر

المراحل الأربع هي أين الفرض؛ وبقية النموذج هي ماذا ومَن.

الأحكام

ماذا يمكن لكل مرحلة أن تفعل بمجرد المطابقة — allow، audit، deny، sanitize، تعليق للموافقة، سقف التكلفة.

قائمة السماح للأدوات

استخدم inbound لتقييد مجموعة الأدوات التي يعلن عنها وكيل.

التحقق من الوسائط

ألّف عبارات وسائط response / mcp تحكم أداة بـ كيف تُستدعى.

التحكم في egress

احجب الوجهات الصادرة على سطح egress — حدّ التسريب.
لكيفية جلوس هذه الأسطح على مسار الفحص، انظر كيف يفحص OrcaRouter وملاحظات زمن استجابة مسار الفرض. للتهديدات التي تعالجها كل مرحلة، انظر استدعاءات الأدوات الخطرة و تسريب البيانات و تسميم أدوات MCP.