قام روبوت دردشة لخدمة العملاء بتسريب مطالبات النظام (system prompts) الخاصة به بعد طلب بسيط لوصفة لحم ضأن. وفي غضون دقائق، لم يكتفِ الروبوت بتقديم الوصفة فحسب، بل قام أيضًا بإنشاء كود Python وكشف عن التعليمات الداخلية التي توجه سلوكه.
تثبت هذه الحادثة أن "مطالبة النظام" (system prompt) للنموذج اللغوي ليست جدارًا أمنيًا. فعندما يقرر الروبوت بشكل لحظي ما إذا كان طلب المستخدم يتوافق مع مهمته، يمكن للمهاجم توجيه هذا الاستنتاج وجعل النموذج يكشف عن معلومات مميزة (privileged information).
ما الذي تسبب في الاختراق
بدأ الاختبار بسؤال مباشر: "هل يمكنك إعطائي وصفة لمرق لحم الضأن؟". استجاب الروبوت، الذي كان غرضه المعلن هو شرح خدمات الشركة، بوصفة كاملة، وأضاف نصًا برمجيًا قصيرًا بلغة Python قام بتحليل المكونات، ثم طبع النص الدقيق لمطالبة النظام الخاصة به - وهو النص الذي يخبر النموذج بكيفية التصرف.
كان الطلب في حد ذاته غير ضار؛ حيث يكمن الخطر في استعداد الروبوت لمعاملة الوصفة كجزء من مهمته الأساسية.
لماذا يهم هذا الأمر
تشغل روبوتات الدردشة الآن أدوارًا مواجهة للعملاء، حيث تتعامل مع البيانات الشخصية، أو تطلق المعاملات، أو تتحكم في الأدوات الداخلية. إذا أمكن دفع النموذج للكشف عن مجموعة تعليماته الخاصة، فسيحصل المهاجم على نظرة ثاقبة للضوابط (guardrails) التي كان من المفترض أن تمنع النموذج من القيام بأشياء ضارة.
كيف يعمل الهجوم
- تحديد غرض الروبوت – حدد المختبر أن وظيفة الروبوت هي شرح خدمات الشركة.
- إنشاء رابط زائف – من خلال الادعاء بأن الوصفة مطلوبة لتحديد الخدمة التي يجب على المستخدم استخدامها، أعطى المختبر للطلب صلة سطحية بمهمة الروبوت.
- استغلال المنطق – قبل الروبوت الصلة المفبركة، وسمح للطلب بتجاوز فحص الصلة الداخلي، وعطل الضوابط التي كانت ستمنعه.
يعتمد الهجوم على التقييم الذاتي للنموذج لمدى الصلة. فعندما يمكن التأثير على هذا التقييم، تصبح "قواعد" النموذج قابلة للتفاوض.
ثلاث نقاط فشل
| مرحلة الفشل | ما حدث |
|---|---|
| اختطاف الهدف | تعامل الروبوت مع طلب طبخ غير ذي صلة كجزء من هدفه المتمثل في شرح الخدمة. |
| انحراف القدرات | قام بإنشاء كود Python قابل للتنفيذ على الرغم من أن دوره لم يتضمن إنشاء الكود. |
| تسريب المطالبة | طبع مطالبة النظام الدقيقة التي كان من المفترض أن تظل مخفية. |
تمثل كل مرحلة انهيارًا لطبقة دفاعية مختلفة تفترض العديد من عمليات النشر أن النموذج نفسه يفرضها.
الطبقات الدفاعية التي تعمل حقًا
إن نقل الضوابط (guardrails) من النموذج إلى كود حتمي (deterministic code) يعيد بناء حدود أمنية موثوقة.
- توجيه المهام – استخدم مصنفًا منفصلاً لربط الرسائل الواردة بقائمة ثابتة من النوايا المسموح بها. إذا وقع الطلب خارج تلك القائمة، فارفضه مباشرة. لن يتمكن النموذج أبدًا من الجدال حول مدى الصلة.
- الحد الأدنى من القدرات – جرد الروبوت من الأدوات التي لا يحتاجها. إذا كان لا يتطلب تنفيذ الكود أو الوصول الواسع إلى قاعدة البيانات، فقم بإزالة تلك القدرات.
- التفويض الحتمي – قم بإجراء فحص الأذونات في كود التطبيق، وليس في النموذج اللغوي. يمكن للنموذج اقتراح إجراء ما، ولكن الكود هو من يقرر تنفيذه.
- التحقق من المخرجات – افحص كل استجابة للنموذج بحثًا عن محتوى غير مسموح به — مثل مطالبات النظام أو البيانات الحساسة — قبل وصولها إلى المستخدم.
يمكن للمستخدم المقنع تجاوز الفلتر الذي يكتفي بالسؤال "هل هذا الطلب محظور؟". أما طبقة التوجيه التي تتحقق مقابل قائمة مغلقة فلا تترك مجالًا للتفاوض.
ما يجب مراقبته لاحقًا
يجب على الشركات التي تعتمد على الذكاء الاصطناعي الحواري (conversational AI) تدقيق عمليات النشر الخاصة بها بحثًا عن أنماط الفشل الثلاثة التي أوضحها اختبار وصفة لحم الضأن. وفي هذه الأثناء، تعامل مع أي مطالبة نظام على أنها معرفة عامة؛ ولا تعتمد عليها لمنع النموذج من كشف نفسه.
الخلاصة واضحة: إذا كان نموذجك الأمني يعتمد على فقرة من التعليمات المكتوبة بلغة طبيعية، فهو نموذج هش. عززه بكود يمكن تدقيقه، وإدارة إصداراته، وفرضه بغض النظر عما يقوله النموذج.