الانتقال إلى المحتوى الرئيسي
لديك سياسة تريد وضعها أمام الإنتاج. الخوف ليس من السياسة — بل من قلبها واكتشاف أنها تحجب أداة يحتاجها وكيلك فعلاً، أو تقنّع حقلاً يعتمد عليه تطبيقك. الإصلاح ليس مزيداً من الاختبار في صندوق رمل؛ بل الطرح مقابل حركة مرور حقيقية في موقف لا يستطيع كسر أي شيء، ثم التشديد فقط بعد أن ترى ما يُطلق. هذه الوصفة هي ذلك الطرح: مراقبة ← ظل ← فرض، باستقلالية balanced قبل tight. تبقى في وحدة التحكم (أو REST API) طوال الطريق؛ يستمر الوكيل في استدعاء https://api.orcarouter.ai/v1/... تماماً كما كان.
جديد على النموذج؟ اقرأ أوضاع الفرض لما يفعله كل موقف آليّاً، وخط أساس الوكلاء الآمنين لما يضبطه كل مستوى استقلالية. هذه الصفحة هي التسلسل — الترتيب الذي تقلب به المفاتيح.

​
1. طرح أمان الذكاء الاصطناعي في ثلاث حركات

يقايض الطرح كله الاستقلالية بـالسلامة في ثلاث خطوات، كل واحدة متحقَّق منها مقابل حركة مرور حية قبل التالية:

راقب

اسمح بكل شيء، سجّل كل شيء. تحطّ استدعاءات الأدوات غير المغطّاة في Discovered Tools؛ تسجّل قواعد flag لحواجز الحماية التطابقات دون تغيير حركة المرور. تتعلّم شكل وكيلك الحقيقي.

ظلّل

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

افرض

الظل مطفأ. deny يحجب، mask ينقّح، pending_approval يعلّق. تنتقل الاستقلالية من واسعة (balanced) إلى ضيقة (tight)، ويصبح وكيلك محكوماً.
الانضباط هو النقطة: لا تفرض أبداً قاعدة لم تراقبها أولاً تُطلق في الظل مقابل حركة مرورك الخاصة.

​
2. الحركة الأولى — مراقبة (الاستقلالية = permissive)

