الانتقال إلى المحتوى الرئيسي
يطبّق OrcaRouter أربع طبقات على كل طلب بترتيب ثابت. كل طبقة مستقلة، ضمن نطاق مساحة العمل، وتُربط بمفتاح API دون أي تغيير في الكود. تسير هذه الصفحة مع طلب واحد عبر الطبقات الأربع بالتسلسل، ثم تغطي ترتيب الحل وسلوك fail-open/fail-closed. للمقدمة الأشمل انظر تأمين وكلاء الذكاء الاصطناعي مع OrcaRouter.

​
1. الطبقة 1 — مفتاح API المحدد النطاق

المفتاح هو البوابة الأولى. قبل فحص أي محتوى أو استدعاء أي نموذج، تحل البوابة المفتاح المتصل وتقرر ما إذا كان الطلب مسموحاً به أصلاً. ما يحمله المفتاح:
  • model_limits — مجموعة النماذج التي يجوز للمفتاح استدعاؤها. يُرفض طلب لنموذج خارج القائمة فوراً.
  • allow_ips — قائمة سماح IP اختيارية. يُرفض طلب من مصدر غير مدرج.
  • credit_limit_usd — سقف إنفاق صارم. يُرفض طلب سيدفع المفتاح فوق السقف.
  • expiry — تاريخ انتهاء صارم. المفاتيح المنتهية الصلاحية مرفوضة.
  • environment — وسم (production، staging، dev، …) لتنظيم وتحديد المفتاح حسب بيئة النشر.
  • guardrail_id — سياسة حاجز الحماية المرتبطة بهذا المفتاح (انظر الطبقة 2 والطبقة 4).
  • firewall_policy_id — سياسة جدار الحماية المرتبطة بهذا المفتاح (انظر الطبقة 3).
  • is_firewall_gateway — يُعلّم المفتاح كرمز ضمن نطاق بوابة جدار الحماية؛ مطلوب لمسارات التقييم وبوابة MCP.
الطلب الذي يفشل في التحقق من المفتاح لا يصل إلى نموذج قط — ولا يُقاس. أين تضبط: وحدة التحكم ← مفاتيح API، أو واجهة برمجية للرمز. يتطلب Developer+ للإنشاء أو التحرير؛ is_firewall_gateway وقراءة المفتاح بنص صريح تتطلبان Admin. لنموذج المفتاح الكامل انظر النطاق والمفاتيح والسياسات ومساحات العمل.

​
2. الطبقة 2 — حواجز المدخلات

بمجرد التحقق من المفتاح، تشغّل البوابة قواعد مرحلة المدخلات لحاجز الحماية المرتبط على نص الطلب — قبل أي استدعاء لنموذج أعلى. ما تراه: رسائل المتصل كما أُرسلت. (مطالبة محقونة من سجل مطالبات تُضاف لاحقاً في مرحلة التوجيه؛ قواعد المدخلات لا تراها.) أنواع القواعد المتاحة: keyword، regex، pii، max_chars، external، llm_judge، grounding. الإجراءات التي يمكن للقاعدة إنتاجها:
الإجراءما يحدث
blockيُرفض الطلب — HTTP 400 guardrail_blocked. لا يُحاسَب أي رصيد. يُعلَّم skip-retry.
maskيُنقَّح التطابق (مثل jane@acme.com ← [EMAIL]). يستمر النص المُعقَّم للنموذج.
flagيُسجَّل التطابق؛ حركة المرور غير متغيرة.
block في هذه المرحلة يعني عدم استدعاء النموذج قط. التكلفة: صفر. يرى المتصل خطأ مُهيكلاً يسمّي حاجز الحماية والقاعدة التي أُطلقت. أين تضبط: وحدة التحكم ← Guardrails، أو واجهة برمجية لحواجز الحماية. يتطلب Developer+ للإنشاء أو التعديل. انظر حواجز الحماية للمرجع الكامل للقواعد.

​
3. الطبقة 3 — تشغيل النموذج

إذا كان المفتاح صالحاً وحواجز المدخلات تمر، تُعيد البوابة توجيه الطلب إلى النموذج الأعلى. هذه الطبقة الوحيدة التي ليس فيها تطبيق قابل للضبط — إنها ببساطة النموذج يقوم بعمله. يعمل جدار الحماية على الإجراءات التي ينتجها النموذج (الطبقة 3 ← الطبقة 4 أدناه)، وليس على النموذج نفسه. التوجيه والاحتياطات وموازنة التحميل تحدث هنا بشفافية.

​
4. الطبقة 4 — جدار الحماية للوكيل (استدعاءات الأدوات والخروج)

