الانتقال إلى المحتوى الرئيسي
وكيل يستطيع الوصول للشبكة يمكن تحويله إلى قناة لتسريب البيانات. يزرع مهاجم تعليمات في مستند يقرأه الوكيل — صفحة ويب، أو مقطع مسترجع، أو نتيجة أداة — وتوجّه هذه التعليمات الوكيل لإرسال بيانات حساسة إلى مضيف يتحكم فيه المهاجم، أو لاستطلاع الخدمات الداخلية (SSRF). الوكيل لا “يقرر” التسريب؛ بل ينفّذ ما يبدو له كتعليمة شرعية. تشرح هذه الصفحة كيف يتراكم جدار الحماية للوكيل وحواجز الحماية في OrcaRouter للدفاع ضد تسريب بيانات الذكاء الاصطناعي — دون تغيير كود وكيلك.
يرى جدار الحماية egress فقط للوجهات الموجَّهة عبر البوابة عبر مسار إرسال MCP أو خطّاف evaluate. أداة ينفّذها وكيلك بالكامل داخل عمليته الخاصة تقع خارج رؤيته. وجّه استدعاءات أدوات وكيلك المرتبطة بالشبكة عبر البوابة لتصبح محكومة.

​
1. كيف يعمل الهجوم

المسار المعتاد عبر وكيل يسير في ثلاث خطوات:
  1. الحقن — يقرأ الوكيل محتوى غير موثوق يحمل تعليمات مضمّنة (صفحة ويب، أو مستند مجلوب، أو ملاحظة CRM).
  2. التجميع — تأمر التعليمات المحقونة الوكيلَ بجمع مواد حساسة — مفاتيح API، أو صفوف قاعدة بيانات، أو PII للمستخدمين — باستخدام أدوات يمتلكها بالفعل.
  3. التسريب — يُؤمَر الوكيل بإرسال تلك المواد عبر أداة ذات شكل جلب: http_fetch أو web_search أو fetch_url أو request. الوجهة يتحكم فيها المهاجم.
SSRF له نفس الشكل موجَّهاً للداخل: بدلاً من مضيف خارجي يُوجَّه الوكيل نحو 169.254.169.254 (بيانات تعريف السحابة)، أو منفذ Redis داخلي، أو خدمة خاصة أخرى. انظر حقن المطالبة لخطوة الحقن؛ تركّز هذه الصفحة على خطوة الشبكة.

​
2. قائمة سماح egress — أغلق الوجهات الصادرة

الدفاع الأكثر متانة هو قائمة سماح egress: عدِّد المضيفين الذين يُسمح لوكلائك بالوصول إليهم شرعياً وارفض كل ما عداهم. تستخدم قاعدة egress stage: egress وحقل egress. يتحكم الحكم في القطبية — allow يمرّر الوجهات المدرجة؛ قاعدة deny شاملة ذات أولوية أدنى تحجب الباقي: 
[
  {
    "priority": 10,
    "label": "Allow known API endpoints",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "allow",
    "egress": {
      "allow": [
        "api.openai.com",
        "api.anthropic.com",
        "api.orcarouter.ai"
      ]
    }
  },
  {
    "priority": 20,
    "label": "Deny all other outbound destinations",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny"
  }
]
تُطابق الإدخالات على CIDR، أو عنوان IP مباشر، أو اسم مضيف غير حساس لحالة الأحرف. تُحَل أسماء المضيفين بأفضل جهد وتُعاد مطابقتها مقابل مدخلات IP/CIDR، لذا يُلتقط وجهة مثل 169.254.169.254 المُعادة بـ DNS بقاعدة رفض CIDR 10.0.0.0/8. استدعاء محجوب يُعيد HTTP 400 برمز خطأ firewall_blocked. لرفض النطاقات المعروفة بالخطورة دون قائمة سماح صريحة، اكتب قاعدة رفض egress مستهدفة تُدرج نقطة نهاية بيانات تعريف السحابة (169.254.169.254) والنطاقات الخاصة RFC-1918 (10.0.0.0/8، 172.16.0.0/12، 192.168.0.0/16). راكم قائمة سماحك فوقها بأولوية أدنى حتى تُقيَّم قواعد الرفض أولاً.

​
3. أوقف أدوات الجلب في طبقة الاسم

قبل تقييم وجهة egress أصلاً، يمكنك إزالة القدرة كلياً. يرفض مستوى الاستقلالية tight أدوات http_fetch وweb_search وfetch_url وrequest بنمط glob لاسم الأداة كحاجز خلفي لـ SSRF والتسريب. إذا كان وكيلك لا يحتاج أياً من هذه الأدوات، يزيل tight سطح الهجوم في خطوة واحدة: 
POST /api/workspace/firewall/autonomy
{ "level": "tight" }
لرفض أدوات الجلب دون اعتماد الموقف الكامل tight، اكتب قاعدة رفض لسطح inbound. يحجب inbound الأداة قبل أن يتمكن النموذج من اختيارها — لا يتلقى الوكيل القدرة في قائمة أدواته أبداً: 
{
  "priority": 5,
  "label": "Deny fetch-shaped tools",
  "stage": "inbound",
  "tool_name_glob": "http_fetch",
  "verdict": "deny"
}
كرر ذلك لكل اسم أداة ذات شكل جلب يستخدمها مكدّس وكيلك.

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

يعمل حاجز الحماية Secrets Blocker في مرحلة المدخلات، فيفحص المطالبة بحثاً عن مفاتيح الوصول بأسلوب AWS، ومفاتيح OpenAI، ومفاتيح Anthropic، ورموز GitHub، وأنماط بيانات اعتماد مشابهة قبل مغادرة الطلب للبوابة. إذا اكتُشف سر، يُحجب الطلب — لا تصل بيانات الاعتماد إلى نموذج ولا تظهر في استدعاء أداة. فعّله من لوحة Guardrails، أو كجزء من مستوى الاستقلالية tight. وهو مستقل عن قواعد egress لجدار الحماية.
التهديدالطبقة التي توقفه
المطالبة تحمل مفتاح APISecrets Blocker (حاجز مدخلات)
الوكيل يستدعي أداة جلب نحو مضيف مهاجمقاعدة سماح/رفض egress
أداة ذات شكل جلب مُعلَن عنها للنموذجقاعدة رفض inbound أو مستوى tight
الوكيل يصل لبيانات تعريف السحابة أو RFC-1918قاعدة رفض egress تُدرج هذه CIDRs

​
5. الطرح بوضع الظل

إذا لم تكن متأكداً من المضيفين الذين يصلهم وكيلك شرعياً اليوم، ابدأ في وضع الظل قبل التنفيذ:
  1. أنشئ قواعد egress بقائمة السماح المقصودة واضبط shadow_mode: true على السياسة.
  2. راقب تغذية Events — تظهر الاستدعاءات التي كانت ستُحجب كـ [shadow] would deny مع الوجهة.
  3. عدّل قائمة allow حتى تُرفض فقط الوجهات التي يصلها المهاجمون، ثم أطفئ وضع الظل لبدء التنفيذ.
لا يُحجب أي حركة مرور طالما وضع الظل مفعّل.

​
6. المزيد

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

لغة المطابقة الكاملة — قوائم egress، وCIDRs، وعبارات الوسائط، وجميع الأحكام.

نظرة عامة على جدار الحماية للوكيل

السياسات، والأسطح، ومستويات الاستقلالية، والقابلية للملاحظة.

حقن المطالبة

خطوة الحقن التي توجّه الوكلاء نحو التسريب.

تسميم أدوات MCP

أدوات MCP الخبيثة التي تسجّل قدرات ذات شكل جلب.