ضُبطت أداة البرمجة Grok Build التابعة لشركة xAI وهي ترفع بصمت مستودعات Git الكاملة للمطورين — بما في ذلك سجل الالتزامات الكامل والملفات غير المتتبعة والأسرار غير المحجوبة — إلى حاوية تخزين على Google Cloud، وفقاً لتحليل على مستوى حركة الشبكة نشره باحث أمني يُعرف باسم cereblab. أوقفت xAI عمليات الرفع من جانب الخادم يوم 13 يوليو، ووعد إيلون ماسك بأن جميع البيانات المرفوعة سابقاً "ستُحذف حذفاً تاماً ونهائياً"، لكن الشركة لم تصدر بعد تنبيهاً أمنياً رسمياً.
أبرز النقاط
- كانت النسخة 0.2.93 من أداة سطر الأوامر Grok Build تحزم المستودعات الكاملة وترفعها إلى حاوية Google Cloud Storage المسماة grok-code-session-traces، بغض النظر عما تتطلبه مهمة البرمجة فعلياً.
- في أحد الاختبارات الموثقة، احتاج النموذج إلى نحو 192 كيلوبايت من السياق بينما رفعت قناة التخزين 5.10 جيجابايت — أي نحو 27,800 ضعف البيانات اللازمة.
- رُفعت ملفات .env المتتبعة دون أي حجب، بما فيها مفاتيح API وكلمات مرور قواعد بيانات مزروعة للاختبار. حتى ملف طُلب من الوكيل صراحةً عدم قراءته أبداً جرى رفعه.
- تعطيل خيار "تحسين النموذج" لم يوقف عمليات الرفع: ظل الخادم يستجيب بتفعيل رفع البيانات، ما يكشف أن الاحتفاظ بالبيانات وتدريب النموذج يخضعان لمفاتيح تحكم منفصلة وخفية.
- أوقفت xAI الرفع عبر مفتاح على جانب الخادم يوم 13 يوليو دون نشر تنبيه أو تحديث في سجل التغييرات.
التفاصيل
اعترض الباحث حركة الشبكة الصادرة من Grok Build فوجد قناتين منفصلتين: حركة النموذج العادية المستخدمة لتوليد الردود، وقناة تخزين منفصلة تؤرشف مستودع المستخدم بالكامل في 73 جزءاً بحجم نحو 75 ميجابايت لكل منها. وكانت عمليات الرفع تحدث حتى في اختبارات خالية من أي استدعاء للأدوات، طُلب فيها من الوكيل الرد بكلمة "OK" فقط دون فتح أي ملفات.
وتجاوز نطاق المشكلة شيفرة المشاريع. فقد أبلغ بعض المستخدمين عن رفع مجلداتهم الرئيسية بالكامل — بما فيها مفاتيح SSH وقواعد بيانات مديري كلمات المرور. ولأن سجلات Git الكاملة كانت تُنقل، ظلت الأسرار التي أُدرجت في الالتزامات ثم حُذفت قبل أشهر متاحة ضمن البيانات المؤرشفة.
ردت xAI عبر حسابها SpaceXAI موضحةً أن عملاء المؤسسات الخاضعين لسياسة عدم الاحتفاظ بالبيانات لم تُخزن شيفرتهم مطلقاً، وأن الاستخدام عبر مفاتيح API يحترم تلك السياسات. كما أطلقت الشركة أمر /privacy الذي يتيح للمستخدمين الأفراد تعطيل الاحتفاظ بالبيانات وحذف ما سبقت مزامنته. لكن منتقدين أشاروا إلى ما توصل إليه الباحث من أن هذا الأمر يعمل كخيار انسحاب لكل جلسة على حدة وليس المفتاح الذي أوقف الرفع فعلياً — فذلك جاء من مفتاح جانب الخادم. وكتب الباحث: "الوضع الافتراضي الصحيح هو الإيقاف".
التأثير
يحث باحثو الأمن كل مطور استخدم Grok Build على تدوير جميع بيانات الاعتماد التي كان بإمكان الأداة الوصول إليها — ليس فقط الملفات التي قرأها النموذج خلال الجلسة، بل أي ملف متتبع في المستودع وأي سر ظهر يوماً في سجل Git.
كما تبقى الشكوك قائمة حول الحذف الموعود. فقد استعلم أحد المستخدمين، بعد انسحابه عبر أمر /privacy، من واجهة برمجة التخزين الخاصة بـ xAI نفسها بعد يوم كامل، وأفاد بأن جميع الأرشيفات الـ143 المرفوعة من جهازه ما تزال موجودة بعد أكثر من 24 ساعة من الانسحاب. ولم تكشف xAI عن عدد المستخدمين المتأثرين ولا عن جدول زمني للحذف ولا عن وسيلة تتيح للمطورين التحقق من إزالة بياناتهم.
الخلفية
أُطلقت Grok Build في وقت سابق من هذا العام كمنافس من xAI لأداتي Claude Code وCodex CLI من OpenAI، ضمن موجة وكلاء البرمجة العاملين في الطرفية والمتغلغلين اليوم في بيئات المطورين المحلية. وهذا الموقع المتميز هو بالضبط ما يجعل الحادثة خطيرة: فجميع وكلاء البرمجة السحابيين يرسلون بعض السياق للاستدلال، لكن أرشفة مستودعات كاملة بالجملة عبر قناة منفصلة يتجاوز بكثير ما تتطلبه أي مهمة برمجية.
وتأتي الحادثة وسط تدقيق متزايد في ممارسات البيانات لدى أدوات التطوير المعتمدة على الذكاء الاصطناعي، حتى إن سام ألتمان الرئيس التنفيذي لـ OpenAI أشار إلى المشكلة علناً — في انتقاد مباشر نادر بين مختبرات ذكاء اصطناعي متنافسة.
ما التالي
يقول الباحث الذي كشف عمليات الرفع إنه سيعيد فحص واجهة برمجة التخزين يومياً وسينشر ما إذا كانت xAI ستفي بوعد الحذف. وتعيد فرق المؤسسات تقييم وكلاء البرمجة التي تستوفي متطلبات عدم الاحتفاظ بالبيانات، ومن المرجح أن تسرّع الحادثة المطالب بجعل جمع البيانات في أدوات التطوير الذكية قابلاً للتحقق ومعطلاً افتراضياً.
المصدر: The Hacker News