بعد استجابة النموذج — أو مضمّناً، مع إصدار استدعاءات الأدوات — يحكم جدار الحماية للوكيل في كل إجراء يطلبه النموذج. أسطح التطبيق الأربعة:
السطحما يراه جدار الحماية
inboundتعريفات الأدوات التي يُعلن عنها الوكيل للنموذج. يحجب أداة خطرة قبل أن يتمكن النموذج من اختيارها.
responsetool_calls التي يُصدرها النموذج في رده.
mcptools/call مُرسَل عبر بوابة Firewall MCP أو خطّاف التقييم.
egressوجهة شبكية صادرة (host / IP / CIDR) يُبلّغ عنها أداة — سطح SSRF وتسريب البيانات.
الأحكام التي يمكن للقاعدة (أو الافتراضي) إنتاجها:
الحكمما يفعل
allowيمرّ الاستدعاء. يُسجَّل.
auditيمرّ الاستدعاء؛ يُسجَّل للمراجعة. الـ default_verdict الافتراضي.
denyيُحجب الاستدعاء — HTTP 400 firewall_blocked على سطح inbound؛ خطأ أداة على mcp.
sanitizeتُنقَّح السلاسل الفرعية المطابقة من وسائط الأداة؛ يمرّ الاستدعاء المُنظَّف. على inbound (لا وسائط بعد)، يتصاعد إلى deny.
pending_approvalيُعلَّق الاستدعاء؛ مراجع خارج النطاق يوافق أو يرفض؛ يُعيد الوكيل التقديم برمز موافقة أحادي الاستخدام.
cap_costيُرفض بمجرد تجاوز الإنفاق المتراكم لتشغيل الوكيل سقف السنتات لكل قاعدة.
deny على سطح inbound لا يكلّف رموز نموذج — الحجب يُطلق قبل الاستدعاء الأعلى. pending_approval يُعيد HTTP 400 firewall_approval_pending مع معرّف موافقة يستطلعه العميل. أين تضبط: وحدة التحكم ← Firewall، أو واجهة برمجية لجدار الحماية. يتطلب Developer+ لإنشاء أو تعديل السياسات والقواعد. انظر جدار الحماية وقواعد جدار الحماية للغة القواعد الكاملة.

​
5. الطبقة 5 — حواجز المخرجات

بعد استجابة النموذج (وبعد اكتمال أي دورة استدعاء أداة)، تشغّل البوابة قواعد مرحلة المخرجات لحاجز الحماية المرتبط على نص الاستجابة قبل وصولها للمتصل. تنطبق نفس أنواع القواعد والإجراءات كما في الطبقة 2. block على المخرجات يُعيد HTTP 400 guardrail_blocked ويردّ الرصيد المُستهلك مسبقاً — لا يدفع المتصل شيئاً.
البث وإخفاء المخرجات. يُطبَّق إجراء block على كلٍّ من الاستجابات المبثوثة وغير المبثوثة — على البث، يقطع الماسح المسار في منتصفه ويُصدر رسالة بديلة. إجراء mask على المخرجات ينطبق حالياً على الاستجابات غير المبثوثة فقط؛ على الاستجابة المبثوثة يمر الجزء الأصلي دون إخفاء. تحقّق من مجموعة المرحلة/البث الخاصة بك في sandbox حاجز الحماية قبل الاعتماد عليها.

​
6. الطبقة 6 — التدقيق

كل تطابق وحكم وقرار موافقة يُكتب في مسار التدقيق، مرتبطاً بتشغيل الوكيل والجلسة التي تسببت فيه. هذه ليست خطوة تطبيق منفصلة — إنها تعمل بالتوازي مع الطبقات 2–5 — لكنها الطبقة التي تجعل الطبقات الأخرى مساءلة. ما يُسجَّل:
  • تطابقات حواجز الحماية: نوع القاعدة، الإجراء، المرحلة، سلسلة التفصيل، و(إذا فُعّل Log raw content) السلسلة الفرعية المطابقة.
  • أحداث جدار الحماية: السطح، اسم الأداة، الحكم، القاعدة المطابقة، رمز السبب، عوامل المخاطرة، والتشغيل/الجلسة التي ينتمي إليها الاستدعاء.
  • قرارات الموافقة: من وافق أو رفض، متى، وما إذا كانت القاعدة الأساسية قد تغيرت بين التعليق والقرار.
  • تغييرات السياسة: كل إنشاء وتحديث وحذف وتغيير مستوى استقلالية يكتب صف تدقيق مُصدَّر.
أين تراجع: وحدة التحكم ← Guardrails ← Matches؛ وحدة التحكم ← Firewall ← Events وRuns & Sessions وAudit. تغذية Matches لحواجز الحماية مفتوحة لأي Member في مساحة العمل؛ تغذيتا Events وRuns & Sessions لجدار الحماية تتطلبان Developer+.

​
7. جدول الملخص

