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

​
1. سياسة الأمان لكل مفتاح: حقلان على مفتاح

يفحص حاجز الحماية النص الذي يتدفق عبر نموذج (PII، الأسرار، jailbreaks). وتحكم سياسة جدار الحماية استدعاءات الأدوات التي يصدرها وكيل (أي أدوات، أي خوادم MCP، أي مضيفين). كلاهما سياسات مسمّاة ضمن نطاق مساحة العمل — تُنشأ مرة واحدة، تُشارَك عبر مساحة العمل — ويختار مفتاح واحدة محددة عبر حقلين:
الحقليربطيُضبط في وحدة التحكم
guardrail_idحاجز الحماية الذي يفحص مطالبات هذا المفتاح واستجاباته.Developer+
firewall_policy_idسياسة جدار الحماية التي تقيّم استدعاءات أدوات هذا المفتاح.Developer+
كلاهما يُضبط في محرّر المفاتيح عند /console/token. ضبط أيٍّ منهما هو إجراء Developer+ — والسياسات نفسها تُنشأ أيضاً Developer+ (انظر النطاق والمفاتيح).
هذان الحقلان مستقلان. يمكن لمفتاح أن يربط حاجز حماية ولا يربط سياسة جدار حماية، أو العكس، أو كليهما، أو لا شيء — يُحَل كل مستوى من تلقاء نفسه. ترك حقل غير مضبوط (0) ليس مثل إطفاء الفرض؛ انظر §3.

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

لنقل إن حاجز الحماية الافتراضي لمساحة عملك يعلّم PII لكنه يمرّرها، وسياسة جدار الحماية الافتراضية تدقّق كل استدعاء أداة. هذا جيد لمعظم الوكلاء — لكن وكيلك المالي يتعامل مع أرقام الضمان الاجتماعي للعملاء وينبغي ألا يستدعي أداة shell أبداً. أنشئ finance-guardrail أكثر صرامة (يحجب PII تماماً) وfinance-firewall (يسمح فقط بالأدوات الثلاث التي يحتاجها)، ثم اربط كليهما بمفتاح ذلك الوكيل: 
# الضبط عبر وحدة التحكم (UserAuth — جلستك)، وليس مفتاح ترحيل.
# هذا هو استدعاء تحديث المفتاح الذي يجريه المحرّر في /console/token.
PUT /api/token
{
  "id": 4127,
  "name": "finance-agent",
  "guardrail_id": 12,          // finance-guardrail (PII = block)
  "firewall_policy_id": 8      // finance-firewall (قائمة سماح بـ 3 أدوات)
}
من الطلب التالي فصاعداً، تُفحص حركة مرور ذلك المفتاح بواسطة حاجز الحماية 12 وتُقيَّم استدعاءات أدواته بواسطة السياسة 8 — بينما يبقى كل مفتاح آخر في مساحة العمل يشغّل افتراضيات مساحة العمل. لا يتغيّر كود الوكيل نفسه أبداً؛ يبقى يستدعي https://api.orcarouter.ai/v1/... بمفتاحه sk-orca-… تماماً كما كان.
هذا هو نمط الاستقلالية الأدنى: مفتاح واحد محدّد النطاق بدقة لكل وكيل، كلٌّ مربوط بالسياسات التي يحتاجها عمله فعلاً. حين يُخترَق ذلك الوكيل، يكون نطاق الانفجار هو ما كان مفتاحه مخوَّلاً للقيام به — لا شيء أكثر. انظر قائمة تحقّق الاستقلالية الأدنى.

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

لكل طلب، تحلّ البوابة حاجز الحماية النشط وسياسة جدار الحماية النشطة بشكل مستقل. يبدو الترتيب متطابقاً لكليهما — الربط أولاً، افتراضي مساحة العمل ثانياً — لكنهما يتباعدان في حالة واحدة.

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

يشير guardrail_id للمفتاح إلى حاجز حماية موجود ومفعّل. يفحص ذلك الحاجز الطلب.
تعطيل حاجز الحماية المربوط هو مفتاح إطفاء. لا يحصل المفتاح على أي فحص محتوى — فهو لا يتراجع إلى افتراضي مساحة العمل. هذا متعمّد: ربط حاجز حماية وتعطيله هو كيف تُطفئ الفحص لذلك المفتاح.
لا guardrail_id على المفتاح. ينطبق حاجز الحماية الافتراضي المفعّل لمساحة العمل، إن وُجد.
لا ربط ولا افتراضي لمساحة العمل ← يمرّ الطلب دون فحص محتوى.

​
حل جدار الحماية

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

​
4. كيف يبدو الحجب

عندما ترفض سياسة مربوطة طلباً، يرى المستدعي خطأً مهيكلاً — يمكن للوكيل أن يتفاعل بدلاً من الانهيار:
المستوىرمز الخطأHTTPالتكلفة
حاجز الحمايةguardrail_blocked400لا شيء — حجب مدخل يُطلق قبل القياس؛ وحجب مخرج يُعيد المبلغ. مُعلَّم skip-retry.
جدار الحماية (inbound)firewall_blocked400حجب inbound يُطلق قبل استدعاء النموذج، فلا رموز نموذج. Skip-retry.
جدار الحماية (مُعلَّق)firewall_approval_pending400مُعلَّق لموافقة بشرية؛ يستطلع الوكيل ويعيد التقديم بمجرد الموافقة.
كلا جسمي الخطأ على هيئة OpenAI ويسمّيان السياسة والسبب، فيمكن لوكيلك أن يتفرّع على الرمز. انظر المراجع العميقة لسجل الحدث الكامل وكيف تُسجَّل المطابقات.

​
5. إلى أين تذهب بعد ذلك

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

النموذج الكامل بثلاثة مستويات — مساحة العمل، السياسة، المفتاح — وكل حقل يحمله مفتاح.

كائن الرمز

كل حقل على مفتاح: model_limits، allow_ips، credit_limit_usd، expired_time، وربطا السياسة.

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

أنشئ سياسة المحتوى التي تربطها عبر guardrail_id — القواعد، وكيانات PII، والإجراءات، والإعدادات المسبقة.

جدار الحماية

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