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

​
1. أحكام القواعد الستة

تنتج القاعدة حكماً واحداً بالضبط من ستة. ألّفها في محرر القواعد بوحدة التحكم؛ يجتاز المحرك القواعد بترتيب الأولوية وأول مطابقة تفوز.
يمضي الاستدعاء دون مساس. لا يزال يهبط في تغذية الأحداث كـ allow، فتحتفظ بمسار تدقيق دون حجب أي شيء. استخدمه كتصريح صريح في سياسة حجب افتراضي.
نتيجة حركة مرور مطابقة لـ allow، لكن الاستدعاء معلّم كشيء أردت مراقبته. هذه أيضاً القيمة التي يهبط عليها الحكم الافتراضي خارج الصندوق — راقب كل شيء، لا تحجب شيئاً، حتى تكون مستعداً للفرض.
لا يصل الاستدعاء إلى الأداة أبداً. على سطح inbound يعيد الترحيل HTTP 400 برمز خطأ firewall_blocked، يسمّي الأداة والسبب؛ وعلى سطح mcp يعود كـ خطأ أداة فيمكن للنموذج التفاعل. انظر كيف يبدو الحجب.
ينقّح السلاسل الفرعية المطابقة من وسائط استدعاء الأداة (سر أو PII وضعه الوكيل في حقل command أو body) ويعيد توجيه الاستدعاء المنظَّف. ينقّح الوسائط فقط — وليس أبداً المحتوى الذي تعيده أداة. على سطح inbound لا توجد وسائط استدعاء بعد، فـ sanitize يتصاعد إلى deny. انظر تطهير الاستجابات.
يحوّل الاستدعاء إلى مراجعة خارج النطاق. يعيد الترحيل HTTP 400 برمز firewall_approval_pending ومعرّف موافقة؛ لا يصل الاستدعاء إلى الأداة. يحلّه مراجِع في وحدة التحكم أو عبر استدعاء webhook، ويعيد الوكيل التقديم بترويسة موافقة أحادية الاستخدام. انظر الموافقات.
قاطع دائرة للتكلفة — مؤلَّف كقاعدة لكنه يُحَل إلى allow أو deny وقت التقييم. انظر §3 و سقف التكلفة.
وضع الظل يسطّح الفرض. في وضع الظل، يُخفَّض كل حكم فارض (deny وsanitize وpending_approval وcap_cost الذي حُلّ إلى deny) إلى audit ويُسبَق السبب بـ [shadow] would …. اطرح سياسة فارضة بهذه الطريقة وراقب تغذية الأحداث قبل أن تقلبها للوضع الحي.

​
2. الحكم الافتراضي

الحكم الافتراضي (default_verdict على السياسة) هو ما تفعله السياسة عندما لا تطابق أي قاعدة استدعاء أداة. إنه أرضية موقفك، وخلافاً لحكم القاعدة يقبل ثلاث قيم فقط:
default_verdictعندما لا تطابق أي قاعدة…
audit (الافتراضي)اسمح بالاستدعاء، لكن سجّله. المكان الآمن للبدء.
allowاسمح وسجّل، بلا سجل مراجعة.
denyاحجب أي شيء لا تسمح به قاعدة صراحةً — موقف حجب افتراضي.
تتخلّف سياسة جديدة إلى audit: ترصد كل استدعاء أداة ولا تحجب شيئاً حتى تضيف قواعد فارضة. الأحكام الثلاثة الخاصة بالقواعد فقط — sanitize وpending_approval وcap_cost — لا يمكن أن تكون افتراضية؛ الحكم الافتراضي تراجع شامل، وتلك الأحكام لا معنى لها إلا ضمن نطاق مطابقة محددة.
deny كحكم افتراضي هو حجب افتراضي: أي استدعاء أداة لا تسمح به قواعدك صراحةً بـ allow يُحجب. قوي لوكيل مغلق بإحكام، لكنه سيوقف استدعاءات نسيت إدراجها في قائمة السماح. اقرنه بقواعد سماح صريحة (قائمة السماح للأدوات) واطرحه تحت وضع الظل أولاً.

