الانتقال إلى المحتوى الرئيسي
وكيل الذكاء الاصطناعي لا يولّد نصاً فحسب — بل يتصرّف. يستدعي shell.exec، ويستعلم قاعدة بيانات، ويجلب URL، ويرسل أداة عبر خادم MCP. كل واحد من هذه إجراء له عواقب في العالم الحقيقي لا تستطيع حواجز الحماية على مستوى المطالبة رؤيته. جدار حماية الوكيل هو المستوى على مستوى الإجراء الذي يحكمها: سياسة مسمّاة ضمن نطاق مساحة العمل تقيّمها البوابة على كل استدعاء أداة، قبل أن يصل إلى الأداة. هذه الصفحة هي المحور لقسم جدار الحماية — نموذج السياسة، والأحكام، والأسطح، وكيف تُربط سياسة بمفتاح. كل صفحة فرعية تتعمّق أكثر، ويعيش مرجع المحرك الكامل في جدار الحماية وقواعد جدار الحماية.

​
1. ماذا يفعل جدار حماية الوكيل

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

​
2. مثال ملموس

افترض أنك تريد حجب أوامر shell المدمّرة لكن تمرير كل شيء آخر تحت التدقيق. في وحدة التحكم تنشئ سياسة بـ default_verdict = audit وقاعدة واحدة: 
{
  "label": "block rm -rf",
  "tool_name_glob": "*.exec",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|drop table\"}]}",
  "verdict": "deny"
}
args_match_json هي سلسلة مرمّزة بصيغة JSON (تتحقق منها البوابة مقابل مخطط العبارات عند الحفظ): path هو JSONPath إلى وسائط الاستدعاء، وop واحد من eq أو contains أو regex أو in أو cidr_match أو gt أو lt. اربط مفتاحاً بالسياسة (اضبط firewall_policy_id على المفتاح). الآن عندما يصدر وكيل shell.exec بـ command: "rm -rf /"، تعيد البوابة HTTP 400 برمز خطأ firewall_blocked وسبب يسمّي الأداة — ولا يصل الاستدعاء إلى الـ shell أبداً. كل استدعاء أداة آخر مسموح به ومسجَّل للمراجعة.
اطرح سياسة جديدة تحت وضع الظل أولاً: تقيّم وتسجّل تماماً كما ستفعل في الإنتاج، لكن يُخفَّض كل حكم فارض إلى audit ويُسبَق السبب بـ [shadow] would …. راقب تغذية الأحداث، ثم أطفئ وضع الظل لتبدأ الفرض.

​
3. السياسة والقواعد والحل

السياسة ضمن نطاق مساحة العمل ومسمّاة، ولها enabled وis_default وdefault_verdict (allow / audit / deny، الافتراضي audit) وعلامة shadow_mode. القاعدة هي فحص واحد داخلها — انظر إنشاء سياسة و مخطط القاعدة. لأي استدعاء أداة تحل البوابة السياسة النشطة بهذا الترتيب:
  1. ربط المفتاح — firewall_policy_id للمفتاح المستدعي، عندما تكون تلك السياسة موجودة ومفعّلة.
  2. افتراضي مساحة العمل — وإلا سياسة is_default المفعّلة.
سياسة جدار الحماية المرتبطة المعطّلة تتراجع إلى افتراضي مساحة العمل — وهذا يختلف عن حواجز الحماية، حيث يُحَل الربط المعطّل إلى لا شيء. مفتاح الإطفاء على جدار حماية مفتاح هو “استخدم الافتراضي”، وليس “لا فرض”. انظر إدارة السياسات.
عندما لا تُحَل أي سياسة على الإطلاق، يعتمد السلوك على إعداد firewall_observe_mode لمساحة العمل: مع وضع observe مفعّلاً، يُسمح بالاستدعاء لكنه يُسجَّل كـثغرة تغطية (يظهر في الأدوات المكتشفة)؛ ومع إطفائه، يُسمح بالاستدعاء صامتاً.

​
4. الأحكام

تنتج القاعدة — أو الافتراضي — إحدى القيم:
الحكمماذا يفعل
allowيمرّر، مسجَّل.
auditيسمح + يسجّل للمراجعة. الافتراضي المعتاد.
denyيحجب. HTTP 400 firewall_blocked على inbound؛ خطأ أداة على MCP.
sanitizeينقّح السلاسل الفرعية المطابقة من وسائط الأداة ويعيد التوجيه.
pending_approvalيعلّق لإنسان؛ HTTP 400 firewall_approval_pending.
cap_costيحجب بمجرد أن يتجاوز إنفاق التشغيل سقفاً لكل قاعدة.
حكم sanitize ينقّح وسائط الاستدعاء فقط — وليس أبداً المحتوى الذي تعيده أداة. على سطح inbound، حيث لا توجد وسائط وقت الاستدعاء بعد، يتصاعد sanitize إلى حجب. انظر الأحكام و تطهير الاستجابات.

​
5. أسطح الفرض الأربعة

يُقيَّم كل استدعاء أداة مقابل سطح واحد بالضبط — ثبّت قاعدة على واحد بحقل stage، أو اتركه فارغاً لينطبق على الجميع.

inbound

الأدوات التي يعلن عنها الوكيل للنموذج على الطلب. احجب أداة خطرة قبل أن يتمكن النموذج حتى من اختيارها.

response

استدعاءات tool_calls التي يصدرها النموذج في رده.

mcp

استدعاء tools/call مُرسَل عبر بوابة MCP. انظر خوادم MCP.

egress

مضيف / IP / CIDR صادر تصل إليه أداة — سطح SSRF وتسريب البيانات.

​
6. المطابقة

