الانتقال إلى المحتوى الرئيسي
تنتهي الأسرار حيث لا تنتمي. مطوّر يلصق ملف .env في مطالبة طلباً “للمساعدة في التصحيح”. مستند مسترجَع يحمل مفتاح API مضمّناً. نموذج، حين يُطلب منه “أظهر الإعدادات”، يردّ مفتاح وصول AWS مباشرةً إلى العميل. وكيل يبني استدعاء أداة برمز حيّ مخبوز في الوسائط. كل واحد من هذه مسارٌ لبيان اعتماد كي يفرّ — إلى سجلات مزوّد أعلى، أو إلى نسخة محادثة لعميل، أو إلى أداة تابعة لطرف ثالث. تغطّي هذه الصفحة كيف تتيح لك حواجز الحماية وجدار حماية الوكيل في OrcaRouter الدفاع ضد تسريب llm للأسرار — دون تغيير كود تطبيقك.
يحدث الكشف عند البوابة، أمام كل مفتاح مربوط — فتغطّي سياسة واحدة كل مزوّد، وكل نموذج، وكل وكيل دون أي تغيير في SDK.

​
1. أين تتسرّب الأسرار

يمكن لبيان اعتماد أن يفرّ عند ثلاث نقاط متمايزة في الطلب:
يكون بيان الاعتماد في الطلب قبل أن يعمل النموذج أبداً — مفتاح ملصوق، أو قصاصة .env، أو رمز داخل كتلة RAG مسترجَعة. إن تُرك دون فحص فإنه يصل إلى المزوّد الأعلى وقد ينتهي في سجلاته. أوقفه بحاجز حماية الإدخال Secrets Blocker (§2).
يُصدر النموذج سرّاً إلى عميلك — يجترّ مفتاحاً من سياقه، أو يهلوس سلسلةً على شكل بيان اعتماد. التقطه بـقاعدة أسرار في الإخراج (§3).
يبني وكيلك استدعاء أداة برمز في الوسائط. يُنقّح حكم sanitize لجدار الحماية السلاسل الفرعية المطابقة من الوسائط قبل أن يُرسَل الاستدعاء (§4).
الأوّلان فحصا محتوى (حواجز الحماية)؛ والثالث فحص إجراء (جدار الحماية). طبّق الثلاثة معاً للدفاع المتعمّق.

​
2. Secrets Blocker — أوقف بيانات الاعتماد في المطالبة

Secrets Blocker إعداد مسبق لحاجز حماية تحت فئة secrets يعمل في مرحلة input. يفحص الطلب بحثاً عن أشكال بيانات اعتماد — مفاتيح وصول AWS، ومفاتيح بنمط OpenAI، ورموز GitHub — ويحجب الاستدعاء قبل أن يغادر البوابة. لا يصل بيان الاعتماد إلى نموذج أبداً. ألّفه مرة في وحدة التحكم، اربط مفتاحاً، فيُفحص كل طلب عبر ذلك المفتاح:
1

أنشئ حاجز الحماية

في وحدة التحكم، افتح /console/guardrails، انقر New guardrail، وطبّق الإعداد المسبق Secrets & API-Key Blocker من فئة secrets. يبذر حاجز حماية بقواعد حجب في مرحلة الإدخال لأشكال بيانات الاعتماد الشائعة — حرّر بحرية من هناك.
2

اربط مفتاحاً

افتح /console/token، حرّر مفتاح API، واختر حاجز الحماية من قائمة Guardrail المنسدلة — أو اضبطه كافتراضي لمساحة العمل بحيث يرثه كل مفتاح غير مربوط.
3

أرسل طلباً

استدعِ البوابة تماماً كما من قبل بمفتاح sk-orca-... ذاك:
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "why is AKIAIOSFODNN7EXAMPLE rejected"}
    ]
  }'
يعثر شكل مفتاح AWS على حاجز الحماية ويُرفض الطلب بـ HTTP 400 guardrail_blocked. لا يصل المفتاح إلى النموذج أبداً.
الطلب المحجوب لا يكلّف أي حصة — يُطلق حجب مرحلة الإدخال قبل القياس — ويُعلَّم skip-retry، فإعادة تشغيل نفس المطالبة تحجبها مجدداً فحسب بدلاً من إحراق قناة احتياطية.
تحتاج تغطية أوسع؟ تطرح فئة secrets أيضاً إعداداً مسبقاً Private Keys & Cloud Tokens يحجب مفاتيح PEM الخاصة، ورموز Slack وStripe، ومفاتيح Google API، ورموز JWT. طبّق كليهما — يمكن لحاجز حماية أن يحمل أي عدد من القواعد. ولالتقاط رموز JWT وأشكال بيانات الاعتماد ككيانات مكتوبة (بوسوم [JWT] / [AWS_ACCESS_KEY])، فإن قاعدة pii تغطّي jwt وaws_access_key وapi_key_openai هي البديل المدفوع بالكيانات؛ انظر مرجع حواجز الحماية.
يشغّل مستوى استقلالية tight لجدار الحماية حاجز حماية Secrets Blocker كجزء من موقفه، إلى جانب PII Shield ورفض shell المدمّر. إن أردت مفتاحاً واحداً بدلاً من تأليف القواعد يدوياً، فذلك هو المسار السريع. لكن فحص بيان الاعتماد نفسه هو دائماً حاجز الحماية — وليس ماسح وسائط جدار الحماية.

​
3. احجب الأسرار في مخرجات النموذج

