بحث KENSAI: كشف خلفية RAG هو فشل معماري، وليس حادثة Prompt

أنظمة RAG لا تتسرّب لأن prompt واحد تصرّف بغرابة مرة واحدة. هي تتسرّب لأن الفرق تكشف تمديدات الخلفية وآثار التصحيح وبقايا المحادثات لطبقة العميل ثم تسمي ذلك تفصيلاً تنفيذياً.

لماذا تهم هذه الإشارة اليوم

تدقيق حديث لروبوت محادثة طبي يعتمد على RAG مهم لأنه أظهر أن الأسطح العادية المرئية للعميل يمكن أن تسرّب الـ prompts وتفاصيل الإعداد والـ schemas والبيانات الوصفية وحتى تاريخ المحادثات القريب. لم يحتج الأمر إلى jailbreak استعراضي. الفضول مع فحص المتصفح كان كافياً.

ما الذي انكسر فعلاً

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

لماذا هذا خلل معماري

إذا كانت الـ prompts وقواعد التوجيه وبيانات الاسترجاع الوصفية وآثار الجلسات الحديثة قريبة جداً من الواجهة الأمامية، فسيرى المستخدم أكثر مما يفترض أن تكشفه الواجهة. هذه ليست مشكلة صياغة. إنها مشكلة حدود حالة. الـ plumbing الرخوة تخلق فرصاً لاحقة لـ prompt injection والتوجيه والاستخراج.

ماذا يجب أن تفعل الفرق الآن

قلّل البيانات الوصفية المرئية للعميل، وافصل أسطح التصحيح عن مسار تسليم المستخدم، واجعل الآثار المؤقتة تنتهي بسرعة، وافحص الـ payloads المرئية في المتصفح كما لو أنها إفصاحات عدائية. أي حقل لا يحتاجه المستخدم لتنفيذ الفعل لا يجب أن يسافر لمجرد الراحة.

خلاصة KENSAI

خصوصية الوكلاء تُكسب في الواجهات والرؤوس والـ payloads وحدود الحالة. إذا كان المتصفح يرى أكثر مما يحتاجه المستخدم، فالنظام بالفعل رخْو أكثر من اللازم. RAG الآمن ممل بالطريقة الصحيحة: تعرّض أقل، وصلات أشد، ومفاجآت أقل.