الاختبار العدائي يميز تقنية الهجوم وهدفه والنتيجة التنفيذية الفعلية، ويراجع حدود السلطة عند نقطة تنفيذ الأداة.
اختبار مقاومة تطبيقات LLM للهجمات عبر المطالبات: من الحقن النصي إلى حدود تنفيذ الوكيل
تختبر هذه المقالة التطبيقات التي تستخدم نماذج لغوية سواء كانت تقدم نصوصًا فقط أم تنفذ مهام عبر أدوات. الهدف ليس جمع أوامر هجومية متداولة، بل تصميم اختبار أمني يميّز قدرة المهاجم وسطح الدخول وحدود الثقة والسلوك المحظور والفعل المنفذ والدليل الذي يثبت النتيجة. إرشادات IMDA تجعل adversarial prompts أحد مجالات الاختبار المرتبط بسياق التطبيق، بينما تبني سيادة هنا طبقة تفصيلية للتحكم بالسلطة والأدلة وإدارة القرار، دون الادعاء بأنها جزء إلزامي من الوثيقة السنغافورية.
1. الهدف ونموذج التهديد
لا يُعرّف الاختبار العدائي بأنه تجربة عبارات «تجاهل التعليمات السابقة» فقط. يحدد فريق الاختبار من يسيطر على المدخل، وما مستوى موثوقيته، وما الذي يريد تغييره في النظام، وكيف يمكن أن ينتقل من نص غير موثوق إلى قرار أو فعل. يمكن للمهاجم كتابة صفحة ويب أو وثيقة أو بريد يقرأها RAG، أو يتلاعب بأداة خارجية تعيد نتائج فيها تعليمات مزيفة. وتختلف جودة الدفاع عند رفض النموذج نصًا ضارًا عن قدرة البنية على منع إرسال بيانات أو تغيير سجلات دون تفويض. يجب ألا تخلط الخطة بين attack technique وattack goal، لأن التقنية نفسها قد تهدف إلى تسرب البيانات أو تعديل قرار أو تعطيل سير العمل.
سؤال فحص للمؤسسة: من يستطيع التحكم بالمحتوى الذي يصل للنموذج؟
2. حدود السلطة لا مجرد حدود اللغة
التطبيق النصي الذي يقدم إجابة خاطئة يختلف عن وكيل يستطيع إنشاء طلب شراء أو تحديث قاعدة CRM أو إلغاء تذكرة. قبل red teaming يحتاج الفريق إلى خريطة صلاحيات واضحة: هوية المستخدم، وهوية الخدمة، ودور الأداة، والجهات المسموح الاتصال بها، وحدود المبلغ والتكرار، ومتطلبات التأكيد البشري. إذا كان الوكيل يستخدم token خدمة واسعًا لا يراعي صلاحيات المستخدم النهائي، فقد يصبح prompt injection سببًا مباشرًا لتجاوز السلطة. ولذلك يختبر فريق الأمان enforcement على جانب الخادم بجانب قدرة النموذج على رفض التعليمات المخالفة.
سؤال فحص للمؤسسة: هل تستطيع الأداة تجاوز صلاحية المستخدم؟
3. أسطح الحقن غير المباشر
الحقن المباشر يأتي في رسالة المستخدم؛ والحقن غير المباشر يأتي من مخرجات أدوات أو محتوى مسترجع غير موثوق. من الأسطح الحساسة صفحات الويب التي تلخصها الأدوات، مستندات الموردين، أوصاف تذاكر الدعم، نتائج البحث، مستودعات الشيفرة، وتعليقات الخلايا داخل جداول العمل. يكتب المهاجم تعليمات تبدو أحيانًا كرسالة إدارية أو سياسة جديدة أو جزء من markup. ينبغي فحص كيف يعلّم التطبيق المصدر ومستوى الثقة، وكيف يمنع ترقيته من «معلومة للقراءة» إلى «أمر لتنفيذ وظيفة». لا يكفي إسقاط عبارة محددة عند كل تجربة؛ يجب اختبار عائلات من الصياغات والتراكيب واللغات.
سؤال فحص للمؤسسة: هل تُعامل نتائج البحث كمحتوى أم كأوامر؟
4. تصميم حالات اختبار واقعية
تحتاج كل حالة ID ونقطة الدخول وسياق المستخدم والإصدار والهدف والسلوك الممنوع والمخرج المتوقع ودليل الحسم. مثال: وثيقة توريد تحتوي ملاحظة مشروعة عن تاريخ التسليم، ثم تعليمات تدعي أنها من مسؤول النظام وتطلب إرسال أسماء المتقدمين إلى بريد آخر. المثال لا يتطلب تنفيذ إرسال فعلي؛ يمكن إعداده داخل بيئة اختبار مع endpoint محاكٍ. نجاح الدفاع يقاس بأن النموذج يتعامل مع التعليمات الخفية كبيانات غير موثوقة، وأن الأداة لا تنفذ الإرسال، وأن سجل التنفيذ يوضح سبب المنع. أما استجابة تقول «لم أفعل» دون trace فقد لا تكفي إذا كان التنفيذ يحدث خلف الواجهة.
سؤال فحص للمؤسسة: هل يمكن إعادة تنفيذ حالة الاختبار مع الحفاظ على الأدلة؟
5. حملات متعددة الخطوات
تتجاوز بعض الهجمات دورة سؤال وجواب واحدة: يبدأ المهاجم بطلب بريء، ثم يغرس مرجعًا مخادعًا، ثم يقدم ملفًا يحتوي متطلبات إجرائية مزيفة، ثم يستغل نتائج سابقة ليطلب إجراءً يتجاوز التفويض. لذلك يجب تصميم محادثات متعددة الخطوات مع حالات تغيير السياق وتلخيص الذاكرة وخروج المستخدم ودخول آخر. سجل الهجوم يحتاج كل خطوة لا الطلب الأخير فقط. اختبارات الذاكرة مهمة خصوصًا عندما يستطيع المهاجم جعل النظام يحتفظ بجملة ذات صياغة سلطوية ثم يعيد استخدامها لاحقًا في جلسة مختلفة، أو عندما تختصر أداة التلخيص نصًا خبيثًا كأنه توجيه مشروع.
سؤال فحص للمؤسسة: هل يتغير الخطر بين جلسة واحدة وسلسلة محادثات؟
6. مصادر الحقيقة وأدوات التقييم
لا نعتبر وصول استجابة من النموذج إلى عبارة ممنوعة دليلًا وحده على حدوث أثر أمني. ينبغي تصنيف النتائج إلى محاولة مرصودة، تجاوز سلوكي نصي، استدعاء أداة غير مصرح، تنفيذ فعل فعلي، أو كشف بيانات موثوق. ويمكن للمقارنة الآلية أن تفرز الحالات، لكن تحتاج النتائج الحساسة إلى مراجعة trace وسجل permissions. إذا كان الفعل المحاكى يمثل تحويلًا ماليًا، نفحص هل قُبل الطلب من policy engine أم رفضه، لا هل وعد النموذج بالتحويل فقط. هذا يضمن ألا يتحول معدل نجاح المهاجم إلى رقم مبالغ فيه بسبب أخطاء في طريقة القياس.
سؤال فحص للمؤسسة: هل يوجد trace يثبت وقوع الإجراء؟
7. اختبار ضوابط التخفيف
لا توجد طبقة واحدة مناسبة لكل تهديد. قد تستخدم المؤسسة فصل تعليمات المستوى الأعلى عن محتوى المصدر، تقييد الأدوات حسب السياق، allowlists للوجهات، تحقق schema، تصنيف المدخلات، مراجعة بشرية، سجلات قابلة للتدقيق، وحواجز لمنع التصدير. ولكل ضابط اختبار وظيفي محدد يثبت أنه يعمل في الظروف المناسبة. من الخطأ اعتبار وجود سياسة مكتوبة دليلًا على فاعلية التنفيذ، أو اعتبار فشل بعض الهجمات في prompt-level detector كافيًا لحماية system-level actions. أفضل دفاع يحافظ على السلطة عند نقطة التنفيذ حتى إذا أقنع نص خبيث النموذج لغويًا.
سؤال فحص للمؤسسة: ما نقطة الإنفاذ الفعلية للضابط؟
8. اللغات والتمويه
تجارب الأمان الإنجليزية وحدها لا تغطي تطبيقًا عربيًا ثنائي اللغة. يجب إدخال اختبارات تتضمن تبديل اللغة داخل نفس المستند، استخدام لهجات وأساليب رسمية مزيفة، بيانات مركبة من العربية والإنجليزية، اتجاهات كتابة تؤثر في عرض الروابط، وترميزًا قد يخفي عبارات هجومية عن مرشح بسيط. ويجب التحقق من أن التطبيق لا يثق بنص لمجرد أنه محاط بتنسيق يبدو رسميًا أو جرى نقله من مصدر يحمل شعار جهة. يمكن أن تكون نقطة الضعف في parser أو طريقة اختيار أدوات البحث أو قواعد الاقتباس، لا في النموذج وحده.
سؤال فحص للمؤسسة: هل تغطي المجموعة اللغة العربية وأساليب التمويه؟
9. معالجة النتيجة الحرجة
إذا كشف اختبار في بيئة محكومة أن ملفًا خارجيًا أدى إلى استدعاء غير مخول لأداة، تحفظ سلسلة أدلة تحتوي المحتوى المحرض والنسخة والهوية والأداة والحمولة ونتيجة تنفيذ الضابط. يحدد مالك الحادث إن كان هناك بيانات خرجت فعلًا، ثم يعزل القدرة المتأثرة ويطبق إجراء إصلاح مع اختبار Regression. ينبغي تجنب نشر payload قابل لإعادة استخدامه مع تفاصيل تشغيلية حساسة على صفحة عامة؛ يمكن نشر النمط السببي والدروس والضوابط دون أسرار المؤسسة. ولا ينبغي إعلان النجاح بعد إصلاح الحالة نفسها فقط؛ يجب اختبار حالات مجاورة لكشف تراجع قدرة الحماية.
سؤال فحص للمؤسسة: هل عُزلت القدرة المصابة وأُعيد اختبارها؟
10. الحدود الإحصائية والتغطية
ليس red teaming اختبارًا لإثبات عدم وجود ثغرات. عدد الهجمات يهم، لكن نوعيتها وتمثيلها للسطوح والأدوار والأفعال أهم من العدد المجرد. ينبغي الإفصاح عن تغطية أسطح الدخول واللغات والأدوات والأهداف وفئات المستخدمين، مع عدد حالات النجاح والاختبارات المكررة والفشل في التقييم. لا تقارن نماذج مختلفة دون تثبيت شروط الاختبار والإصدارات. وإذا فشل الصفر من مجموعة صغيرة، فالاستنتاج الصحيح هو عدم ملاحظة اختراق ضمن الحالات المختبرة، لا تأكيد تحصين التطبيق بالكامل. تحدد عتبات الإطلاق المؤسسة وفق شدة الأثر وتوثق الاستثناءات وصلاحيات قبول الخطر.
سؤال فحص للمؤسسة: ما المخاطر التي لم تمثلها العينة؟
11. الاختبار ضمن CI/CD
عند أي تغيير prompt أو نموذج أو connector أو صلاحيات، يمكن تشغيل مجموعة regression ثابتة، ثم توسيعها دوريًا بمجموعات جديدة لا يعرفها فريق التطوير مسبقًا. ينبغي أن يمنع pipeline إصدار النسخ التي فشلت فيها اختبارات حرجة محددة، مع مسار استثناء رسمي إذا كان الاستثناء مسموحًا وقابلًا للمراجعة. لا تنقل مفاتيح الإنتاج إلى بيئة الاختبار ولا ترسل بيانات عملاء حقيقية إلى أدوات خارجية دون إذن. تربط حالات الهجوم بمعرفات تغييرات الإصدار، وتحتفظ بعينات وتحليلات كافية للتحقيق، وتطبق سياسات حذف واحتفاظ متوازنة مع السرية.
سؤال فحص للمؤسسة: ما الأحداث التي تعيد فتح قرار الأمان؟
12. حدود المصدر والنتيجة
يستخدم هذا المحتوى دليل IMDA باعتباره مصدرًا لمنهج اختبار السلامة والاعتمادية، مع تضمين adversarial prompts ضمن المخاطر الأساسية للتطبيقات اللغوية. لكنه لا يدعي أن قائمة الهجمات الموصوفة أو ضوابط السلطة أو سياسة CI/CD متطلبات تنظيمية حرفية من IMDA. هذه إضافات تحليلية تشغيلية من سيادة لحوكمة التنفيذ والأدلة. يجب أن تظل النتيجة قابلة للتدقيق: ما الاختبار؟ ما الضعف؟ ما الذي نُفذ بالفعل؟ ما الذي منعه الضابط؟ وما الإصدار الذي تم اعتماده؟
سؤال فحص للمؤسسة: هل مصدر كل ادعاء واضح؟