الطبقةما تتحكم فيهما تراهالنتيجة عند تطابقأين تضبط
1. مفتاح محدد النطاقالهوية، الوصول للنموذج، الإنفاق، IP، الانتهاءرمز مصادقة الطلبHTTP 4xx قبل أي تشغيل؛ لا قياسوحدة التحكم ← مفاتيح API (Developer+)
2. حواجز المدخلاتمحتوى نص الطلبرسائل المتصلحجب (HTTP 400 guardrail_blocked، لا رسوم)، إخفاء، أو تعليموحدة التحكم ← Guardrails (Developer+)
3. النموذج———ضبط التوجيه/القناة
4. جدار الحماية للوكيلاستدعاءات الأدوات، إرسال MCP، الخروجاسم الأداة، الوسائط، الوجهةallow / audit / deny / sanitize / pending_approval / cap_costوحدة التحكم ← Firewall (Developer+)
5. حواجز المخرجاتمحتوى نص الاستجابةرد النموذجحجب (HTTP 400، رد الرصيد)، إخفاء، أو تعليموحدة التحكم ← Guardrails (Developer+)
6. التدقيقالإسناد والمساركل ما سبقإدخال سجل غير قابل للتغييروحدة التحكم ← Matches (Member) / Events & Runs (Developer+)

​
8. ترتيب حل السياسات

لأي طلب، يُحَل حاجز الحماية النشط وسياسة جدار الحماية بشكل مستقل:
  1. ربط المفتاح — إذا كان المفتاح يحمل guardrail_id أو firewall_policy_id صريحاً، وتلك السياسة موجودة ومفعّلة، فإنها تنطبق.
  2. افتراضي مساحة العمل — إذا لم يكن للمفتاح ربط، تنطبق حواجز الحماية أو السياسة is_default المفعّلة لمساحة العمل.
  3. لا هذا ولا ذاك — لا تطبيق. الطلب متطابق بايت ببايت مع مساحة عمل لم تفعّل الميزة أبداً.
يختلف المستويان عندما يكون للسياسة المرتبطة حالة مُعطَّلة: ربط حاجز حماية معطَّل يُطفئ حواجز الحماية لذلك المفتاح (لا تراجع)، بينما ربط جدار الحماية المعطَّل يتراجع إلى سياسة جدار الحماية الافتراضية لمساحة العمل. يمكن لحاجز حماية واحد وسياسة جدار حماية واحدة على الأكثر لكل مساحة عمل أن يكونا الافتراضيَين. ترقية افتراضي جديد يُنزّل القديم في نفس المعاملة.

​
9. fail-open وfail-closed

سلوكان — مُطبَّقان على حالات مختلفة.Fail-open (أخطاء عابرة): إذا اصطدم حل السياسة بخطأ عابر — خلل مؤقت في قاعدة البيانات، أو انقطاع شبكي على الطريق إلى مورّد خارجي — تتدهور البوابة إلى لا تطبيق بدلاً من إسقاط حركة المرور. السلامة تتدهور؛ التوفّر محفوظ. اضبط fail_open: false على قواعد external أو llm_judge عندما يكون فحص فائت غير مقبول لسياستك.Fail-closed (حالات غامضة): حيث يكون عدم التطبيق هزيمةً للقاعدة، يفشل المحرك مغلقاً: تقرير egress بوجهة غير قابلة للحل يُرفض؛ متجر موافقات غير قابل للوصول يُعلَّق الاستدعاء بدلاً من تمريره؛ مهارة لا يمكن حل ملكيتها تُحجب. التوفّر محفوظ على المسار السعيد؛ السلامة لا تُتخطّى صامتةً في الحالات الطرفية المهمة.
انظر أوضاع التطبيق لشجرة القرار الكاملة، وكيف يفحص OrcaRouter الطلبات لميكانيكيات مسار الترحيل.

​
10. التعمق

حواجز الحماية

مرجع القواعد الكامل — الأنواع والإجراءات وكيانات PII وLLM judge والتوجيه وsandbox الاختبار.

جدار الحماية

نموذج السياسة والأحكام والأسطح ووضع الظل وموافقة HITL وكشف الشذوذ.

قواعد جدار الحماية

لغة مطابقة القواعد — أنماط أدوات glob وعبارات الوسائط وقوائم egress والمُطهّرات.

حواجز الحماية مقابل جدار الحماية

أي طبقة تصطاد أي تهديد — ومتى تحتاج كليهما.

النطاق والمفاتيح والسياسات

نموذج المفتاح الكامل: ما يحمله المفتاح وكيف تُحَل السياسات.

أوضاع التطبيق

fail-open مقابل fail-closed — شجرة القرار الكاملة.
كل استدعاء عبر OrcaRouter يمر بجميع طبقات التطبيق الأربع بالترتيب — التحقق من المفتاح، فحص المدخلات، حكم جدار الحماية، فحص المخرجات — مع مسار تدقيق كامل مكتوب عبر جميعها.