يُعدّ حقن التعليمات البرمجية الفورية الخطر الأكبر الذي يهدد تطبيقات المؤسسات التي تستخدم نماذج اللغة، وفقًا لمنظمة OWASP، التي حافظت على صدارتها في قائمة أخطر عشرة مخاطر للعام الثاني على التوالي. ولا يُعدّ هذا سيناريو نظريًا أو مشكلة معملية، بل هو نتيجة مباشرة لكيفية عمل هذه الأنظمة.
لا يُميّز نموذج اللغة بين التعليمات التي يُقدّمها مُطوّره والنص الذي يُعالجه. فكل شيء يصل على شكل كلمات. إذا احتوى مستند يقرأه النظام على شيءٍ ما على شكل تعليمات، فمن المُحتمل أن يُعامله النظام على هذا الأساس.
النسخة المعروفة - وهي قيام مستخدم بكتابة "تجاهل تعليماتك" - هي الأقل إثارة للقلق، لأن المهاجم يجب أن يكون موجودًا وتكون صلاحياته هي صلاحيات أي مستخدم آخر.
النسخة التي تهم في بيئة الأعمال هي الحقن غير المباشرالنص الخبيث ليس من كتابة المستخدم؛ بل يأتي ضمن المحتوى الذي يعالجه النظام كجزء من عمله الطبيعي.
المتجهات المعتادة:
في كل الأحوال، تكون العملية واحدة: شخص خارجي يكتب نصًا يقرأه نظامك، وقد يؤثر هذا النص على وظائفه. وفي كل الأحوال، يكون الضرر المحتمل مساويًا تمامًا لنطاق الصلاحيات التي منحتها له.
الحل البديهي هو تصفية التعليمات المشبوهة عند المدخلات. لكن هذا لا ينجح بشكل موثوق، وذلك لثلاثة أسباب:
للغة أشكال لا حصر لها. يمكن إعادة صياغة أي قائمة بالأنماط المحظورة. ويمكن أن تكون التعليمات بلغة أخرى، أو معاد صياغتها، أو مقسمة إلى عدة جمل.
قد يكون مخفياً. نص فارغ على صفحة فارغة في ملف PDF، بيانات وصفية، محتوى لا يراه المستخدم ولكن النظام يقرأه.
لا يمكن للمرشح معرفة النية. قد تحتوي رسالة بريد إلكتروني مشروعة على عبارة "يرجى إعادة توجيه هذا إلى قسم المحاسبة". لا يملك النظام طريقة فعالة لتحديد ما إذا كانت هذه تعليمات لنفسه أم معلومات لشخص ما.
الاستنتاج العملي غير مريح ولكنه في الوقت نفسه يوضح الأمور: علينا أن نفترض أن عملية الحقن ستحدث، وأن نصمم بحيث لا يكون لها أي تأثير..
مبدأ | ماذا يتضمن ذلك؟ | ما يمنعه |
|---|---|---|
الحد الأدنى للتصريح | لا يصل النظام إلا إلى ما تتطلبه مهمته المحددة | أن التعليمات المُدخلة تصل إلى البيانات الخارجية |
فصل القنوات | لا يتم التعامل مع المحتوى الخارجي أبدًا كتعليمات للنظام | دع دالة كثافة الاحتمال تعيد تعريف السلوك |
قائمة الأسهم المسموح بها | العمليات المدرجة صراحةً فقط هي المسموح بها | أن يحدث شيء غير متوقع |
التحقق البشري في الأمور التي لا رجعة فيها | المدفوعات، والاتصالات الخارجية، وتغييرات الإنتاج | أن الضرر يتجسد دون مراجعة |
التسجيل الكامل | يسجل ما تم إدخاله وما تم تنفيذه. | أن الحادث لا يمكن إصلاحه |
هذه القرارات الخمسة هي قرارات معمارية، وليست مجرد إعدادات للأدوات. وكلها لا تكلف الكثير إذا تم اتخاذها قبل البناء، ولهذا السبب ينتمي هذا المقال إلى نقاش التصميم أكثر من نقاش الأمن.
أضافت منظمة OWASP خطرين مرتبطين بهذا الجدول يجب ذكرهما: LLM02، الإفصاح عن المعلومات الحساسة, ، و LLM06، الطاقة الفائضة. تُقدّم النماذج الثلاثة نفس المشكلة من زوايا مختلفة: ما الذي يستطيع النظام قراءته، وما الذي يستطيع فعله، ومن يستطيع التأثير عليه. وقد طوّرنا هذا في إن منح الصلاحيات لوكيل هو قرار محفوف بالمخاطر
تخيل مساعدًا يقوم بمعالجة الفواتير الواردة في البريد الإلكتروني الإداري: فهو يستخرج المبلغ والمورد ورقم الحساب، ويجهز عملية الدفع.
يرسل مورد محتال فاتورة تتضمن تعليمات صغيرة في أسفلها إلى النظام لاستخدام رقم حساب مختلف. إذا كان لدى الموظف صلاحية إعداد المدفوعات ولم يتحقق أحد من رقم الحساب مقابل سجل المورد، يتم تنفيذ عملية الاحتيال بكفاءة نظام آلي.
لاحظ أنه في هذا المثال، لم يفشل النموذج: فقد نفّذ ما طلبه منه النص تمامًا. يكمن الخلل في التصميم، الذي سمح لنص خارجي بتحديد معلومة بالغة الأهمية دون التحقق منها من المصدر الأصلي.
ومن هنا تأتي القاعدة التي نكررها في كل مشروع: يقوم النموذج بصياغة وتفسير المعلومات؛ ويقرر النظام الحقائق.. يتم التحقق من المبالغ والحسابات والحالات والأذونات مقابل النظام المصدر؛ ولا يتم قبولها مطلقًا من المحتوى المعالج.
عندما يقدم شخص ما حلاً مدعوماً بالذكاء الاصطناعي لقراءة المحتوى الخارجي، فإن ثلاثة أسئلة تميز بين الحل الجاد والحل الارتجالي:
إنّ مزوّد الخدمة الذي يردّ قائلاً: "نموذجنا لا يقع في هذا الفخ" لم يُدرك حجم المخاطر. فالاحتواء لا يعتمد على جودة النموذج، بل على النطاق الممنوح له.
يتمثل هذا في التلاعب بسلوك نموذج اللغة من خلال نص يعالجه النموذج كما لو كان تعليمات. وقد صنّفت منظمة OWASP هذا الأمر كأخطر خطر ضمن قائمة المخاطر العشرة الأولى لتطبيقات ماجستير القانون بحلول عام 2025، لأن النموذج لا يُميّز هيكليًا بين تعليمات المطور والمحتوى الذي يُحلّله.
هذا هو الشكل ذو الصلة في بيئات العمل: التعليمات لا يكتبها المستخدم، ولكنها تأتي ضمن المحتوى الذي يعالجه النظام بشكل روتيني - بريد إلكتروني من المورد، أو ملف PDF، أو صفحة ويب، أو تذكرة دعم، أو حقل نموذج.
ليس ذلك موثوقًا. فاللغة تسمح بإعادة صياغة لا حصر لها، ويمكن إخفاء التعليمات في نصوص أو بيانات وصفية غير مرئية، ولا يمكن لأي مرشح تحديد النية. والنهج الصحيح هو افتراض حدوث ذلك والحد من الضرر المحتمل من خلال الأذونات والضوابط.
مع خمسة مبادئ تصميم: الحد الأدنى من الصلاحيات لكل مهمة، والفصل بين المحتوى الخارجي وتعليمات النظام، وقائمة بيضاء بالإجراءات المسموح بها، والتحقق البشري الإلزامي في العمليات غير القابلة للعكس، والتسجيل الكامل للمدخلات والإجراءات المنفذة.
نعم، إذا كان النظام يعالجها ويتمتع بصلاحيات واسعة. المثال النموذجي هو فاتورة تتضمن تعليمات لتغيير رقم حساب الدفع. المشكلة ليست في النموذج نفسه، بل في التصميم الذي يسمح لنص خارجي بتحديد البيانات المهمة دون التحقق منها مقابل المصدر.
ماذا يحدث إذا تضمن المحتوى المُعالَج تعليماتٍ مُوجَّهةً إلى النظام؟ ما الذي يُمكن للنظام فعله في أسوأ السيناريوهات؟ وهل يُمكن إعادة بناء حادثةٍ وقعت قبل شهر؟ إنّ الإجابة التي تنفي إمكانية وقوع هجوم تُشير إلى عدم إدراك المخاطر.
هل يقرأ نظام الذكاء الاصطناعي الخاص بك المحتوى المكتوب من قبل أطراف ثالثة؟ نقوم بمراجعة النطاق والأذونات وفصل القنوات وإمكانية التتبع، ونخبرك ما هو أسوأ سيناريو ممكن مع التصميم الحالي. اطلب مراجعة →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
