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

​
1. الأوضاع الثلاثة في لمحة

الوضعما يحدث لحركة المرورالآليةمتى تستخدم
المراقبةتُسمح كل حركة المرور؛ الاستدعاءات دون سياسة تُسجَّل كثغرات تغطيةوضع observe على مستوى مساحة العمل مفعّل؛ قواعد حواجز الحماية تستخدم إجراء flag؛ default_verdict لجدار الحماية هو auditالاكتشاف الأساسي — افهم ما يفعله وكلاؤك فعلاً قبل كتابة قاعدة واحدة
الظلتُسمح حركة المرور؛ سياسة تُقيَّم والحجب المحتمل يُسجَّل كـ [shadow] would …علامة shadow_mode لكل سياسة على سياسة جدار الحمايةالتحقق الآمن قبل الإنتاج — تأكّد من صحة تطبيق السياسة قبل لمس حركة المرور
الفرضتُطبَّق أحكام حقيقية — deny يحجب، sanitize ينقّح، pending_approval يُعلَّقوضع الظل مطفأ؛ إجراءات حواجز الحماية مضبوطة على block / mask؛ أحكام جدار الحماية حيةتطبيق الإنتاج بعد التحقق من السياسة في وضع الظل
متطلبات الدور. يستطيع أي عضو في مساحة العمل قراءة السياسات والإعدادات وعرض الأدوات المكتشفة؛ تغذيتا Events وRuns لجدار الحماية تتطلبان دور Developer. تغيير الإعدادات وإجراءات السياسة أو shadow_mode يتطلب أيضاً Developer أو أعلى.

​
2. وضع المراقبة — قِس قبل أن تُقنَّن

وضع المراقبة ليس مفتاحاً واحداً. إنه مجموعة ثلاث آليات مستقلة تُنتج معاً “اسمح بكل شيء، سجّل كل شيء”:

​
وضع observe لجدار الحماية (إعداد مساحة العمل)

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

​
حكم audit لجدار الحماية (لكل سياسة افتراضياً)

عندما تُحَل سياسة ما لكن لا تطابق قاعدة استدعاء أداة، يُطبَّق default_verdict للسياسة. القيمة الافتراضية لـ default_verdict هي audit — اسمح بالاستدعاء وسجّله للمراجعة. سياسة جديدة بلا قواعد ولا تغيير في الضبط لا تحجب شيئاً ولا تسمح صامتةً بشيء: تُدقَّق في كل ما تراه. audit هو أيضاً حكم قاعدة عادي. قاعدة تطابق وتُنتج audit تمرّر الاستدعاء وتسجّله — النظير لوضع تدقيق حواجز الحماية في جدار الحماية.

​
إجراء flag لحواجز الحماية (إجراء لكل قاعدة)

على جانب حواجز الحماية، إجراء flag هو مكافئ المراقبة: تُطلَق القاعدة، يُسجَّل تطابق في تغذية Matches، ويستمر الطلب دون تغيير. لا حجب. لا تنقيح. استخدم flag عندما تريد قياس قاعدة — رؤية عدد مرات إطلاقها وعلى ماذا — قبل الالتزام بـ block أو mask.
معاً، تُنتج هذه الثلاثة وضع المراقبة: وضع observe يصطاد استدعاءات الأدوات غير المغطاة؛ أحكام audit تغطي استدعاءات الأدوات تحت سياسة لكن ليس بعد تحت قاعدة محددة؛ إجراءات flag تغطي فحوصات حواجز الحماية التي لست مستعداً بعد لفرضها.

​
3. وضع الظل — تحقّق قبل الفرض

وضع الظل هو علامة لكل سياسة (shadow_mode: true) على سياسة جدار الحماية. عندما يكون مفعّلاً:
  • تُقيَّم السياسة كل استدعاء أداة تماماً كما ستفعل في الإنتاج — تُطابَق القواعد وتُحسَب الأحكام وتُختبَر محمولات الوسائط.
  • كل حكم مُطبِّق (deny، sanitize، pending_approval) يُخفَّض إلى audit قبل وصوله للأداة.
  • سبب السجل يُسبَق بـ [shadow] would … حتى ترى في تغذية الأحداث بالضبط ما كان سيُحجب أو يُنقَّح أو يُعلَّق.
