رصد أداة Grok وهي ترفع مستودعات كاملة وأسرارًا إلى السحابة

للحظةٍ قد تبدو أدوات الذكاء الاصطناعي البرمجية وكأنها مساعد مثالي يعمل بصمت داخل جهازك، يفهم الشيفرة دون أن يغادر حدودها، ويحترم أسرار المشروع كما لو كانت أسراره الخاصة. لكن ما كشفه باحثون أمنيون هذا الأسبوع حول أداة Grok Build من xAI أعاد طرح سؤال قديم بصيغة جديدة: ماذا يعني حقاً “محلي أولاً”؟

بحسب تحليل تقني نُشر في 10 يوليو، فإن النسخة 0.2.93 من Grok Build CLI كانت تنقل محتويات ملفات المشاريع – بما في ذلك ملفات .env التي تحتوي مفاتيح API وكلمات مرور قواعد البيانات – إلى خوادم xAI دون تنقيح. الاكتشاف لا يتعلق بثغرة عابرة، بل بسلوك منهجي يتناقض مع الرسائل التسويقية التي رافقت إطلاق الأداة في مايو 2026.

عند إطلاق Grok Build، شددت xAI على أن “لا شيفرة مصدرية تُنقل إلى خوادم الشركة”. لكن تحليل حركة البيانات على مستوى الشبكة باستخدام mitmproxy أظهر أن الأداة ترسل الملفات المقروءة عبر نقطتي نهاية: الأولى إلى واجهة النموذج الحي، والثانية إلى قناة تخزين دائمة.

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

الأمر لم يتوقف عند الملفات النشطة. التحليل أظهر أن الأداة ترفع المستودع كاملاً، مع كل الملفات المتتبعة وسجل Git الكامل، على هيئة git bundle. في اختبار على مشروع بحجم 12 جيجابايت، انتقل أكثر من 5 جيجابايت من البيانات دون فشل واحد في النقل.

نقطة التحميل كانت حزمة تخزين على Google Cloud باسم grok-code-session-traces، ما يعني أن البيانات لا تمر فقط عبر واجهة النموذج، بل تُؤرشف في قناة منفصلة. هذا التفصيل التقني يوسّع نطاق المخاطر، لأنه يضيف بعد التخزين طويل الأمد إلى معادلة الخصوصية.

توفر Grok Build خياراً بعنوان “Improve the model”، وهو الإعداد الوحيد الواضح للمستخدم المتعلق بالخصوصية. لكن إيقافه لم يوقف رفع المستودعات. تحليل استجابة واجهة الإعدادات أظهر أن trace_upload_enabled بقي مفعلاً حتى بعد تعطيله.

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

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

هذه ليست حلولاً مثالية، لكنها تعكس توجهاً متنامياً: المطورون باتوا يتعاملون مع أدوات الذكاء الاصطناعي كأنها خدمات سحابية كاملة الصلاحيات، لا مجرد مساعد محلي.

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

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

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