لا يساوي إغلاق التذكرة إغلاق الخطر؛ يحتاج الأمر إلى ضابط صحيح وإعادة اختبار وبيان للمتبقي.
قالب خطة معالجة نتائج GenAI وإعادة الاختبار وإثبات إغلاق المخاطر
وظيفة خطة المعالجة
هذا قالب إدارة إصلاح وإعادة اختبار لنتائج فحص GenAI، يربط نتيجة الفريق الأحمر بمعالجة تملكها فرق الهندسة أو الهوية أو البيانات ثم بمراجعة مستقلّة. تستند بنيته إلى Phase 8 Post-Engagement & Remediation في OWASP GenAI Red Teaming Manual v1.0 وإلى منهج التقييم في Phase 7، لكنه ليس استمارة رسمية تصدرها OWASP ولا شهادة إغلاق خطر. لا يكفي نقل تذكرة إلى Done إذا بقي السبب الجذري أو لم تُختبر الوظيفة المشروعة بعد الإصلاح. يُستخدم القالب داخل عمليات مأذونة ويحتفظ بالنتيجة القديمة بوصفها جزءاً من الأثر التاريخي، مع فصل ما حدث فعلاً عما كان مجرد احتمال أو فرضية في التقرير.
تسجيل الحالة وإصدارها
يبدأ سجل المعالجة بمعرف النتيجة الأصلية ورابط أدلتها وتاريخها ونوع الوصول الذي استخدمه المختبر وإصدار التطبيق والمكوّن المتأثر، ثم يوثق تاريخ استلام الفريق المسؤول. لا ينبغي أن ينشئ الفريق رقم نتيجة جديداً كلما تغير عنوان التذكرة، لأن ذلك قد يفصل سبب الضعف عن إصلاحه ويجعل مقارنة النتائج صعبة. يمكن أن يكون للمشكلة أكثر من إجراء، مثل تصحيح تفويض API وتحسين مراقبة الاستدعاءات، ولكل إجراء مالك ومعيار. عند تعذر تأكيد السبب الجذري من الأدلة يجب أن تبقى الحالة معلقة للتحقيق، لا أن تُغلق بناء على افتراض أو انطباع.
تحديد السبب بدل العرض
قد يظهر الخلل في رد النموذج لكنه ينشأ من استرجاع ملف خارج الدور أو أداة تعمل بمفتاح خدمة واسع أو سياق يخلط محتوى غير موثوق بتعليمات التشغيل. يجب أن يتضمن القالب مكان ظهور الأثر والطبقة التي ثبت فشل ضابطها وما إذا كانت هناك أسباب أخرى تحتاج فحصاً. إذا رفض النظام الخلفي المعاملة لكن النموذج اقترحها، فهناك فرق بين تحسين سلوك الوكيل وبين إصلاح سلطة تنفيذ لم تفشل في هذه الحالة. لا ينبغي إضافة تعليمات لغوية أقوى باعتبارها حلاً مضموناً عندما يكون الإخفاق متعلقاً بتفويض ملف أو أداة خلفية. يحتاج العلاج إلى دليل يتصل بموضع السلطة الفعلية.
ملكية الضوابط والقرارات
يُسند لكل إجراء فريق تنفيذ مثل هندسة خدمة البحث أو إدارة الهوية أو فريق أدوات الوكيل أو المراقبة، مع جهة تراجع النتيجة وصاحب صلاحية قبول خطر متبقٍ. قد يكون مالك المنتج مسؤولاً عن جدول الإطلاق لكنه لا يستطيع وحده قبول جميع مخاطر بيانات العملاء أو تعطيل ضوابط مؤسسية. لذلك يوضح السجل مَن يملك قرار تعليق الأداة ومَن يقيم أثر ذلك على الخدمة ومَن يستطيع إعادة تفعيلها بعد التحقق. إذا تعلق الإصلاح بمورد خارجي، يذكر مسار المتابعة التعاقدية والمهلة والضابط المحلي الممكن دون إعطاء الفريق حق اختبار بنية المورد خارج موافقة منفصلة.
خطة احتواء مؤقتة
إذا كان استمرار أداة عالية السلطة قد يسبب أثراً غير مقبول، يمكن أن تشمل خطة الاحتواء سحب صلاحية كتابة أو إيقاف تكامل محدد أو حصره بحسابات اختبار أو إضافة موافقة موثوقة على مستوى المعاملة. ينبغي أن يعرف صاحب القرار أثر الاحتواء على الوظائف المشروعة ومتى يُراجع الإجراء وكيف تُراقب أي محاولة استخدام خلال فترة التعليق. لا يعني الاحتواء أن السبب الجذري عولج، كما لا ينبغي توسيع التوقف إلى كل النظام إن كان بالإمكان عزل المكوّن الحرج بصورة آمنة. يحدد الجدول تاريخ تطبيق الاحتواء ومالكه ومصدر إثباته، وما الحالات التي تستوجب التصعيد إذا لم يعمل.
معالجة عزل بيانات RAG
عند إثبات استرجاع مستند خارج الدور يمكن أن تتعلق المعالجة بترشيح الصلاحيات في خدمة البحث أو تخزين مؤقت أو رابط ملف أو فهرس لم يعكس تغير أذونات المصدر. يحدد الفريق المسار الذي أعاد البيانات فعلياً وموضع التحقق الصحيح ويضيف سياسة مستقلة عن تعليمات النموذج. لا يكفي إخفاء المستند في واجهة المحادثة إذا كانت خدمة البحث تسترجعه أصلاً، ولا يكفي حذف ملف الاختبار إذا كان المستأجر التالي سيواجه المشكلة نفسها مع ملف آخر. يجب أن يتضمن معيار إعادة الفحص عدم رجوع مستندات محظورة من المصدر وبقاء المستندات المسموحة قابلة للعرض، مع حسابين ومراجع اصطناعية معروفة.
معالجة تفويض الوكيل
إذا ثبت أن أداة تسمح بتنفيذ فعل خارج دور المستفيد، يجب أن تفرض طبقة API التحقق من هوية المستخدم الأصلية ونوع العملية والأصل وشروط الموافقة، وألا تعتمد على الامتياز الواسع لرمز خدمة أو قرار النموذج وحده. يمكن أن تحتاج هندسة الوكيل إلى تقليل قائمة الأدوات المتاحة أو فصل نتائج مصدر غير موثوق عن توجيهات التشغيل، لكن الضابط التنفيذي ينبغي أن يعمل حتى عندما يقترح النموذج طلباً غير مناسب. يحدد اختبار الانحدار حساب قراءة لا يستطيع تنفيذ تعديل محظور وحساباً مخولاً يستطيع القيام بوظيفته المشروعة، مع مصدر سجل يبين سبب السماح والرفض.
معالجة الذاكرة والاستمرارية
قد يحفظ الوكيل محتوى مسترجعاً أو نتيجة أداة في ذاكرة يستخدمها لاحقاً، وتحتاج المعالجة إلى ضبط المصدر وحق الكتابة والاسترجاع والعمر وإبطال العناصر غير المناسبة. لا يكون حذف سجل واحد علاجاً كاملاً إذا كان يمكن لمصدر مشابه الدخول إلى ذاكرة مشتركة دون حدود. يكتب القالب هل الملاحظة تتعلق ببقاء محتوى أو بوصوله إلى حساب آخر أو بتأثيره في قرار أداة، لأن كل حالة تحتاج نوع دليل مختلف. وينبغي أن تُجرى التجارب اللاحقة بحسابات اصطناعية وجلسات معروفة لتحديد مصدر التأثير، لا أن تُستخدم بيانات شخصية أو محادثات موظفين حقيقية لإثبات الاستمرار.
معالجة مراقبة الأحداث
يمكن أن تمنع الخدمة الخلفية عملية غير مصرح بها لكن لا تسجل محاولة الاستدعاء بطريقة يستطيع الفريق الأزرق فهمها. يحتاج القالب إلى مهمة مستقلة لإضافة حدث موثوق بمعرف الطلب والدور ونوع العملية وحالة المنع، مع تجنب نسخ أسرار أو محتوى ملفات إلى منصة التنبيه. يجب أن يكون معيار نجاح الكشف محدداً، مثل وصول الحدث إلى جهة مراقبة وفق زمن أو سياق معلوم، وأن يظل منفصلاً عن معيار نجاح المنع. لا يعني ارتفاع عدد الإنذارات أن المراقبة تحسنت تلقائياً؛ قد يضعف ذلك القدرة على اكتشاف أحداث ذات أهمية إذا كانت الإشارات تفتقر إلى سياق المهمة.
إدارة التغير في المورد
إذا ارتبطت النتيجة بإصدار نموذج أو مكتبة أو خادم MCP، فيجب أن يذكر القالب ما الذي يتغير عند تحديثه وما الحالات التي تحتاج إعادة تقييم. قد يؤدي تحديث وصف أداة إلى تغيير طريقة اختيار الوكيل لها، أو يؤدي تبديل خدمة استرجاع إلى تغير مرشحات الملفات، حتى إن لم تتغير الواجهة. تُقارن النسخ وفق معلومات مصدر موثوقة ولا تُنقل نتيجة قديمة تلقائياً إلى إصدار جديد. إذا لم يوفر المورد معلومات كافية عن داخله، تسجل حدود الرؤية ويُختبر ما تستطيع المؤسسة فرضه في طبقة التطبيق والتفويض والتسجيل، مع متابعة ضمانات المورد ضمن نطاقها الحقيقي.
تصميم معيار إعادة الاختبار
يعاد اشتقاق معيار التحقق من الحالة الأصلية: ماذا كان متوقعاً؟ ماذا حدث؟ ما الضابط الذي تغير؟ وما مصدر الدليل الجديد؟ لا يُقبل نجاح إعادة اختبار لأن النص المولد أصبح ألطف بينما بقيت معاملة خلفية خارج التفويض. يجب تثبيت الحساب ودور المستخدم وبيانات الاختبار وحالة الفهرس وإصدار الخدمة قدر الإمكان، وعند اختلاف شروط مهمة يُشرح أثرها على المقارنة. ويستخدم PASS إذا أثبت المصدر المناسب عمل الضابط، وFAIL إذا بقي السلوك المحظور مثبتاً، وINCONCLUSIVE إذا كانت البيانات أو السجلات ناقصة أو تعطل المكوّن الذي يفترض اختباره.
فحص أثر العلاج على المستخدم المشروع
قد يجعل الإصلاح أداة أو محرك بحث شديد التقييد لدرجة تعطيل خدمة مشروعة؛ لذلك تتضمن خطة إعادة الفحص حالات يجب أن تنجح بالإضافة إلى حالات المنع. فبعد تطبيق ترشيح وصول جديد يجب أن يستطيع الموظف رؤية سياسات قسمه، وبعد تقليل صلاحيات أداة يجب أن يظل صاحب الدور المناسب قادراً على إنشاء مسودة. وتُفحص الأدوار المجاورة إذا كان التغيير في سياسة مشتركة قد يؤثر عليها. لا تُخلط نسبة رفض الطلبات بمعدل أمان التنفيذ؛ يمكن أن ترتفع الأولى بينما تظل ثغرة التفويض موجودة، ويمكن أن ينجح الثاني بينما تحتاج صياغة النموذج إلى تحسين إضافي.
توثيق دليل الإغلاق
يحفظ السجل معرف نسخة الإصلاح وتاريخه ومالك المراجعة ونتيجة إعادة الاختبار ومصدر الدليل وروابط الأحداث، مع المحافظة على ما يثبت حالة الضعف في النسخة السابقة. قد تكون الأدلة الحساسة في مخزن مقيد ويمثل التقرير العام رابطاً أو معرفاً للمراجعين المخولين. ينبغي ألا تُمسح الحالة التاريخية عندما يتغير تقييم الخطورة، بل يوضح سبب المراجعة وما معلومات جديدة أدت إليها. وإذا بقيت فجوة كشف بعد علاج أصل التفويض، تسجل كمهمة مستقلة ولا تُخفى خلف حالة الإغلاق الأولى. هذا يحول إدارة التذاكر إلى سلسلة مساءلة قابلة للتدقيق.
قرار المخاطر المتبقية
قد لا تتمكن المؤسسة من إزالة جميع أسباب الخطر فوراً، خاصة إذا كان الإصلاح لدى مورد خارجي أو كان تعطيل وظيفة يؤثر في عمل حساس. يذكر السجل ما الخطر الذي يبقى ومَن قبل استمراره والمدة والضوابط التعويضية وعلامات إعادة فتح القرار. لا يستطيع فريق Red Team قبول خطر تجاري أو قانوني نيابة عن صاحب الصلاحية إذا لم يكن مخولاً بذلك، ولا تعني موافقة مؤقتة أن النظام أصبح متوافقاً مع جميع المعايير. يتغير القرار عند إضافة أداة أو توسيع نطاق البيانات أو ظهور دليل جديد، ويجب أن يشمل سجل التغيير هذه الحالات حتى لا يتحول الاستثناء إلى وضع دائم بلا مراجعة.
الملف التنفيذي للمراجعة
يمكن لصاحب القرار تلقي ملخص يوضح النتائج الحرجة التي أُغلقت بدليل والنتائج التي بقيت مفتوحة وقرارات الاحتواء والمخاطر المتبقية والأدوار المسؤولة. لا يحتاج الملخص إلى تفاصيل مدخلات هجومية أو أسرار إعدادات، لكنه يحتاج إلى دقة واضحة بشأن ما تم إثباته في النسخة الجديدة وما لم يُختبر. وتُعرض نسبة الإنجاز مع تعريف المقام والأولويات لا بمعزل عن حجم المخاطر، لأن إغلاق عشر تذاكر منخفضة الأثر لا يلغي ثغرة تفويض واحدة مرتفعة الحساسية. تُحدد شروط توسيع الاستخدام أو إعادة تفعيل أداة على أساس نتائج قابلة للتحقق.
حالة إغلاق افتراضية مكتملة
REMEDIATE-01: نتيجة أصلية تثبت استرجاع وثيقة تجريبية خارج الدور. حد الثقة بين المستخدم وخدمة RAG، والسبب المؤكد خلل ترشيح عند الاسترجاع. الإجراء تعديل سياسة البحث وربط الهوية في طبقة المصدر، مع تنظيف النسخ المشتقة التي لا تحترم التغيير. يعيد المراجع اختبار حسابي مستأجرين على فهرس محدد، ويتأكد من عدم ظهور ملف محظور ومن استمرار عرض الملف المسموح. يُسجل مصدر نتائج الاسترجاع وأثر التحديث وإصدار الحزمة، ثم يغلق السبب إذا اجتاز جميع المعايير. إن ظل رابط الملف الأصلي مكشوفاً فلا يعد العلاج مكتملاً رغم نجاح واجهة الدردشة.
حالة إغلاق ثانية
REMEDIATE-02: وكيل مشتريات في بيئة اختبار اقترح أداة تغيير سجل لكن نظام ERP رفض العملية، بينما لم تسجل محاولة الرفض في منصة المراقبة. هنا ضابط التفويض لم يفشل في الحالة المؤكدة، لكن الرؤية الأمنية ناقصة. الإجراء تحسين الربط بين استدعاء الوكيل وسجل قرار API وإرسال حدث مناسب إلى المراقبة، دون تكرار بيانات المورد أو رموز الدخول. يعاد تشغيل حالة اختبار مصرح بها للتأكد من ظهور الحدث ومن استمرار رفض العملية المحظورة، مع حالة مشروعة للتحقق من عدم تعطيل وظيفة المسودة. لا تُعرض هذه النتيجة بوصفها إصلاح اختراق لم يحدث في السجل الخلفي.
فحص جودة الإغلاق
يُرفض إغلاق نتيجة إذا لم يتضح الضابط الذي تغير أو لم يذكر الإصدار أو كانت نتيجة إعادة الاختبار مبنية على عطل أداة لا على قرار صلاحية صحيح. كما يُرفض استخدام تجارب بحساب إداري لإثبات سلامة مستخدم محدود دون بيان الفارق، أو وصف بيانات اصطناعية ظهرت في سياق واحد بأنها تسرب شامل لجميع العملاء. يجب أن يستطيع مدقق مستقل فهم ما الذي عولج ومن راجعه وما الأدلة التي تثبته وما الشروط التي تعيد فتحه. ويُحافظ على نسخ الوثيقة لأغراض المراجعة بدلاً من تحديث ملاحظات الماضي بصورة تمحو مسار القرار.
المصدر والتراخيص
المصدر المنهجي OWASP GenAI Red Teaming Manual v1.0، أكتوبر 2026، Phase 8 Post-Engagement & Remediation والارتباط بـPhase 7 Evaluation & Reporting. القالب والمثالان من صياغة سيادة AI ولا يمثلان تقارير OWASP رسمية أو وقائع فعلية. يستخدم ضمن نطاق أعمال مؤسسة مخولة وببيانات اصطناعية أو مواد لديها حق معالجتها، ولا يمنح تصريحاً لإجراء نشاط هجومي على الغير. تراعي إعادة الاستخدام شروط CC BY-SA 4.0 للمادة المرخصة من المصدر.