وضع الظل هو مفتاح الطرح الآمن. اكتب سياسة، فعّل الظل، وجّه حركة المرور الحقيقية إليها، راقب عروض الأحداث والتشغيلات لساعات أو أيام، تأكّد من أن السياسة تُطلَق على الأدوات الصحيحة ولا شيء غير متوقع، ثم أطفئ وضع الظل لبدء الفرض.
لا يوجد في حواجز الحماية مكافئ shadow_mode على مستوى السياسة — استخدم إجراء flag لكل قاعدة لمراقبة فحوصات حواجز حماية فردية قبل التبديل إلى block أو mask.

​
4. وضع الفرض — أحكام حقيقية، عواقب حقيقية

في وضع الفرض، لا شيء يُخفَّض:
  • جدار الحماية deny ← يرى الوكيل خطأ أداة (MCP) أو HTTP 400 firewall_blocked (سطح inbound). يُسمّي الخطأ الأداة والسبب. يُعلَّم skip-retry.
  • جدار الحماية sanitize ← تُنقَّح السلاسل الفرعية المطابقة من وسائط الأداة ويُعاد توجيه الاستدعاء المُنظَّف.
  • جدار الحماية pending_approval ← يُعلَّق الاستدعاء؛ يحصل الوكيل على HTTP 400 firewall_approval_pending ومعرّف موافقة للاستطلاع.
  • حواجز الحماية block ← HTTP 400 guardrail_blocked، يسمّي حاجز الحماية والقاعدة التي أُطلقت. لا يكلّف رصيداً.
  • حواجز الحماية mask ← يُنقَّح التطابق (مثل jane@acme.com ← [EMAIL]) ويستمر الطلب بالنص المُعقَّم.
للوصول إلى وضع الفرض: أطفئ shadow_mode على سياسة جدار الحماية، وغيّر إجراءات قواعد حواجز الحماية من flag إلى block أو mask حسب الاقتضاء.

​
5. الطرح الموصى به

1

مراقبة — اكتشف ما يفعله وكلاؤك

فعّل وضع observe لمساحة العمل (PUT /api/workspace/firewall/settings، firewall_observe_mode: true). اترك جدار الحماية بلا سياسة (أو سياسة default_verdict هي audit). أضف إجراءات flag لأي قواعد حواجز حماية تريد قياسها.راقب عرض Discovered Tools يمتلئ بكل استدعاء أداة تُجريه وكلاؤك، مُعلَّماً covered أو gap. استخدم هذا كمدخل لكتابة قواعد سياستك الأولى — أنت تكتب قواعد لحركة مرور حقيقية، وليس افتراضية.دع هذا يعمل حتى يستقر عرض Discovered Tools ولديك بيانات كافية لكتابة قواعد مقصودة.
2

ظل — تحقّق قبل الفرض

أنشئ سياسة جدار حماية بـ shadow_mode: true. اربطها بالمفاتيح التي تريد حكمها (أو اجعلها افتراضي مساحة العمل). لحواجز الحماية، أبقِ إجراءات القواعد على flag في هذه المرحلة.تُقيَّم السياسة الآن كل استدعاء أداة حقيقي وتسجّل ما ستفعله. افتح عرضَي Events وRuns وصفّح بحثاً عن بادئة [shadow]. تأكّد:
  • تُطلَق على الأدوات وأنماط الوسائط التي قصدتها.
  • لا تُطلَق على أي شيء تريد السماح به (إيجابيات كاذبة).
اضبط القواعد، أعِد المراقبة، كرّر. عندما يبدو سجل الظل صحيحاً، انتقل للأمام.
3

فرض — اقلب المفتاح

