أظهر تحليل أمني مستقل أُجري على أداة Grok Build CLI، المطورة من شركة xAI، أن الأداة تقوم بنقل مستودعات Git كاملة، بما تشمله من سجلات تاريخية وبيانات اعتماد حساسة، إلى حاوية تخزين سحابية تابعة لشركة Google دون إعلام المطورين مسبقاً. وكشفت اختبارات تالية أن الشركة عطلت آلية الرفع هذه عبر إشارة تحكم من جهة الخادم دون نشر إشعار أمني أو إصدار تحديث برمجي للمستخدمين، الأمر الذي يطرح تساؤلات جدية حول مستوى الشفافية في مساعدي البرمجة المعتمدين على الذكاء الاصطناعي.
وقد استند التحليل، الذي أجراه باحث أمني مستقل يُدعى cereblab، ونُشر في مستودع عام على منصة GitHub في 10 يوليو 2026، إلى مراقبة وتحليل حركة البيانات الخاصة بالإصدار 0.2.93 من الأداة باستخدام أداة mitmproxy على نظام التشغيل macOS. وبينت البيانات الملتقطة أن برمجية العميل كانت ترسل تدفقين منفصلين؛ يختص الأول بنموذج الذكاء الاصطناعي ويشمل الملفات التي يفحصها الوكيل البرمجي لتنفيذ المهام المطلوبة، في حين يتعلق التدفق الثاني بالتخزين السحابي، حيث يُرسل حزمة Git كاملة لكل مستودع يجري تتبعه إلى حاوية تخزين على Google Cloud Storage تحمل الاسم grok-code-session-traces.
وبغية تأكيد أن عملية الرفع لا تقتصر على الملفات اللازمة للعمل، أجرى الباحث تجربة محددة؛ حيث أصدر أمراً للأداة بالاكتفاء بالرد بكلمة “OK” دون فحص أي ملفات. ومع ذلك، رصد إرسال ملف يحتوي على معرف فريد يقع في المسار src/_probe/never_read_canary.txt، إلى جانب السجل التاريخي الكامل للمستودع. وتضمنت التجربة أيضاً إدراج بيانات اعتماد افتراضية في ملف .env، لتظهر قيم مثل API_KEY وDB_PASSWORD بنص صريح غير مشفر ضمن طلبات نموذج المحادثة وفي أرشيف جلسة العمل المرسل إلى السحابة.
وفي اختبار آخر شمل مستودعاً بحجم 12 جيجابايت، اقتصرت حركة البيانات الفعلية لتنفيذ المهمة على 192 كيلوبايت، بينما تخطت البيانات المرفوعة للتخزين السحابي حاجز 5.1 جيجابايت قبل قطع الاتصال، وهو ما يمثل فارقاً يبلغ 27,800 ضعف.
كذلك تبين للباحث أن خيار “Improve the model” المتاح في الأداة، والذي قد يظنه المطورون وسيلة لتعطيل جمع البيانات، لم يمنع عمليات الرفع؛ إذ واصل الخادم إرسال القيمة trace_upload_enabled: true. وأوضح الباحث أن تفعيل هذا الخيار ينحصر في الموافقة على استخدام البيانات للتدريب، ولا يحول دون إرسال الشيفرة المصدرية خارج جهاز المستخدم. وما يزيد من حساسية الأمر أن وثائق الإعداد الرسمية لم تشر مطلقاً إلى سلوك الرفع أو إلى حاوية التخزين المستخدمة، على الرغم من تسويق الأداة بوصفها تعمل بآلية “المعالجة المحلية أولاً”.
وعقب يوم واحد من صدور التقرير، أعاد الباحث فحص العميل ذاته (الإصدار 0.2.93) ست مرات متعاقبة، ليرصد توقف عمليات الرفع السحابي تماماً، وتغير استجابة الخادم لترسل الإشارتين disable_codebase_upload: true وtrace_upload_enabled: false. ويعني ذلك تفعيل إجراء وقائي صامت من جهة الخادم عن بُعد ودون إرسال إشعار للمستخدمين. ومع ذلك، فإن هذه الملاحظة اقتصرت على جهاز وحساب فردي، ما يمنع تعميم الاستنتاج بأن هذا التعديل نهائي أو مطبق على الجميع.
ولم يشر سجل التغييرات الرسمي الخاص بالإصدار 0.2.98 الصادر في 12 يوليو إلى هذا السلوك أو التدبير الوقائي المتخذ، كما لم تقدم شركة xAI بياناً يوضح الغرض من عمليات الرفع، أو نطاقها، أو فترة الاحتفاظ بالبيانات التي تم جمعها، أو مصير المستودعات المخزنة مسبقاً في حاوية grok-code-session-traces. واقتصر تعليق الشركة اللاحق على الإشارة إلى خيارات الخصوصية المتوفرة مثل ميزة عدم الاحتفاظ بالبيانات (Zero Data Retention) المخصصة للمشتركين من قطاع الأعمال، دون توضيح مصير الملفات المرفوعة سابقاً.
ورغم أن البيانات المنشورة لا توفر دليلاً قاطعاً على تدريب xAI نماذجها باستخدام تلك الملفات أو اطلاع موظفيها عليها، فإن مكمن الخطر يتمثل في عملية الجمع التلقائي وغير المعلن للبيانات دون علم المستخدمين أو موافقتهم الواضحة.
يضع هذا السلوك علامات استفهام حول موثوقية أدوات التطوير المدعومة بالذكاء الاصطناعي، ويسلط الضوء على الأهمية البالغة للإفصاح الشفاف والكامل عن أي تدفق للبيانات خارج البيئة المحلية.