ابدأ أوسع ما يمكن. طبّق مستوى الاستقلالية permissive من Firewall → Posture (Developer+) — أو POST /api/workspace/firewall/autonomy. يفعّل وضع observe لمساحة العمل ولا يترك سياسة فارضة، فيُسمح بكل استدعاء ويُسجَّل كل استدعاء غير مغطّى كـثغرة تغطية. 
# Console: Firewall → Posture → apply "permissive"
# or, via the REST API on your session token:
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "permissive"}'
تعمل مسارات /api/workspace/firewall/* على جلسة وحدة تحكّمك / رمز وصولك، لا على مفتاح ترحيل sk-orca-.... تطبيق مستوى استقلالية كتابة لمساحة العمل — Developer+. وحدها استدعاءات النموذج /v1/* تستخدم مفتاح الترحيل.
الآن وجّه حركة مرور حقيقية نحوه ودعه يعمل. راقب تغذيتين:
  • Firewall → Discovered Tools (Member) — كل أداة يستدعيها وكيلك، مُعلَّمة covered أو gap. هذا مدخل قواعدك: أنت على وشك كتابة سياسة لـحركة مرور تحدث فعلاً، لا افتراضات.
  • Guardrails → Matches (Member) — إن أضفت أي قواعد بإجراء flag، كل تطابق تسجّله، دون لمس الطلب.
دعه يعمل حتى يتوقف Discovered Tools عن إظهار أدوات جديدة. تلك القائمة المستقرة هي مواصفات تأليف قواعدك.

​
3. الحركة الثانية — ظل (سياسة حقيقية، صفر حجب)

الآن ألّف السياسة التي تريدها فعلاً — أنماط globs للأدوات، وعبارات الوسائط، وقوائم egress، وسقف cap_cost — وفعّل shadow_mode قبل أن تربطها. (ابنِ القواعد من قواعد جدار الحماية؛ نموذج السياسة الكامل في مرجع جدار الحماية.) 
{
  "name": "prod-rollout",
  "enabled": true,
  "shadow_mode": true,
  "default_verdict": "audit",
  "rules": [
    { "priority": 10, "tool_name_glob": "shell.exec", "verdict": "deny" },
    { "priority": 20, "tool_name_glob": "*",          "verdict": "cap_cost", "cap_cost_cents": 1000 }
  ]
}
مع shadow_mode: true، يُخفَّض كل من ذلك deny وذلك cap_cost إلى audit وقت التقييم — يحسب المحرك الحكم الحقيقي، يسجّله مسبوقاً بـ [shadow] would …، ويمرّر الاستدعاء. اربط السياسة بالمفاتيح التي تطرحها (اضبط firewall_policy_id على المفتاح) أو اجعلها افتراضي مساحة العمل. ثم اقرأ Firewall → Events / Runs (Developer+) مصفّاة إلى بادئة [shadow] وأكّد كلا الجانبين:
كل استدعاء shell.exec يُظهر [shadow] would deny. كل تشغيل يتجاوز سقفك يُظهر [shadow] would cap_cost. ترى السياسة حركة المرور التي بنيتها لها.
لا أداة مشروعة تظهر بحكم حجب محتمل. هذا فحص الإيجابيات الكاذبة — سبب وجود الظل. إذا عُلِّمت أداة تحتاجها، أصلح القاعدة وأعِد المراقبة قبل أن تفرض أبداً.
حواجز الحماية بلا ظل على مستوى السياسة. المكافئ هو إجراء flag لكل قاعدة: يسجّل تطابقاً في تغذية Matches ولا يغيّر شيئاً، فتستطيع قياس قاعدة محتوى قبل تبديلها إلى block أو mask. شغّل قواعد حواجز حمايتك كـ flag عبر هذه الحركة نفسها.

​
4. الحركة الثالثة — فرض (الاستقلالية balanced، ثم tight)

عندما يبدو سجل الظل صحيحاً، افرض في مرحلتين، لا واحدة. لا تقفز مباشرةً إلى الحجب-الافتراضي. أولاً، balanced. هذا الموقف الفارض الأول الموصى به: الحكم الافتراضي لجدار الحماية audit، لكن أكثر الإجراءات تدميراً (مثل الـ shell المدمّر) مرفوضة، ويعمل حاجز PII Shield بـ تدقيق-فقط — يعلّم PII دون تقنيعها بعد. تحجب الآن أسوأ شيء بينما تراقب الباقي. أطفئ shadow_mode على سياستك الخاصة في نفس الحركة بحيث تنطلق أحكام deny / cap_cost لديها للحياة بجانب خط الأساس. 
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "balanced"}'
راقب Events ساعة. تظهر الحجوب الحقيقية الآن دون بادئة [shadow]. يعيد استدعاء أداة مرفوض HTTP 400 firewall_blocked؛ وهو skip-retry ولا يكلّف أي رموز نموذج. ثم، tight. بمجرد أن يهدأ balanced، انتقل إلى الحجب-الافتراضي. مستوى tight يحجب افتراضياً، ويرفض الـ shell المدمّر و egress الخاص بـ SSRF، ويفرض PII Shield + Secrets Blocker — تُقنَّع PII على الطلب قبل أن يراه النموذج، وتُحجب الأسرار في طلباتك. تعيد مطالبة محجوبة HTTP 400 guardrail_blocked، ولا تكلّف أي حصة، وهي skip-retry.
المرحلةجدار الحماية (الإجراءات)حواجز الحماية (النص)ما تثبته
permissiveمراقبة؛ لا شيء محجوبflag فقطشكل حركة المرور الحقيقي
balancedتدقيق افتراضي؛ الـ shell المدمّر مرفوضPII مُعلَّمةأسوأ حالة موقَفة
tightحجب-افتراضي؛ shell + أدوات على هيئة جلب (SSRF) مرفوضةPII مقنَّعة، الأسرار محجوبةانعدام ثقة كامل
تحفظ التدفق لـ PII. تحت tight، يقنّع PII Shield الـ PII على الطلب قبل أن يراه النموذج — ذلك حيّ. أما تقنيع استجابة متدفقة من جانب المخرجات فليس حيّاً بعد؛ يُفرض block على المخرجات في التدفق (يقطع الماسح التدفق). إذا كنت تعتمد على تنقيح مخرجات النموذج، تحقّق من تركيبتك من المرحلة/التدفق في تبويب Test لحاجز الحماية أولاً. انظر حواجز الحماية.

​
5. مخرج الطوارئ — تراجع بنقرة واحدة

كل تغيير استقلالية معاملة واحدة تلتقط موقفك السابق، فتستطيع التراجع مباشرةً من Firewall → Posture (أو POST /api/workspace/firewall/autonomy/undo/:audit_id). يمكنك أيضاً ببساطة إعادة تطبيق مستوى أليَن — أنزل tight إلى balanced، أو balanced إلى permissive — في أي وقت.
يستعيد التراجع من لقطة التدقيق لـ آخر تطبيق. إذا أجريت تحريرات سياسة يدوية منذ التطبيق الذي تتراجع عنه، لم تعد تلك اللقطة الأحدث غير المستخدمة ويرفض التراجع بدلاً من إزالة تلك التحريرات صامتاً. عندما يحدث ذلك، أعِد تطبيق مستوى أليَن بدلاً من ذلك — متاح دائماً.

​
6. من أين تأتي أحكام كل حركة

لا يحجب الطرح أبداً شيئاً لم تطلبه، لأن كل موقف يخطّط إلى آلية صريحة قابلة للملاحظة:
الموقفالآليةالنتيجة
المراقبةfirewall_observe_mode لمساحة العمل مفعّل + flag لحاجز الحمايةسماح + تسجيل ثغرات / تطابقات
الظلshadow_mode لكل سياسةحكم حقيقي محسوب، مُخفَّض إلى audit، مُسجَّل [shadow] would …
الفرضshadow_mode مطفأ + استقلالية tight/balanceddeny / mask / cap_cost تنطلق للحياة
المصطلحات الأربعة — وضع observe، وحكم audit، وإجراء flag، و shadow_mode — هي مفاتيح متمايزة، موثَّقة جنباً إلى جنب في أوضاع الفرض.

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

أوضاع الفرض

خريطة الآلية خلف المراقبة والظل والفرض.

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

ما يضبطه كل مستوى استقلالية، وكيف تحاكيه أولاً.

رويض وكيل مستقل

الخطوة التالية بعد أن تفرض: سقوف التكلفة، وكشف الشذوذ، والموافقات.

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

السياسات والقواعد والأحكام ووضع الظل وبوابة MCP بالكامل.
إطلاق تثق به طرح، لا مفتاح. راقب ما يفعله وكيلك، ظلّل السياسة مقابل حركة مرورها الحقيقية، ثم افرض — balanced قبل tight — وكل قاعدة متحقَّق منها على الإنتاج قبل أن تحجب أبداً.