أثارت أداة البرمجة المدعومة بالذكاء الاصطناعي Grok Build من SpaceXAI انتقادات حادة بعد أن اكتشف باحثون قيامها برفع مستودعات مستخدمين كاملة إلى تخزين Google Cloud. وقد أثار هذا الاختراق حالة من القلق بشأن كمية البيانات المملوكة التي يمكن لمساعدي الذكاء الاصطناعي استيعابها والاحتفاظ بها.

الاحتفاظ المفرط بالبيانات والمخاطر الأمنية

أظهر تحليل Cereblab أن واجهة سطر الأوامر (CLI) الخاصة بـ Grok Build قامت بتجميع وإرسال قواعد برمجية (codebases) كاملة إلى السحابة. والأمر الأكثر إثارة للقلق هو أن الأداة فتحت ملفات طُلب منها تجاهلها، واسترجعت أسراراً (secrets) كان المطورون قد مسحوها من سجل git.

هذا المستوى من تكديس البيانات يجعل المنافسين مثل Claude Code يبدون متواضعين للغاية. وحذر الدكتور Lukasz Olejnik، الباحث الأمني في King’s College London، من أن مثل هذا الجمع للبيانات قد يعرض الكود المصدري، ومخططات البنية التحتية، والثغرات الأمنية، وبيانات الاعتماد لخوادم بعيدة.

رد فعل SpaceXAI وإيلون ماسك

أوقفت SpaceXAI ميزة الرفع. ويرى الباحثون الآن علامة disable_codebase_upload: true على خوادم Grok، مما يؤكد أن عملية الدفع التلقائي لم تعد تعمل.

نشر إيلون ماسك على منصة X أن جميع البيانات التي تم رفعها مسبقاً سيتم "حذفها تماماً وبشكل نهائي". كما حث المستخدمين على السماح لشركة SpaceXAI بالاحتفاظ بالبيانات من أجل "إصلاح مشكلات التصحيح" (debugging issues)، وهو طلب يراه الكثيرون متناقضاً.

اقترحت الشركة استخدام أمر CLI المسمى /privacy لإدارة الاحتفاظ بالبيانات، لكن Cereblab لاحظت أن الأمر يغير فقط إعدادات التخزين لكل جلسة، ولا يوقف عمليات رفع المستودعات المنهجية التي تسببت في هذه الفضيحة.

لماذا يهم هذا المطورين والمؤسسات

تحذر هذه الواقعة المطورين والمؤسسات من أن وكلاء البرمجة المدعومين بالذكاء الاصطناعي لم يعودوا مجرد أدوات بسيطة للإكمال التلقائي؛ بل يمكنهم قراءة الكود وتعديله وإرساله (commit) بأنفسهم. وعندما يتجاوز الوكيل ملفات التجاهل (ignore files) أو يستعيد أسراراً محذوفة، فإن أي ادعاء بـ "عدم الاحتفاظ بالبيانات" (zero data retention) يجب إثباته باختبارات تقنية، وليس بوعود واجهة المستخدم (UI).

بالنسبة للمديرين التقنيين (CTOs) وأصحاب المنتجات، تؤكد هذه الحادثة الحاجة إلى:

  • عمليات تدقيق مستقلة لأدوات الذكاء الاصطناعي على قواعد برمجية حقيقية.
  • بنود تعاقدية توضح كيفية التعامل مع البيانات، وفترات الاحتفاظ بها، وضمانات الحذف.
  • ضمانات وقت التشغيل (Runtime safeguards) التي تفرض أذونات على مستوى الملف، خاصة للمستودعات التي تحتوي على بيانات اعتماد أو خوارزميات مسجلة ببراءة اختراع.

النقاط الرئيسية المستفادة

  • نطاق بيانات غير مقصود: قامت Grok Build برفع مستودعات كاملة، بما في ذلك الملفات المقيدة والأسرار المحذوفة، إلى Google Cloud.
  • حالة التخفيف من المخاطر: أوقفت SpaceXAI الرفع التلقائي وتعهدت بمسح البيانات التي تم جمعها بالفعل.
  • الآثار الأمنية: يسلط الاختراق الضوء على خطر الاحتفاظ المفرط بالبيانات في وكلاء البرمجة بالذكاء الاصطناعي، مما قد يؤدي إلى تسريب المنطق البرمجي المملوك وبيانات الاعتماد.

تم ضبط أداة Grok Build من SpaceXAI وهي تقوم بصمت برفع قواعد برمجية كاملة للمستخدمين إلى Google Cloud، مما عرض الملفات المصدرية المملوكة والأسرار المحذوفة للخطر.

ماذا حدث

تتبعت Cereblab حركة مرور الشبكة لواجهة CLI الخاصة بـ Grok Build إلى حاوية (bucket) في Google Cloud ووجدت أنها تقوم بتعبئة مستودعات git كاملة تلقائياً لرفعها. باختصار، قام المساعد بسحب بيانات طُلب منه تجاهلها.

كيف تم اكتشاف الاختراق

فحص الباحثون البيانات المرسلة (payloads) ورأوا أن علامة الرفع مفعلة افتراضياً، دون وجود خيار عالمي لإلغاء الاشتراك. وحذر الدكتور Lukasz Olejnik من أن هذا "الاحتفاظ المفرط بالبيانات" قد يسرب منطق الأعمال، وتفاصيل البنية التحتية، ورموز المصادقة (authentication tokens). وبالمقارنة مع مساعدي البرمجة الآخرين بالذكاء الاصطناعي — مع اعتبار Claude Code نقطة مرجعية — فإن سلوك Grok Build يعد أكثر توغلاً بشكل ملحوظ.

رد فعل SpaceXAI

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

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

لماذا يهم هذا المطورين والمؤسسات

تتطور وكلاء البرمجة المدعومين بالذكاء الاصطناعي من مجرد أدوات إكمال تلقائي إلى أدوات مستقلة يمكنها قراءة الكود وتعديله وإرساله (commit). وعندما يتمكن الوكيل من تجاوز ملفات التجاهل المحلية أو استعادة أسرار محذوفة، فإن أي وعد بـ "عدم الاحتفاظ بالبيانات" يجب التحقق منه باختبارات تقنية، وليس فقط من خلال إعدادات واجهة المستخدم. يجب على المديرين التقنيين (CTOs) وأصحاب المنتجات:

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

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

وجهة النظر المقابلة من SpaceXAI

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

الخلاصة

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