تعبّر القواعد عن أي استدعاءات أدوات تصطادها بمفردات صغيرة حتمية آمنة على المسار الساخن:
glob حسّاس لحالة الأحرف على اسم الأداة (shell.*، *.delete)، يمكن دمجه اختيارياً بـ AND مع glob على المهارة المالكة. انظر صيغة glob و قائمة السماح للأدوات.
عبارات JSONPath على وسائط الاستدعاء بعوامل eq وcontains وregex وin وcidr_match وgt وlt — الفرق بين “احجب shell.exec” و”احجبها فقط عندما يكون الأمر rm -rf”. تفشل العبارات مغلقةً (القاعدة، وليس الطلب). انظر التحقق من الوسائط.
قوائم سماح ومنع المضيف / IP / CIDR على سطح egress. يمكنك تأليف قاعدة منع خاصة بك لبيانات تعريف السحابة أو نطاقات RFC-1918. انظر التحكم في egress.
قاعدة sequence تطابق سلسلة مرتبة من الاستدعاءات عبر نافذة (تُفرض بشكل تفاعلي)؛ قاعدة cap_cost تحجب بمجرد أن يتجاوز الإنفاق المتراكم لتشغيل وكيل سقف السنتات. انظر قواعد التسلسل وسقف التكلفة.

​
7. الموافقة البشرية والاستقلالية والشذوذ

  • الإنسان في الحلقة. حكم pending_approval يعلّق الاستدعاء ويعيد معرّف موافقته. يحلّه مراجِع في وحدة التحكم (Developer+) أو عبر استدعاء webhook مُوقَّع بـ HMAC؛ يستطلع الوكيل ويعيد التقديم بترويسة X-OrcaRouter-Firewall-Approval أحادية الاستخدام. انظر الموافقات و webhook الموافقة.
  • مستويات الاستقلالية. مفتاح واحد يضبط كامل موقفك: tight (حجب افتراضي
    • حجب shell المدمّر + حجب الأدوات بهيئة الجلب (http_fetch/web_search/fetch_url/request، متجه SSRF) + PII Shield
    • Secrets Blocker مفروضان)، أو balanced (تدقيق افتراضي، حجب shell المدمّر، PII Shield بالتدقيق فقط)، أو permissive (observe فقط). كل واحد يكتب صفوف سياسة وحواجز حماية حقيقية قابلة للتحرير، مع تراجع بنقرة واحدة من لقطة التدقيق.
  • كشف الشذوذ. إلى جانب القواعد الساكنة، يسجّل جدار الحماية نقاط استخدام الأدوات مقابل خط أساس متعلّم لساعة الأسبوع (14 يوماً) ويعلّم ارتفاعات المعدل/التكلفة وretry_loop وnovel_path على تغذية قابلة للقراءة من قبل Member يمكنك تأجيلها حتى 7 أيام.

​
8. أين يقع جدار الحماية

جدار الحماية هو النظير على مستوى الإجراء لمستويين مجاورين:
المستوىيحكممتى تلجأ إليه
حواجز الحمايةنص المطالبة والاستجابةPII، الأسرار، jailbreaks، نية الحقن
جدار حماية الوكيلإجراءات الأدواتأي أدوات، استدعاءات MCP، مضيفون، وتكلفة
الامتثالالأدلة والأطرجاهزية SOC 2 / HIPAA / EU AI Act
يمكن أن ينطبق كلا مستويي المحتوى والإجراء على طلب واحد، ويضبطهما مستوى استقلالية معاً. انظر حواجز الحماية مقابل جدار الحماية ومجموعة التحكم.

​
9. الربط والتوصيل

تُربط سياسة بمفتاح عبر firewall_policy_id (مضبوط في وحدة التحكم؛ يعيش الربط على المفتاح في البوابة). هناك طريقتان يصل بهما استدعاء أداة إلى المحرك، كلاهما يتطلب مفتاحاً ضمن نطاق بوابة جدار الحماية (is_firewall_gateway = true) — مفتاح ترحيل عادي يحصل على 403 على هذه المسارات:
  • بوابة MCP — وجّه عميل MCP الخاص بك إلى نقطة النهاية الموحَّدة ANY /api/v1/firewall/mcp؛ كل tools/call يُقيَّم مضمّناً. انظر خوادم MCP.
  • خطّاف Evaluate — استدعِ POST /api/v1/firewall/evaluate (أو /evaluate_plan لخطة متعددة الخطوات) من حلقة وكيلك قبل الإرسال، وتصرّف بناءً على الحكم.
كل ضبط وحدة التحكم يعمل ضمن جلستك عبر /api/workspace/firewall/*. قراءات السياسات والإعدادات والأدوات المكتشفة ومحاكي الاستقلالية للقراءة فقط وتغذية الشذوذ مفتوحة لكل عضو في مساحة العمل؛ صندوق رمل Test للتشغيل التجريبي، وسجل الأحداث / التشغيلات، وكل الكتابات تتطلب Developer+. انظر مفاتيح البوابة و اختبار القواعد.

​
10. التهديدات التي يعالجها هذا المستوى

استدعاءات أدوات خطرة

احجب shell المدمّر، وحذف قواعد البيانات، والأفعال المحفوفة بالمخاطر بـ glob + الوسائط.

تسريب البيانات

قوائم egress وقواعد التسلسل قراءة-ثم-تصدير.

تسميم أدوات MCP

تقييم لكل استدعاء على سطح mcp قبل الإرسال.

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

الموافقات، وسقوف التكلفة، وموقف الحجب الافتراضي.

​
الخطوات التالية

إنشاء سياسة

حرّر أول سياسة وقاعدة لك.

الأحكام

ماذا يفعل كل حكم على السلك.

سجل الأحداث

اقرأ ما قرّره جدار الحماية ولماذا.