اضبط shadow_mode: false على السياسة. لأي قواعد حواجز حماية كنت تراقبها بـ flag، غيّر الإجراء إلى block أو mask حسب الاقتضاء.راقب تغذية Events لأي حجب غير متوقع في الساعة الأولى. إجراء Undo في سجل التدقيق للاستقلالية يتيح لك استعادة الحالة السابقة بنقرة واحدة إذا احتجت إلى التراجع.

​
6. مستويات الاستقلالية — اضبط كل ذلك دفعة واحدة

ضبط السياسات قاعدةً بقاعدة هو المسار الدقيق. مستويات الاستقلالية هي المسار السريع — تحكّم واحد يضبط بشكل ذري موقف جدار الحماية وحواجز الحماية لمساحة عملك في معاملة واحدة، مع التراجع بنقرة واحدة:
المستوىالوضع المُنتَج
permissiveوضع المراقبة: لا سياسة مُطبِّقة، لا حواجز حماية، وضع observe لمساحة العمل مفعّل — ترى كل شيء، لا شيء محجوب. يرسم على خطوة المراقبة أعلاه.
balancedحكم افتراضي audit، لكن shell المدمّر مرفوض؛ PII Shield يعمل في وضع تدقيق فقط (يُعلّم PII)؛ وضع observe مطفأ. الموقف الابتدائي الموصى به بمجرد معرفة شكل حركة مرورك.
tightفرض كامل: حجب افتراضي، مع shell المدمّر وخروج SSRF مرفوضَين؛ حواجز PII Shield والأسرار مُطبَّقة (تفحص طلباتك لـ PII والأسرار)؛ وضع observe مطفأ.
طبّق عبر POST /api/workspace/firewall/autonomy (Developer+). نقطة نهاية Simulate (GET /api/workspace/firewall/simulate?level=) تعاين ما سيفعله تغيير المستوى قبل تطبيقه.
مستويات الاستقلالية هي طبقة راحة فوق نفس الآليات الموصوفة أعلاه — إنها تضبط default_verdict ووضع observe وقواعد جدار الحماية وإجراءات قواعد حواجز الحماية. إنها لا تُبدّل shadow_mode؛ يبقى ذلك تحكّماً يدوياً لكل سياسة. يمكنك دائماً تجاوز إعدادات فردية بعد تطبيق مستوى.

​
7. خريطة الآليات — أي إعداد يفعل ماذا

هذا الجدول هو المرجع الموثوق. المصطلحات الأربعة مختلفة — لا تخلط بينها:
المصطلحالنوعما يتحكم فيه
وضع Observeإعداد مساحة العملالسلوك عندما يُحَل استدعاء أداة إلى لا سياسة. مفعّل ← سجّل كثغرة (Discovered Tools). مطفأ ← سماح صامت.
حكم auditحكم سياسة / قاعدةالسلوك لاستدعاء أداة تحت سياسة تطابق (أو تتراجع للافتراضي). سماح + تسجيل. الـ default_verdict الافتراضي.
إجراء flagإجراء قاعدة حاجز حمايةيسمح فحص حاجز الحماية بحركة المرور ويسجّل تطابقاً. إجراء المراقبة-دون-فرض لحواجز الحماية.
shadow_modeعلامة لكل سياسة جدار حمايةيُخفَّض كل حكم مُطبِّق (deny/sanitize/pending_approval) إلى audit والسبب يُسبَق بـ [shadow] would ….

خط الأساس للوكلاء الآمنين

الموقف الابتدائي الموصى به والإعداد في خمس دقائق لأمان وكيل انعدام الثقة.

جدار الحماية للوكيل

المرجع الكامل للسياسات والقواعد والأحكام ووضع الظل وبوابة MCP.
أوضاع التطبيق ليست مفتاح تشغيل/إيقاف ثنائياً. انتقل عبر المراقبة ← الظل ← الفرض وقواعدك مُتحقَّق منها على حركة المرور الحقيقية قبل أن تحجبها قط.