قائمة فحص أمان سكربتات الذكاء الاصطناعي قبل الإطلاق

ارسم مسار البيانات والأفعال قبل تشغيل أي ماسح

ابدأ برسم بسيط: المستخدم، الواجهة، الخادم، مزود النموذج، قاعدة البيانات، التخزين، وأي Tool أو Webhook. اكتب عند كل سهم نوع البيانات ومن يستطيع قراءتها أو تغييرها. OWASP تضع حقن التعليمات، كشف المعلومات الحساسة، سلسلة التوريد، المعالجة غير الآمنة للمخرجات، والوكالة المفرطة ضمن أبرز مخاطر تطبيقات LLM.

لا يصل المفتاح إلى المتصفح أو Git أو سجل الخطأ

ضع مفاتيح المزود وقاعدة البيانات وWebhooks في مخزن أسرار البيئة، لا داخل الكود أو ملف مرفوع للمستودع. افصل مفاتيح الاختبار عن الإنتاج، وامنح كل خدمة أقل صلاحية ممكنة. إذا ظهر مفتاح في Commit أو Log، ألغِه ودوّره فوراً؛ حذف السطر وحده لا يبطل المفتاح ولا يمحوه من التاريخ.

تحقق من المستخدم في الخادم عند كل عملية حساسة

إخفاء زر في الواجهة ليس صلاحية. على الخادم التحقق من الجلسة والدور وملكية المورد وحدود الخطة. افصل صلاحيات المسؤول عن المستخدم، واختبر الوصول الأفقي: هل يستطيع مستخدم تغيير المعرّف وقراءة محادثة أو ملف أو فاتورة مستخدم آخر؟

عامل النص والملفات والويب كمدخل غير موثوق

قد تأتي التعليمات الخبيثة مباشرة من المستخدم أو بصورة غير مباشرة من صفحة أو ملف أو بريد يدخل إلى السياق. لا تعتمد على System Prompt وحده كحاجز أمني. افصل البيانات عن التعليمات، وحدد ما يستطيع النموذج فعله خارجياً، واختبر محاولات تجاوز السياسة وتسريب السياق.

توصي OpenAI بالاختبار الخصومي، وتقييد المدخلات والمخرجات، واستخدام Moderation والمراجعة البشرية حيث يلزم. ابنِ مجموعة اختبارات تشمل لغات متعددة ونصوصاً طويلة وتعليمات مخفية داخل المصادر المسترجعة.

لا تمنح النموذج وكالة أوسع من المهمة

تصف OWASP «الوكالة المفرطة» كخطر ينفذ فيه النظام أفعالاً ضارة بسبب مخرجات متلاعب بها أو غامضة. لا تعطِ أداة واحدة صلاحية قراءة كل شيء وكتابة كل شيء. صمّم Tools ضيقة، وتحقق من Arguments في الخادم، واربط التنفيذ بهوية المستخدم وصلاحياته.

مخرج النموذج بيانات غير موثوقة، لا كود جاهز للتنفيذ

لا تمرر نص النموذج إلى SQL أو Shell أو HTML أو رابط Redirect بلا تحقق وتعقيم. استخدم مخرجات منظمة بـSchema صارم، واسمح بالقيم المتوقعة فقط، وأعد التحقق قبل الاستعمال. افحص نوع الملف وحجمه ومحتواه، وغيّر اسمه، وخزّنه خارج مسار التنفيذ.

ثبّت الإصدارات وافهم ما يدخل إلى الإنتاج

شغّل npm audit وراجع التقرير، ولا تستخدم npm audit fix --force بلا اختبار لأن التحديث الكبير قد يكسر التطبيق. احتفظ بـpackage-lock وشغّل npm ci في البناء، وراجع الحزم غير الضرورية وسكربتات التثبيت والمصدر والصيانة.

فحص رسمي

التقرير نقطة بداية لا شهادة أمان

توضح npm أن التدقيق يكشف ثغرات معروفة في شجرة التبعيات ويقترح معالجة عند توفرها، لكنه لا يفحص كل أنواع العيوب ولا Peer Dependencies.

فعّل Dependency graph وDependabot alerts، واستخدم Code scanning إن كانت خطتك ومستودعك يدعمانه. راجع أي تحديث أمني في بيئة اختبار قبل دمجه.

قلّل ما ترسله وما تحتفظ به

لا ترسل الاسم أو البريد أو أرقام الهوية إلى النموذج إذا لم تكن الميزة تحتاجها. راجع إعدادات الاحتفاظ لدى المزود، ومدة تخزين المحادثات، ومن يستطيع الوصول إلى Logs ونسخ الاحتياط. ضع سياسة حذف وطلب تصدير واضحة، وحدد الغرض القانوني لمعالجة بيانات العملاء حسب سوقك.

استخدم Moderation وفق سياسة منتجك، وسجل سبب الحظر أو الإحالة للمراجعة دون تخزين محتوى حساس أكثر من اللازم. للمجالات عالية المخاطر، اجعل المراجعة البشرية جزءاً من المسار لا استثناءً.

اعرف ماذا ستفعل في أول ساعة من الحادث

أنشئ Logs مترابطة بمعرّف طلب ومستخدم غير مباشر، وسجل محاولات الدخول وتغيير الصلاحيات واستدعاءات الأدوات ونتائج Webhooks وأخطاء المزود. لا تسجل الأسرار أو النصوص الحساسة افتراضياً. اضبط تنبيهات على ارتفاع التكلفة، معدل الأخطاء، محاولات Prompt Injection، وتكرار الأفعال الحساسة.

لا تعتبر البند منجزاً دون دليل

إذا فشل بند حرج، أطلق نسخة محدودة بلا الأداة الحساسة أو أجّل الإطلاق. الأمن قرار نطاق، وليس مرحلة تجميل أخيرة.