الاختبار الهجومي الجيد يثبت سلوك النظام وضوابطه وأثر الإخفاق ضمن نطاق مصرح، ولا يساوي مجرد اختبار رفض النموذج.
دليل OWASP للاختبار الهجومي للذكاء الاصطناعي التوليدي 2026: من هندسة الهجوم إلى إثبات المعالجة
نطاق المرجع ولماذا يستحق قراءة مختلفة
أصدر مشروع OWASP GenAI Security Project النسخة الأولى من دليل GenAI Red Teaming Manual في أكتوبر 2026. يقدم الدليل منهجية عملية للاختبار العدائي لأنظمة الذكاء الاصطناعي التوليدي، ولا يحصر الاختبار في إرسال مطالبات خادعة إلى نموذج لغوي. نقطة الانطلاق هي أن النظام المؤسسي يتكون من نموذج وتطبيق وبيانات وأدوات وخدمات وهويات وصلاحيات ومسارات تشغيل؛ ويمكن أن تنشأ الثغرة من التفاعل بين هذه المكونات حتى لو بدا النموذج منفرداً آمناً. يغطي المرجع التخطيط والاستطلاع ورسم الأسطح والاستغلال وقياس الأثر والاستمرارية وما بعد الاختراق والتقييم والمعالجة. هذه المقالة قراءة تحليلية مستقلة أعدتها سيادة AI انطلاقاً من بنية الدليل، وليست ترجمة رسمية له أو بديلاً عن نصه. المصدر الأصلي: https://genai.owasp.org/resource/genai-red-teaming-manual-version-1-0/ .
التحول العملي الذي ينبغي أن تفهمه المؤسسة هو الانتقال من سؤال «هل استطاع المختبر دفع النموذج إلى إجابة غير مرغوبة؟» إلى «هل استطاع سلوك عدائي عبور حد ثقة أو إساءة استخدام صلاحية أو تغيير قرار أو كشف أصل أو استنزاف مورد، وما الدليل القابل لإعادة التحقق على ذلك؟». لا تتساوى جميع نتائج الاختبار: مخرجات غير مناسبة في بيئة تجريبية ليست مساوية لتنفيذ تحويل مالي أو كشف بيانات عميل. لذلك يجب فصل السلوك الملحوظ عن مسار الاستغلال وعن الأثر المؤكد وعن احتمالات الضرر التي لم تُثبت.
1. تحديد الهدف والتفويض قبل أي اختبار
تبدأ المنهجية بالتخطيط وتحديد النطاق. يجب تعريف النظام ومكوناته ومالكه وصاحب قرار المخاطر والفرق المشاركة وحدود ما يسمح باختباره، بما في ذلك حسابات الاختبار، والمستأجرون التجريبيون، والبيانات المصطنعة، والخدمات الخارجية، والوقت المسموح، وحدود الاستهلاك والإيقاف. أن يملك المختبر حساب مستخدم لا يعني تلقائياً امتلاكه حق تجربة كل واجهة أو استهلاك كل خدمة أو نقل بيانات بين مستأجرين. الاتفاق على قواعد العمل ليس إجراءً شكلياً، بل شرط يجعل النتائج قابلة للاستخدام ويحمي العمليات والبيانات والأطراف الثالثة.
على المؤسسة أيضاً أن تحدد الغاية بدقة: هل نفحص استخداماً جديداً قبل النشر؟ هل نختبر تحديث نموذج أو تعديل Guardrail؟ هل نحاكي مهاجماً خارجياً؟ هل نتحقق من صلاحيات وكيل؟ أم نعيد اختبار إصلاح بعد حادث؟ يتغير تصميم الاختبار بتغير الغرض. من الخطأ تطبيق حزمة مطالبات ثابتة على جميع الأنظمة ثم وصف النتيجة بأنها تقييم أمني شامل. ناتج هذه المرحلة وثيقة نطاق حية تتضمن أصول الاختبار وفرضيات المخاطر وأدوار الموافقة ومسار التصعيد ومعايير إيقاف فورية عند ظهور أثر غير مقصود.
2. Black-Box وGray-Box وWhite-Box ليست درجات جودة
يميز الدليل بين ثلاثة أوضاع للوصول. في Black-Box لا يرى المختبر إلا السطوح المتاحة للمستخدم أو المهاجم المفترض، ويسجل ما ظهر منها؛ ولا يجوز الجزم بهوية النموذج أو معماريته من سلوك الواجهة وحده. في Gray-Box يحصل على معرفة جزئية مثل مخططات معمارية أو سجلات أو حسابات ذات أدوار محددة، ويجب توثيق ما قُدم تحديداً. في White-Box يمكن فحص الشيفرة والتكوين والتعليمات والسياسات وتدفقات البيانات والقياس التشغيلي المتاح. ولا يعني الوصول إلى التطبيق امتلاك أوزان نموذج مستضاف أو بيانات تدريبه.
اختيار الوضع ليس سباقاً إلى أكبر قدر من الصلاحيات. الاختبار الخارجي قد يكشف تجربة المهاجم الواقعية، والفحص الداخلي يساعد على إثبات سبب الإخفاق وتحويله إلى Regression Test. الأفضل أن توثق العلاقة بين مستوى الوصول والادعاء: إثبات أن استجابة واجهة كشفت محتوى معين لا يساوي إثبات أن الأوزان سُرقت؛ ورؤية مطالبة نظام داخل سجل مصرح به لا تعني أنها كانت متاحة لمستخدم عادي.
3. الاستطلاع والبصمة وسلسلة التوريد
المرحلة الثانية هي Reconnaissance & Fingerprinting. يراجع الفريق المواد العامة والواجهات والوثائق ومؤشرات التكاملات وسلسلة التوريد ضمن النطاق المصرح. قد تؤثر نسخة مكتبة أو نموذج مضمن أو طبقة وسيطة أو مزود بحث أو خدمة تخزين على حدود الثقة. الهدف إعداد فرضيات اختبار قابلة للتكذيب، لا كتابة سرد واثق حول مكونات لم يتم التحقق منها. يجب تمييز «لوحظ على الواجهة» عن «أكده مالك النظام» وعن «فرضية تحتاج تحققاً».
في المؤسسة التي تستخدم نموذجاً خارجياً عبر API، قد تكون نقطة التعرض في إدارة المفاتيح أو أدوات الوكيل أو سجلات المحادثة أو المكونات الوسيطة أو سياسة مشاركة المدخلات. لا يكفي فحص اسم المزود؛ ينبغي تسجيل المكونات التي تمر خلالها البيانات والضوابط التي تفرض العزل وكيف يتغير النظام عند تحديث المورد. هذه النتائج تنتقل إلى خريطة الأسطح بدلاً من البقاء قائمة أصول منفصلة لا ترتبط بسيناريو.
4. حدود الثقة وتدفقات البيانات قبل أسماء الهجمات
المرحلة الثالثة Surface Mapping تشمل تنظيم بيئة الاختبار وحدود الثقة وتدفقات البيانات ونمذجة التهديدات. يبدأ العمل برسم رحلة المعلومة من المصدر إلى النموذج وإلى القرار أو الأداة أو المستودع اللاحق. لكل انتقال نحدد جهة المصدر ومستوى الثقة وطريقة التحقق وإمكانية التحويل من محتوى إلى تعليمات. قد يدخل نص غير موثوق عبر رسالة مستخدم، أو مستند مسترجع، أو صفحة ويب، أو بريد إلكتروني، أو نتيجة أداة، ثم يتصرف التطبيق معه على أنه أمر يمتلك سلطة أعلى.
الفرق الحاسم هو أن المعلومة المقتبسة ليست تفويضاً. لذلك ينبغي أن تُختبر حدود الثقة على مستوى النظام: مَن يسمح للأداة بالعمل؟ هل تتحقق طبقة التنفيذ من صلاحيات المستفيد؟ هل يحتفظ الوكيل بسياق غير موثوق بين الطلبات؟ هل تستطيع البيانات المسترجعة التأثير في اختيار وجهة إخراج حساسة؟ إذا كان الاعتماد على تعليمات مكتوبة للنموذج وحدها، فإن الضابط لا يساوي بالضرورة تحكماً تقنياً مستقلاً.
5. المجالات التقنية للاختبار
المرحلة الرابعة Exploitation & Impact تنظم اختبار فئات متعددة: ثغرات النموذج مباشرة، والثغرات في المسارات التي يصل بها المحتوى إلى النظام، والهجمات متعددة الوسائط وغير النصية، ومتجهات الأنظمة الوكيلة، واستنزاف الموارد، والتحايل على الحواجز ومصنفات السلامة. لا تعني هذه المجالات أن كل نموذج معرض لكل هجوم أو أن نجاح صياغة معينة يعكس قابلية اختراق مؤكدة. تبنى كل تجربة على أصل محدد وحد ثقة واضح ونتيجة متوقعة وضابط يفترض أن يمنع السلوك.
في أنظمة RAG يجب فصل اختبار صحة الاسترجاع عن اختبار نفاذ التعليمات من محتوى المستند، وعن اختبار صلاحيات الوصول إلى المستند الأصلي. وفي الأنظمة متعددة الوسائط ينبغي أن تؤخذ طريقة إدخال الصور والملفات والصوت بعين الاعتبار، لا أن يُعاد استخدام سيناريو نصي ثم يسمى اختباراً متعدد الوسائط. أما الوكلاء فيضيفون طبقة الفعل: اختيار الأدوات، تحديد الوسائط المرسلة إليها، التعامل مع حالة التنفيذ، وتفسير نتائجها. ينبغي تنفيذ التجارب على بيئات وبيانات مصرّح بها، مع منع النتائج الحقيقية الضارة أو الوصول غير المقصود إلى حسابات إنتاجية.
6. الوكلاء المستقلون يغيرون معنى نجاح الهجوم
يمكن للمساعد النصي أن يسبب ضرراً بمخرجات مضللة، لكن الوكيل الذي يستدعي أداة يخلق سلسلة سلطة جديدة: طلب المستخدم، تفويض النظام، اختيار الوكيل، صلاحية الأداة، قرار النظام الخلفي، وسجل التنفيذ. هنا لا يكفي أن يرفض الوكيل في محادثة محاكاة. يُختبر ما إذا كان نظام الصلاحيات الخلفي سيمنع فعلاً الإجراء غير المصرح حتى لو اختارت طبقة النموذج استدعاء الأداة.
مثال دفاعي: وكيل يساعد موظف مشتريات على قراءة عروض الموردين، وله صلاحية الاطلاع على سجل محدود وليس صلاحية اعتماد مورد أو تغيير حساب دفع. قد تظهر مادة غير موثوقة تطلب منه تعديل حقول حساسة. الاختبار الصحيح يتحقق من أن المنع يحدث في طبقة الهوية والتفويض والمعاملة، وأن الحدث يظهر في السجلات، وأن طلب الموافقة الحقيقي لا يمكن تجاوزه بصياغة لغوية. ناتج الاختبار قد يكون «لم ينفذ الإجراء» لكنه لا يثبت وحده أن الضابط قوي؛ يجب معرفة سبب المنع وأنه ثابت أمام مسارات بديلة مصرح بها.
7. الاستمرارية والتصعيد وتسريب البيانات
المرحلة الخامسة تركز على Data Exfiltration وPrivilege Escalation وPersistence. الغرض هنا ليس إثبات أن النظام أجاب بنص غير مرغوب، بل التحقق مما إذا كان الخلل يخلق قدرة مستمرة أو وصولاً غير مصرح به أو خروج بيانات خارج الحدود المسموحة. يجب استخدام بيانات اختبار مصطنعة ووجهات إخراج خاضعة لملكية فريق الاختبار، وتحديد شروط التوقف قبل المحاولة. أي مؤشر على بيانات فعلية أو مستخدمين حقيقيين يستوجب تصعيداً وتقييماً وفق قواعد العمل المتفق عليها.
تتطلب الاستمرارية عناية خاصة في وكلاء يحتفظون بالذاكرة أو حالة سير العمل أو التفضيلات أو مخرجات الأدوات. وجود محتوى خبيث في سجل لا يثبت أن الوكيل سيستخدمه لاحقاً؛ يجب قياس ما إذا ظل مؤثراً بعد إغلاق الجلسة أو تغيير المهمة أو إعادة تهيئة الحالة، وما مستوى الوصول الذي بقي متاحاً. وتوثق النتيجة بصفتها ملاحظة محددة في بيئة وزمن وإصدار معلومين، لا حكماً أبدياً على أمن المنتج.
8. ما بعد الاختراق وقياس نطاق الضرر
في المرحلة السادسة Post-Exploitation يحلل الفريق القدرات التي أصبحت ممكنة فعلياً ونطاق الضرر واستقرار الاختراق والأثر على السلامة والأمن والأعمال. لا يجوز خلط الوصول إلى بيانات اختبار مع إمكانية الوصول إلى كل بيانات المؤسسة دون دليل. ويجب التفريق بين ملاحظة واحدة وإعادة إنتاج مستقرة وبين أثر متسلسل يحتاج شروطاً إضافية. يمكن أن يكون الخطر مرتفعاً رغم صعوبة التكرار إذا كان الأصل شديد الحساسية، لكن ذلك ينبغي تفسيره لا تغليفه برقم دقيق مضلل.
يمكن بناء سجل أثر يتضمن الأصل، والجهة المتأثرة، وشروط النجاح، ووجود ضوابط تعويضية، وقدرة الكشف، والأثر التنظيمي المحتمل، وحدود الأدلة، والمسؤول عن قرار الاحتواء. عند اقتراح إجراء فوري مثل تعطيل أداة أو تغيير إذن يجب أن يقيّم فريق التشغيل أثر القرار على الخدمات؛ لا ينبغي أن يتحول اختبار دفاعي إلى انقطاع غير مخطط. تبقى مخاطر ما بعد المعالجة «متبقية» حتى تثبت إعادة الاختبار أنها خفضت احتمال الاستغلال أو أثره وفق معيار محدد مسبقاً.
9. معيار النجاح والفشل ليس انطباع المختبر
المرحلة السابعة Evaluation & Reporting تشمل تصميم الاختبار وTest Oracles ومعايير النجاح والفشل وقابلية إعادة الإنتاج والتغطية والمقاييس. ينبغي أن يحمل كل اختبار معرفاً وهدفاً ونطاقاً ونوع الوصول والإصدار والبيئة والمدخلات المصرح بها والنتيجة المتوقعة والنتيجة الفعلية والأدلة. مثال: «حُظر استدعاء أداة غير مصرح به ولم تتغير حالة النظام الخلفي» أفضل بكثير من كتابة «النموذج آمن». والأفضل أن يدعم الحكم سجل تنفيذ من المصدر الموثوق لا محادثة مرئية فقط.
يجب أيضاً الفصل بين مقاييس الأداء ومقاييس الأمن. نسبة رفض الطلبات لا تقيس بمفردها سلامة التفويض، ونسبة النجاح في مجموعة مطالبات لا تثبت التغطية الشاملة، وقد يؤدي رفع الرفض إلى تعطيل طلبات مشروعة. أدرج إلى جانب نتائج الاختبار تغطية الأسطح والأدوار وحدود الثقة، وعدد النتائج المعاد إنتاجها، وفعالية الكشف، وزمن الاحتواء، وحالة اختبارات الانحدار، ودرجة الثقة بالأدلة. لا تقارن رقمين بين نموذجين إذا اختلفت شروط البيئة أو السيناريوهات أو معيار الحكم دون الإفصاح عن ذلك.
10. التقرير للمدير التنفيذي مختلف عن دفتر الاختبار
يعرض التقرير التقني المسارات والشروط والآثار والأدلة والضوابط التي فشلت وكيفية إعادة التحقق في نطاق مصرح به. أما التقرير التنفيذي فيجيب عن الأسئلة التي تغير القرار: ما الأنظمة المعرضة؟ ما العمليات الحرجة؟ هل توجد صلاحيات زائدة؟ ما البديل المؤقت؟ من يملك قرار قبول المخاطر؟ وما تاريخ التحقق التالي؟ ويجب أن تفصل لوحة العرض بين «تم اكتشافه» و«تم احتواؤه» و«تمت معالجته» و«ثبت نجاح إعادة الاختبار».
لا يحق للفريق الادعاء بأن المؤسسة أصبحت متوافقة تنظيمياً لمجرد تنفيذ Red Teaming. قد تكون الاختبارات دليلاً داعماً ضمن برنامج امتثال أوسع، لكن انطباق المتطلبات يعتمد على الجهة والقطاع والتشريع والنظام الخاضع للاختبار. كذلك لا يعني نجاح التقييم أن المخاطر غير المختبرة غير موجودة. يذكر التقرير صراحة نطاق التغطية والقيود والمتغيرات غير المختبرة وفترة صلاحية النتيجة.
11. المعالجة والتكامل بين الفرق
المرحلة الثامنة Post-Engagement & Remediation تنقل النتائج إلى المسؤولين عن الضوابط والمراقبة والاستجابة. على Red Team أن يصف شروط تحقق الضعف بدقة، وعلى Blue Team أن يحدد ما كان قابلاً للرصد ولماذا لم يُكشف إن حدث ذلك، وعلى فرق الهندسة أن تبني معالجة يمكن اختبارها آلياً أو يدوياً. لا يكفي إغلاق تذكرة لأن المطور أضاف تعليمات جديدة للنموذج؛ يجب اختبار أن العبور غير المصرح لحد الثقة بات ممنوعاً في الطبقة المناسبة، وأن الوظيفة المشروعة لم تتضرر.
التحسين المستمر يربط النتائج بخط أساس قبل المعالجة، واختبار بعد التغيير، واختبارات انحدار عند تحديث النموذج أو الأدوات أو السياسات. يفضل الاحتفاظ بالمعرفات والإصدارات وحالات الأدلة دون تخزين أسرار أو بيانات حساسة في تقارير عامة. إذا أدى تغيير مزود خارجي إلى تعديل السلوك، لا تنتقل ثقة الاختبار السابق تلقائياً إلى الإصدار الجديد؛ يجب تحديد ما تغير وما يحتاج إعادة تحقق.
12. موضع الاختبار الهجومي داخل حوكمة المؤسسة
يمكن تحويل كل نتيجة إلى سلسلة مساءلة: أصل مؤسسي → حد ثقة → سيناريو اختبار → نتيجة مثبتة → أثر → مالك خطر → ضابط → إجراء → دليل إعادة اختبار → قرار قبول أو معالجة. هذا الربط تحليل تضيفه سيادة AI لخدمة حوكمة المؤسسات، وليس اسماً لمنهج جديد نسبناه إلى OWASP. ويصبح أكثر أهمية عندما يربط التطبيق نظاماً مستقلاً بواجهات تنفيذ أو بيانات عابرة للحدود أو مورّدين لا تتحكم المؤسسة بإصداراتهم.
المؤسسة التي تريد إثبات سيادتها على الذكاء الاصطناعي لا يكفي أن تملك وثيقة تصنف المخاطر. عليها أن تعرف ما الذي يستطيع النظام فعله فعلياً، ولصالح من، وبأي صلاحيات، وما الذي يمكن للخصم التأثير فيه، ومن يوقف السلوك، وكيف يراجع القرار. الاختبار الهجومي يقدم جزءاً من أدلة هذه المعرفة، ولكنه لا يغني عن إدارة الموردين أو الهوية أو حماية البيانات أو التدقيق أو الرقابة البشرية. قيمته تظهر عندما تنتقل النتيجة من تقرير تقني إلى قرار محدد قابل للمراجعة.
13. أخطاء منهجية يجب أن يتجنبها برنامج الاختبارات
الخطأ الأول اختيار مجموعة مطالبات مشهورة ثم تسمية تشغيلها «اختباراً شاملاً». الخطأ الثاني اعتبار كل رفض من النموذج دليلاً على سلامة التطبيق، مع تجاهل طبقة تنفيذ الأدوات. الثالث تكرار الاختبار دون تثبيت نسخة النموذج أو حالة الاسترجاع أو الأدوات، ثم مقارنة نتائج لا يمكن إعادة إنتاجها. الرابع تسجيل أثر افتراضي كأنه أثر محقق. الخامس تصنيف خطورة موحدة لا تراعي أصل المؤسسة أو التفويض أو إمكانية كشف الخلل. السادس فصل التقرير الأمني عن مالك الخطر وعن فريق المعالجة. السابع اعتبار تأمين تعليمات النظام بديلاً عن التحكم الخلفي بالصلاحيات. والثامن إخفاء محدودية التغطية عن الإدارة تحت عنوان «اجتاز الاختبار».
المعالجة العملية لهذه الأخطاء ليست زيادة عدد الحالات عشوائياً، بل تحسين التتبع. اربط كل اختبار بفرضية واضحة وبمسار بيانات وبضابط محدد. احتفظ بحالة فشل ونجاح موثقة وبسجل للأسباب التي تجعل الحكم غير حاسم. استخدم بيئة تسمح بالقياس من دون تعريض بيانات حقيقية للخطر. لا تخلط بين التصنيف التعليمي للثغرة وبين إثبات أثرها في النظام المحدد. ولدى تغيير النظام، قرر صراحة ما الذي يجب إعادة اختباره بناء على التغيير، بدلاً من إعادة كل شيء أو تجاهل كل شيء.
14. نموذج قرار قابل للتنفيذ
لإطلاق مساعد مؤسسي متصل بمخزن مستندات، يبدأ الفريق بتحديد الفئات التي يحق لكل مستخدم رؤيتها، والأدوات التي يمكن استدعاؤها، وبيئة الاختبار وحساباته. يرسم حدود الثقة بين المستخدم ومصدر المستندات وطبقة الاسترجاع والنموذج والتطبيق ونظام السجلات. ثم يحدد حالات تقييم: هل يُحترم عزل الوثائق؟ هل تفشل محاولة استخدام تعليمات داخل مستند غير موثوق؟ هل تمنع الطبقة الخلفية استدعاء أداة محظورة؟ هل يبقى أثر الاختبار بعد جلسة جديدة؟ هل توجد إشارات مراقبة قابلة للتدقيق؟
عند جمع النتائج يصف الفريق حالة كل اختبار: PASS مدعوم بالدليل، FAIL مدعوم بالدليل، أو INCONCLUSIVE لنقص الدليل أو خلل البيئة. لا يُعوض فشل حرج بعشرات حالات نجاح قليلة الأهمية. يقرر مالك النظام وفريق المخاطر ما الذي يجب إصلاحه قبل الإطلاق وما الذي يمكن قبوله مؤقتاً وفق صلاحيات واضحة، ويُسجل تاريخ إعادة الاختبار وشروطه. هذه الطريقة تجعل الدليل مرجعاً لتأسيس عملية Assurance مستمرة بدلاً من مناسبة اختبار واحدة.
المصدر وحدود الاستخدام
المصدر الأساسي: OWASP GenAI Security Project, GenAI Red Teaming Manual, Version 1.0, October 2026، خصوصاً مقدمة الدليل والصفحات 7–12 ومنهجية المراحل الثماني في الصفحات 14–129. هذا النص تحليل وتوسعة تحريرية مستقلة باللغة العربية؛ لا يمثل نص OWASP الرسمي ولا يزعم اعتماداً أو تأييداً منها. الترخيص المعلن في الأصل CC BY-SA 4.0، ويجب مراعاة شروط النسب والمشاركة بالمثل عند إعادة إنتاج أو تعديل المادة المرخصة. الأمثلة الواردة افتراضية ودفاعية ويجب تنفيذ أي اختبار على أنظمة يملك الفريق تصريحاً صريحاً باختبارها.