أظهرت الدراسة الأمنية "Friendly Fire" أنه يمكن خداع وكيل الذكاء الاصطناعي ببساطة عن طريق دس تعليمات خبيثة في ملف README، وسوف يمتثل الوكيل لها دون النظر مطلقًا إلى الكود الأساسي. ظهرت نفس الثغرة في خط أنابيب (pipeline) لأتمتة مدونة شخصية اعتمدت على علامة "الموافقة التلقائية" (auto-approve) خلال مرحلة توليد غير خاضعة للإشراف، مما كشف عن سطح هجوم مخفي.
دراسة Friendly Fire تكشف عن ناقل هجوم مخفي
أظهر الباحثون وراء ورقة Friendly Fire استغلالاً بسيطاً ولكنه قوي: يقوم المهاجم بدمج أمر في ملف توثيق يقرأه الذكاء الاصطناعي كجزء من سير عمله المعتاد. ولأن الوكيل يثق في محتوى الملف، فإنه ينفذ الأمر المخفي كما لو كان تعليمات مشروعة. لا يتطلب الهجوم اختراق نموذج الذكاء الاصطناعي نفسه؛ بل يحتاج فقط إلى التأثير على البيانات التي يعالجها النموذج أثناء عدم وجود مراقبة بشرية.
المساهمة الرئيسية للدراسة ليست في حداثة الحمولة (payload)، بل في الكشف عن أن أوضاع "الموافقة التلقائية" (auto-approve)—وهي الإعدادات التي تأمر الذكاء الاصطناعي بالتصرف بناءً على أي شيء يقرأه دون فحص ثانوي—تخلق علاقة ثقة ضمنية مع مصادر البيانات الخارجية. وعندما تكون هذه الثقة عمياء، يصبح خط الأنابيب بوابة لتنفيذ أكواد برمجية عشوائية.
كيف انهار خط أنابيب مدونة غير خاضع للإشراف
طبق مؤلف الدراسة المنطق نفسه على نظام أتمتة مدونة شخصية. يتكون سير العمل من ثلاث مراحل:
- مرحلة التوليد (Generation stretch) – يكتب الذكاء الاصطناعي المقال دون أي إشراف بشري.
- بوابة ضمان الجودة (QA gate) – فحص آلي لدرجة الجودة لتقييم المخرجات.
- زر تيليجرام (Telegram button) – يجب على الإنسان الضغط على زر لنشر المنشور.
خلال مرحلة التوليد، قام المؤلف بتفعيل علامة تسمى dangerously-skip-permissions ، والتي تخبر الذكاء الاصطناعي بمعاملة أي مدخلات على أنها معتمدة. تكرر هذه العلامة جوهرياً وضع "الموافقة التلقائية" الذي أشارت إليه ورقة Friendly Fire.
كشفت عملية تدقيق لاحقة عن فجوة واسعة النطاق: إذا تمكن المهاجم من التأثير على أي ملف يقرأه الذكاء الاصطناعي في تلك النافذة الزمنية، فيمكنه توجيه خط الأنابيب بأكمله. عانى نظام المؤلف نفسه من إخفاقات صامتة في خمس حالات من أصل ست، لأن نصاً برمجياً للإعدادات (configuration script) قام عن غير قصد بالكتابة فوق إعدادات نص برمجى آخر. ومع عدم وجود سجلات لرموز الخروج (exit codes) أو درجات ضمان الجودة، استمرت المشكلة لمدة ثلاثة أيام قبل اكتشافها.
يثبت هذا الحادث أن الأمان لم يأتِ من الثقة في مخرجات الذكاء الاصطناعي، بل من نقاط التفتيش الثلاث الصريحة المحيطة بمرحلة التوليد.
أين يكمن الأمان حقاً
تلتقي الدراسة وفشل أتمتة المدونة عند نقطة واحدة: يجب أن تكون الحماية خارج عملية التوليد. يمكن استدراج الذكاء الاصطناعي إلى أي سلوك عندما يعمل في حالة الموافقة التلقائية؛ وحدها الضوابط المحيطة يمكنها اكتشاف ومنع الإجراءات غير المرغوب فيها.
ملاحظات رئيسية:
- الموافقة البشرية في النهاية تنجح لأنها تراجع المنتج النهائي، وليس الخطوات الوسيطة التي تكون سريعة للغاية وكثيرة جداً بحيث يصعب الإشراف عليها في الوقت الفعلي.
- عتبات الجودة (Quality thresholds) المطبقة بعد التوليد ولكن قبل النشر تلتقط المخرجات ذات الثقة المنخفضة التي قد تكون تعرضت للتلاعب.
- التسجيل الشامل (Comprehensive logging) لكل رمز خروج، ودرجة ضمان جودة، وتغيير في الإعدادات يجعل الإخفاقات الصامتة مرئية قبل أن تتفاقم.
دروس لأي شخص يدير وكلاء يعملون بنظام الموافقة التلقائية
- سجل كل شيء – التقط رموز الخروج، ودرجات ضمان الجودة، وأي تغيير في ملفات الإعدادات. لا يمكنك إصلاح ما لا يمكنك رؤيته.
- فرض بوابة جودة صارمة – ضع عتبة غير قابلة للتفاوض يجب استيفاؤها قبل أن يتمكن خط الأنابيب من الانتقال إلى المرحلة التالية.
- احتفظ بالموافقة البشرية للخطوة النهائية – محاولة مراقبة الذكاء الاصطناعي أثناء التوليد أمر غير واقعي؛ الضغط على زر واحد بعد جميع الفحوصات هو أكثر موثوقية بكثير.
- حماية ملفات الإعدادات – اعزلها عن الأدوات الأخرى التي قد تعيد كتابة الإعدادات، وقم بتدقيق أي صلاحية وصول للكتابة بانتظام.
الخلاصة
وكلاء الذكاء الاصطناعي غير الخاضعين للإشراف آمنون فقط بقدر الفجوات التي تغلقها من حولهم. تحول علامة "الموافقة التلقائية" الراحة إلى باب خلفي صامت؛ التسجيل الشامل، وبوابات الجودة الصارمة، والموافقة البشرية النهائية هي الدفاعات العملية التي تمنع خط الأنابيب من التحول إلى ناقل هجوم.