باتت النماذج اللغوية الكبيرة اليوم مدمجة في دعم العملاء، والبحث الداخلي، ومساعدات البرمجة، والوكلاء المستقلين. ويضيف كلٌّ من هذه الاستخدامات سطح هجوم لم يُصمَّم أمن التطبيقات التقليدي للتعامل معه. وأهم ما يجب إدراكه هو أن نموذج LLM لا يستطيع التمييز بشكل موثوق بين التعليمات الصادرة منك والتعليمات المخفية في المحتوى الذي يعالجه.
هذا هو جوهر حقن الأوامر (prompt injection)، الذي يحتل المرتبة الأولى في OWASP Top 10 for LLM Applications. ولأنه لا يوجد نموذج حالي محصّن ضده، فإن السؤال الصحيح ليس «كيف نمنع كل محاولة حقن؟» بل «ما الذي يمكن أن تحققه التعليمات المحقونة فعليًا في نظامنا؟»
1. حدّد ما يستطيع النموذج رؤيته وفعله
ابدأ بالحصر: ما مصادر البيانات التي يستطيع النموذج قراءتها؟ وما الأدوات التي يمكنه استدعاؤها، وبأي صلاحيات، ونيابةً عن مَن؟ ارسم تدفق البيانات، وحدّد كل نقطة يدخل منها محتوى غير موثوق (مدخلات المستخدمين، والمستندات المرفوعة، ورسائل البريد الإلكتروني، وصفحات الويب، ومخرجات الأدوات) إلى نافذة السياق. فكل واحدة منها نقطة دخول محتملة للحقن.
2. طبّق مبدأ أقل امتياز على النموذج، لا على المستخدمين فقط
تعامل مع نموذج LLM بوصفه مكوّنًا غير موثوق. وامنحه أضيق صلاحيات ممكنة، محصورة في استحقاقات المستخدم الحالي نفسه. فمساعد الدعم لا يحتاج إلى صلاحية الكتابة في نظام إدارة علاقات العملاء (CRM)، وميزة التلخيص لا تحتاج إلى الوصول إلى الإنترنت. وإذا كانت أداة ما قادرة على تغيير البيانات أو تحويل الأموال أو إرسال الرسائل، فهي تستحق التدقيق نفسه الذي تخضع له واجهة API عامة.
3. افرض التحكم في الوصول عند الاسترجاع
كثيرًا ما تُسرّب أنظمة التوليد المعزّز بالاسترجاع (RAG) البيانات لأن المستندات تُفهرس دون صلاحياتها الأصلية. لذا صفِّ نتائج الاسترجاع وفق صلاحيات وصول المستخدم صاحب الطلب قبل وصولها إلى النموذج. ولا تعتمد أبدًا على تعليمات الأمر النصي من قبيل «لا تُجب إلا من المستندات المسموح للمستخدم برؤيتها».
4. أبقِ العنصر البشري في الحلقة للإجراءات ذات العواقب
بالنسبة إلى الإجراءات ذات الأثر الفعلي، مثل إرسال رسائل البريد الإلكتروني أو تنفيذ الشيفرة أو تعديل السجلات أو إجراء المدفوعات، اشترط تأكيدًا صريحًا من المستخدم يوضّح بدقة ما سيحدث. وصمّم هذه التأكيدات بحيث لا يستطيع النص الذي يولّده النموذج تجاوزها.
5. قيّد المخرجات
تعامل مع مخرجات النموذج على أنها مدخلات غير موثوقة للنظام التالي. رمّزها قبل عرضها لمنع هجمات البرمجة النصية عبر المواقع (XSS)، وتحقّق من المخرجات المنظّمة وفق مخطط محدد، واحظر الصور أو الروابط التي تشير إلى نطاقات غير معروفة، فهي قناة شائعة لتسريب البيانات.
6. استخدم ضوابط حماية متعددة الطبقات، لكن لا تعتمد عليها وحدها
ترفع مصنّفات المدخلات والمخرجات، وتحصين أوامر النظام (system prompt)، ومرشّحات المحتوى كلفةَ الهجمات، وتلتقط قدرًا كبيرًا من المحاولات العشوائية. وهي مفيدة، لكنها احتمالية بطبيعتها. أما البنية (الصلاحيات والعزل والتأكيد) فهي ما يحدّ من الأثر عندما تفشل ضوابط الحماية.
7. سجّل وراقب واختبر باستمرار
سجّل الأوامر والسياق المسترجَع واستدعاءات الأدوات والاستجابات، مع ضوابط خصوصية مناسبة، لتتمكّن من التحقيق في الحوادث. وأضف حالات اختبار عدائية إلى حزمة التقييم لديك، وشغّلها مع كل تغيير في النموذج أو الأوامر أو الأدوات. فأساليب كسر القيود (jailbreak) الجديدة تظهر باستمرار، ويجب أن تتطوّر اختباراتك معها.
قائمة تحقق سريعة
- كل مُدخل غير موثوق إلى النموذج محدَّد وموثَّق.
- تعمل الأدوات بصلاحيات المستخدم، ولا تعمل أبدًا بحساب مشترك ذي صلاحيات عليا.
- يفرض الاسترجاع التحكم في الوصول على مستوى المستند.
- تتطلب الإجراءات ذات العواقب تأكيدًا بشريًا.
- تُرمَّز المخرجات ويُتحقَّق منها وتُزال منها الروابط غير الموثوقة.
- تُجرى التقييمات الأمنية تلقائيًا قبل كل إصدار.
إذا كنت تستعد لإطلاق ميزة قائمة على LLM أو وكيل ذكاء اصطناعي، فإن اختبار أمن الذكاء الاصطناعي المستقل هو أسرع طريقة لمعرفة مدى صمود هذه الضوابط أمام مهاجم مصمّم.