​
3. cap_cost يُحَل إلى allow أو deny

cap_cost هو الحكم الوحيد الذي ليس هو ما يظهر في أحداثك. تؤلّف قاعدة بسقف cap_cost_cents، لكن وقت التقييم يحلّها المحرك إلى allow أو deny ملموس قبل تسجيل الحدث — فلا تحمل تغذية الأحداث أبداً حكم cap_cost حرفياً، بل فقط allow/deny الذي رآه الوكيل فعلاً. السقف هو لكل تشغيل وكيل: يقارن المحرك الإنفاق المتراكم للتشغيل بسقفك.
  • تحت السقف ← يُحَل إلى allow. (داخلياً يُعامَل هذا كـ غير مطابق، فيستمر التقييم إلى القاعدة التالية بدلاً من السماح لـ cap_cost بالفوز بأول مطابقة كمنحة.)
  • فوق السقف ← يُحَل إلى deny، بسبب يسمّي إجمالي التشغيل مقابل السقف. هذه النتيجة النهائية، نتيجة قاطع الدائرة.
// A rule that caps a run at $5.00 of accumulated spend.
{
  "label": "run cost ceiling",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
cap_cost يُطلق فقط على الأسطح ما قبل الإرسال (inbound وmcp) — النقاط التي يمنع فيها حجب استدعاء الإنفاق فعلاً. على سطحي ما بعد الإرسال response وegress يكون خاملاً (لم يبق شيء لإيقافه)، فيتخطّاه المحرك هناك.

​
4. كيف يُختار حكم

لأي استدعاء أداة، الحل نفسه بغض النظر عن أي حكم يفوز:
تختار البوابة السياسة المرتبطة بالمفتاح المستدعي (firewall_policy_id)، أو افتراضي مساحة العمل — انظر الحل.
تعمل القواعد بترتيب priority ASC. أول قاعدة يطابق سطحها، وglob الأداة، وعبارات الوسائط الاختيارية، ونطاق egress الاختياري جميعاً تنتج الحكم.
إذا لم تطابق أي قاعدة، ينطبق default_verdict للسياسة — audit ما لم تغيّره.
إذا كان الاستدعاء مملوكاً لـمهارة محكومة، فمهارة في وضع block تفرض deny ومهارة في وضع quarantine تصعّد أي شيء دون deny إلى pending_approval.

​
5. سلوك التكلفة وإعادة المحاولة لـ deny

حكم جدار الحماية على سطح inbound يُطلق قبل استدعاء النموذج الأعلى، فـ deny هناك لا يكلّف أي رموز نموذج. الخطأ معلّم بـ skip-retry — إعادة تشغيل نفس الاستدعاء المحجوب ستحجب مجدداً فحسب، فتخبر البوابة العميل ألّا يعيد المحاولة. هذا متمايز عن حجب حاجز حماية، الذي يفحص نص المطالبة/الاستجابة (PII، الأسرار) بدلاً من إجراءات الأدوات، ويعيد خطأه الخاص guardrail_blocked. يمكن لطلب أن يمر عبر كلا المستويين.
كل حكم يترك أثراً. كل تقييم — allow، audit، deny، cap_cost المُحَل، الموافقة المُعلَّقة — يُسجَّل كحدث جدار حماية، قابل للتصفية حسب الحكم والسطح والأداة والتشغيل. تغذية الأحداث هي كيف تؤكّد أن سياسة تنتج الأحكام التي تتوقعها. انظر سجل الأحداث و التحليلات.

​
أين تذهب بعد ذلك

إنشاء وربط سياسة

اختر حكماً افتراضياً واربط سياسة بمفتاح.

سقف التكلفة

ألّف سقف إنفاق وكيف يُحَل لكل تشغيل.

وضع الظل

خفّض كل حكم فارض إلى audit بينما تقيس الأثر.

مرجع القواعد

لغة المطابقة الكاملة خلف حكم.
للتهديدات التي يُقصَد بهذه الأحكام إيقافها، انظر استدعاءات الأدوات الخطرة و الوكالة المفرطة.