يمكن لسرّ أن يغادر أيضاً في الاستجابة — يردّد النموذج مفتاحاً من سياقه أو يُصدر سلسلةً على شكل بيان اعتماد. أضف قاعدة على مرحلة output لفحص ردّ النموذج قبل أن يعود إلى العميل. تطرح فئة secrets إعداداً مسبقاً Code Secret in Output لهذا تماماً: قواعد حجب في مرحلة الإخراج لمفاتيح PEM الخاصة، ومفاتيح وصول AWS، والرموز السرية بنمط OpenAI. 
{
  "type": "regex",
  "stage": "output",
  "action": "block",
  "pattern": "AKIA[0-9A-Z]{16}"
}
يُفرَض block في الإخراج على الاستجابات غير المتدفّقة والمتدفّقة — على التدفّق، يقطع ماسحٌ الاستجابة في منتصف الطيران قبل أن يصل أي محتوى محجوب إلى العميل. ويردّ حجب الإخراج refunds الحصة المُستهلَكة مسبقاً.
إخفاء الإخراج (استبدال مطابقة بوسم مكتوب بدلاً من رفض الاستجابة بأكملها) ينطبق حالياً على الاستجابات غير المتدفّقة فقط. لبيانات الاعتماد في الإخراج، يكون إجراء block هو الخيار الموثوق على حركة المرور المتدفّقة. أثبت تركيبتك من المرحلة/التدفّق في تبويب Test لحاجز الحماية قبل أن تعتمد عليه.

​
4. نظّف الأسرار من وسائط استدعاء الأداة

حين يبني وكيلك استدعاء أداة، يمكن لبيان اعتماد أن يركب معه في الوسائط. يُنقّح حكم sanitize لجدار الحماية السلاسل الفرعية المطابقة من وسائط استدعاء الأداة ويمرّر الاستدعاء المنظَّف — على سطحي response وmcp، حيث توجد وسائط حيّة وقت الاستدعاء لإعادة كتابتها. قاعدة sanitize تسمّي أي الكواشف تنقّح في إعداد sanitize_json خاصتها — مجموعة من الإعدادات المسبقة المدمجة إضافةً إلى تعبيرات نمطية مخصّصة اختيارية. تُستبدل المادة المطابقة بـ [redacted:<preset>] (والمطابقات المخصّصة بـ [redacted:custom]): 
{
  "priority": 10,
  "label": "Redact AWS keys from tool args",
  "stage": "response",
  "tool_name_glob": "*",
  "verdict": "sanitize",
  "sanitize_json": {
    "presets": ["aws_access_key", "aws_secret_key", "openai_key", "anthropic_key", "bearer_token"],
    "custom": []
  }
}
الإعدادات المسبقة على شكل أسرار المتاحة للمُطهّر هي aws_access_key وaws_secret_key وopenai_key وanthropic_key وbearer_token (إضافةً إلى email وssn_us وcredit_card لـ PII). يجب أن تسمّي قاعدة sanitize إعداداً مسبقاً واحداً أو نمطاً مخصّصاً على الأقل — يُرفض المُطهّر الفارغ عند الحفظ.
ينقّح sanitize الوسائط، لا النتائج. ينظّف وسائط استدعاء أداة ألّفها وكيلك؛ وهو لا يفرك المحتوى الذي تعيده أداة. وعلى سطح inbound — حيث لا توجد وسائط وقت الاستدعاء بعد — يتصاعد sanitize إلى deny. انظر مرجع قواعد جدار الحماية للغة المطابقة.
يبقى حاجز حماية Secrets Blocker (§2) دفاعك الأساسي لبيانات الاعتماد في جسم الطلب — ومُطهّر جدار الحماية هو المكمّل على مستوى الإجراء للأسرار التي تظهر تحديداً داخل وسائط استدعاء الأداة.

​
5. تطبيق الدفاعات الثلاثة بالطبقات

أين السرّالطبقة التي توقفهالإجراء
في المطالبةSecrets Blocker (حاجز حماية إدخال)block
في ردّ النموذجقاعدة أسرار الإخراج (حاجز حماية إخراج)block
في وسيط استدعاء أداةمُطهّر جدار الحمايةsanitize
اطرح أي قاعدة جديدة في وضع الظل (جدار الحماية) أو بإجراء flag (حاجز الحماية) أولاً. راقب تغذية الأحداث / Matches للتأكّد من أنها تُطلق على بيانات اعتماد حقيقية لا على متشابهات حميدة، ثم بدّل إلى الإجراء الفارض.

​
6. راقب ما الذي أُطلق

كل قاعدة حاجز حماية تُطلق تسجّل مطابقة — نوع القاعدة، والإجراء، والمرحلة، وسلسلة تفصيل — إلى تغذية Matches لمساحة العمل (GET /api/guardrail/match، Member). تُسجَّل السلسلة الفرعية المطابقة فقط عندما يكون “Log raw content” مفعّلاً، وهو مطفأ افتراضياً — الموقف المحافظ على الخصوصية، كي لا تصبح تغذية Matches نفسها مكاناً تتراكم فيه الأسرار. اتركه مطفأً لقواعد بيانات الاعتماد ما لم تحتج تحديداً السلسلة الفرعية للفرز. تنتهي قرارات sanitize لجدار الحماية في تغذية Events لجدار الحماية (GET /api/workspace/firewall/events، Developer+)، مع عدم تسجيل الأسرار وكتل القواعد أبداً.

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

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

أنواع القواعد، وكيانات PII، والإعدادات المسبقة، وصندوق رمل الاختبار، وأداة التقييم بالكامل.

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

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

كشف PII

تهديد المحتوى الشقيق: البيانات الشخصية في المطالبات والاستجابات.

تسريب البيانات

حين يصبح بيان اعتماد مسرَّب حمولة استدعاء تسريب صادر.

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

أي مستوى يوقف أي صنف من التسرّب، وكيف يتكاملان.

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

الموقف المبدئي الذي يشغّل هذه الدفاعات معاً.