ثغرة في أدوات برمجة الذكاء الاصطناعي تكشف هشاشة الاعتماد على «الإنسان في الحلقة»

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

النتيجة الأبرز في هذا التحقيق الأمني ليست فقط أن أدوات مثل Amazon Q Developer وAnthropic Claude Code وCursor وGoogle Antigravity وWindsurf، إضافة إلى Augment، تأثرت بنمط خلل متشابه، بل إن هذا الخلل استغل فكرة «الإنسان في الحلقة» نفسها. فبدلاً من أن يكون المستخدم آخر خط دفاع، جرى تضليله بمعلومات ناقصة أو مضللة جعلته يوافق على إجراء يبدو بريئاً، بينما كانت الأداة تنفذ فعلياً خطوة أخطر خارج مساحة العمل المسموح بها.

ثغرة تتجاوز مجرد أخطاء في التنفيذ

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

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

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

ماذا يكشف هذا النمط عن أدوات البرمجة بالذكاء الاصطناعي

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

خبراء الأمن الذين علّقوا على النتائج شددوا على أن المشكلة لا ترتبط بجودة الشيفرة التي ينتجها النموذج، بل بطريقة تصميم الأداة نفسها. فحتى لو كان المخرج البرمجي سليماً، يبقى السؤال: هل تستطيع الأداة أن تعرض على المستخدم حقيقة ما تفعله؟ وهل تملك المؤسسة ضوابط تمنعها من الوصول إلى ملفات حساسة قبل الإذن الصريح؟

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

تأثير واسع على بيئات العمل المؤسسية

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

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

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

ما الذي ينبغي أن تفعله فرق الأمن والتطوير

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

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

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

مشكلة أعمق من ثغرة واحدة

ما يجعل GhostApproval لافتة ليس فقط عدد الأدوات المتأثرة، بل ما تقوله عن المرحلة الحالية من تطور البرمجة بالذكاء الاصطناعي. فالسوق يتحرك بسرعة نحو وكلاء أكثر استقلالية، لكن الحوكمة الأمنية لم تلحق بعد بهذا التحول بالسرعة نفسها. ونتيجة ذلك، قد تظهر الثغرات الجديدة في المكان نفسه تقريباً: في المنطقة الفاصلة بين ما تقرره الآلة وما يعتقد الإنسان أنه سمح به.

لذلك، تبدو الرسالة الأساسية واضحة: كلما توسعت قدرات الوكلاء البرمجيين، كان لزاماً على المؤسسات أن تعيد تعريف الثقة، وأن تتعامل مع هذه الأدوات على أنها جزء من البنية الحساسة لا مجرد مساعدات إنتاجية. فالحل لا يكمن في مزيد من رسائل التأكيد، بل في تصميم أكثر صرامة للصلاحيات والبيئات والرقابة.

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