سلوكيات تسريب البيانات التي تتعارض مع تسويق "المعالجة المحلية"

حدد الباحث قناتين مختلفتين جوهريًا لنقل البيانات تغادران جهاز المطور :

• قناة التفاعل مع النموذج (POST /v1/responses): يتم فيها إرسال الملفات التي فتحها الوكيل الذكي (agent) بشكل متسلسل مع طلبات النموذج. هذا هو السلوك المتوقع من وكيل برمجي سحابي.
• قناة التخزين (POST /v1/storage): يتم فيها تعبئة المستودع بأكمله بشكل مستقل كـ حزمة Git (git bundle) ورفعها على دفعات بحجم ~75 ميجابايت إلى حاوية تخزين سحابية على Google Cloud Storage تُدعى grok-code-session-traces .

أثبت التفاوت الكبير في حجم البيانات أن عملية الرفع لم تكن مدفوعة بما قرأه الوكيل الذكي. في اختبار على مستودع تجريبي بحجم 12 جيجابايت، نقلت قناة التخزين 5.10 جيجابايت عبر 73 دفعة (جميعها استجابت برمز HTTP 200)، بينما نقلت قناة التفاعل مع النموذج 192 كيلوبايت فقط — أي بنسبة تصل إلى ~27,800 ضعف . وحتى مع إعطاء الأمر "رد بـ'حسناً'، لا تقرأ أي ملفات"، قامت الأداة برفع المستودع بأكمله كحزمة Git؛ وأدى استنساخ (clone) الحزمة التي تم اعتراضها إلى استعادة ملف (src/_probe/never_read_canary.txt) طُلب من الوكيل صراحةً عدم فتحه، بالإضافة إلى سجل كامل لتاريخ التعديلات (commit history) .

أنواع المفاتيح والملفات المنقولة دون حجب

• ملفات .env التي تحتوي على مفاتيح API وكلمات مرور قواعد البيانات وبيانات اعتماد أخرى تم نقلها نصاً صريحاً، دون أي حجب أو إخفاء عبر القناتين . في الاختبارات الخاضعة للرقابة، ظهر ملف بحجم 48 كيلوبايت يحتوي على بيانات اعتماد قاعدة البيانات ومفاتيح API بشكل واضح في نص الطلب .
• كل ملف متعقب في المستودع، بالإضافة إلى تاريخ Git الكامل (جميع التعديلات والفروع والعلامات) تم تعبئتها ورفعها . هذا يعني أن المفاتيح السرية التي تمت إزالتها منذ أشهر ولكن جرى تدويرها لاحقاً قد تظل موجودة في البيانات المرفوعة.
• تم تحديد آلية الرفع كـ حزمة Rust تابعة لـ xAI (xai-data-collector) مضمنة في الملف الثنائي (binary)، مع مسارات مصدر مثل crates/codegen/xai-data-collector/src/gcs.rs وcrates/codegen/xai-grok-shell/src/upload/ .
• على قاعدة بيانات حقيقية بحجم 12 جيجابايت تحتوي على ملفات عشوائية لم تُقرأ أبداً، قبلت نقطة نهاية التخزين الرفع دون أي رفض قائم على الحجم؛ كانت الاستجابات الوحيدة غير الناجحة (HTTP 402/429) أخطاء تتعلق بحصص استخدام النموذج، وليس فشلاً في التخزين .

فشل خيار إلغاء الاشتراك (Opt-Out)

اختبر الباحث خيار الخصوصية "تحسين النموذج" (Improve the model) ووجد أنه لم يوقف عمليات الرفع .

• بعد تعطيل الخيار وإعادة تشغيل الأداة، كانت نقطة نهاية إعدادات الخادم لا تزال تُرجع trace_upload_enabled: true .
• استمرت قناة التخزين في قبول دفعات حزمة Git مع استجابات HTTP 200 .
• يوجد خيار إعداد disable_codebase_upload=true في إعدادات الأداة، لكن علاقته بسلوك الخادم غير موثقة، وأظهرت اختبارات الباحث أن الخادم لم يحترم تفضيلات العميل .

التوصيات للمطورين المتأثرين

يوصي الباحث الأصلي والمحللون اللاحقون بما يلي :

إجراءات فورية للفرق التي استخدمت Grok Build CLI على مستودعات خاصة:

• قم بتدوير جميع بيانات الاعتماد التي كانت موجودة في أي ملف .env أو ملف تكوين أو تاريخ Git داخل المستودعات المستخدمة مع Grok Build، حيث قد تكون قد نُقلت وخُزنت في حاوية grok-code-session-traces على Google Cloud .
• دقق في تاريخ Git بحثاً عن المفاتيح السرية التي ربما كانت موجودة في أي تعديل سابق، لأن الأداة أرسلت تاريخ التعديلات بالكامل .
• افترض أن البيانات قد خُزنت، وليس فقط نُقلت — فقد أكد الخادم (HTTP 200) استلام جميع طلبات التخزين .
• اسأل xAI عما إذا تم حذف الحاوية، وما هي ضوابط الوصول التي كانت موجودة، وما إذا كانت اتفاقية معالجة البيانات (DPA) تغطيها (لم يتم نشر أي اتفاقية في وقت الكشف) .

توصيات معمارية لأي وكيل برمجي:

• شغّل الوكلاء داخل حاويات/أجهزة افتراضية مع تثبيت دليل المهمة فقط، دون دليل المستخدم المنزلي، دون وكيل SSH، دون مقبس Docker، ودون تعريض أدلة بيانات اعتماد السحابة .
• طبّق ضوابط للاتصالات الصادرة: اسمح بنقاط نهاية استدلال النموذج وخوادم المصادقة، وامنع الرفع المباشر لوحدات التخزين العامة. قم بالتنبيه عند تجاوز النقل 100 ميجابايت .
• استخدم التقاط حزم الشبكة على مستوى النظام، وتسجيل DNS، ومراقبة الشبكة على نقاط النهاية لاكتشاف عمليات الرفع التي تقوم بها عمليات التنسيق الخلفية التي قد تفوتها عدادات البايت الأمامية .
• اختبر الحد الأدنى والحد الأقصى للأوامر تحت التقاط الحزمة — الحالات التي يُطلب فيها من الوكيل عدم قراءة الملفات ضرورية للكشف عن تسريب يتجاوز نافذة السياق .
• قم بتشغيل ثلاثة حالات أوامر على الأقل: (1) "رد بـ'حسناً'، لا تقرأ أي ملفات"، (2) اقرأ ملفاً واحداً محدداً، (3) افحص لغة المشروع — ثم قارن البايتات لكل نقطة نهاية .

سلوكيات تسريب البيانات التي تتعارض مع تسويق "المعالجة المحلية"

حدد الباحث قناتين مختلفتين جوهريًا لنقل البيانات تغادران جهاز المطور :

• قناة التفاعل مع النموذج (POST /v1/responses): يتم فيها إرسال الملفات التي فتحها الوكيل الذكي (agent) بشكل متسلسل مع طلبات النموذج. هذا هو السلوك المتوقع من وكيل برمجي سحابي.
• قناة التخزين (POST /v1/storage): يتم فيها تعبئة المستودع بأكمله بشكل مستقل كـ حزمة Git (git bundle) ورفعها على دفعات بحجم ~75 ميجابايت إلى حاوية تخزين سحابية على Google Cloud Storage تُدعى grok-code-session-traces .

أثبت التفاوت الكبير في حجم البيانات أن عملية الرفع لم تكن مدفوعة بما قرأه الوكيل الذكي. في اختبار على مستودع تجريبي بحجم 12 جيجابايت، نقلت قناة التخزين 5.10 جيجابايت عبر 73 دفعة (جميعها استجابت برمز HTTP 200)، بينما نقلت قناة التفاعل مع النموذج 192 كيلوبايت فقط — أي بنسبة تصل إلى ~27,800 ضعف . وحتى مع إعطاء الأمر "رد بـ'حسناً'، لا تقرأ أي ملفات"، قامت الأداة برفع المستودع بأكمله كحزمة Git؛ وأدى استنساخ (clone) الحزمة التي تم اعتراضها إلى استعادة ملف (src/_probe/never_read_canary.txt) طُلب من الوكيل صراحةً عدم فتحه، بالإضافة إلى سجل كامل لتاريخ التعديلات (commit history) .

أنواع المفاتيح والملفات المنقولة دون حجب

• ملفات .env التي تحتوي على مفاتيح API وكلمات مرور قواعد البيانات وبيانات اعتماد أخرى تم نقلها نصاً صريحاً، دون أي حجب أو إخفاء عبر القناتين . في الاختبارات الخاضعة للرقابة، ظهر ملف بحجم 48 كيلوبايت يحتوي على بيانات اعتماد قاعدة البيانات ومفاتيح API بشكل واضح في نص الطلب .
• كل ملف متعقب في المستودع، بالإضافة إلى تاريخ Git الكامل (جميع التعديلات والفروع والعلامات) تم تعبئتها ورفعها . هذا يعني أن المفاتيح السرية التي تمت إزالتها منذ أشهر ولكن جرى تدويرها لاحقاً قد تظل موجودة في البيانات المرفوعة.
• تم تحديد آلية الرفع كـ حزمة Rust تابعة لـ xAI (xai-data-collector) مضمنة في الملف الثنائي (binary)، مع مسارات مصدر مثل crates/codegen/xai-data-collector/src/gcs.rs وcrates/codegen/xai-grok-shell/src/upload/ .
• على قاعدة بيانات حقيقية بحجم 12 جيجابايت تحتوي على ملفات عشوائية لم تُقرأ أبداً، قبلت نقطة نهاية التخزين الرفع دون أي رفض قائم على الحجم؛ كانت الاستجابات الوحيدة غير الناجحة (HTTP 402/429) أخطاء تتعلق بحصص استخدام النموذج، وليس فشلاً في التخزين .

فشل خيار إلغاء الاشتراك (Opt-Out)

اختبر الباحث خيار الخصوصية "تحسين النموذج" (Improve the model) ووجد أنه لم يوقف عمليات الرفع .

• بعد تعطيل الخيار وإعادة تشغيل الأداة، كانت نقطة نهاية إعدادات الخادم لا تزال تُرجع trace_upload_enabled: true .
• استمرت قناة التخزين في قبول دفعات حزمة Git مع استجابات HTTP 200 .
• يوجد خيار إعداد disable_codebase_upload=true في إعدادات الأداة، لكن علاقته بسلوك الخادم غير موثقة، وأظهرت اختبارات الباحث أن الخادم لم يحترم تفضيلات العميل .

التوصيات للمطورين المتأثرين

يوصي الباحث الأصلي والمحللون اللاحقون بما يلي :

إجراءات فورية للفرق التي استخدمت Grok Build CLI على مستودعات خاصة:

• قم بتدوير جميع بيانات الاعتماد التي كانت موجودة في أي ملف .env أو ملف تكوين أو تاريخ Git داخل المستودعات المستخدمة مع Grok Build، حيث قد تكون قد نُقلت وخُزنت في حاوية grok-code-session-traces على Google Cloud .
• دقق في تاريخ Git بحثاً عن المفاتيح السرية التي ربما كانت موجودة في أي تعديل سابق، لأن الأداة أرسلت تاريخ التعديلات بالكامل .
• افترض أن البيانات قد خُزنت، وليس فقط نُقلت — فقد أكد الخادم (HTTP 200) استلام جميع طلبات التخزين .
• اسأل xAI عما إذا تم حذف الحاوية، وما هي ضوابط الوصول التي كانت موجودة، وما إذا كانت اتفاقية معالجة البيانات (DPA) تغطيها (لم يتم نشر أي اتفاقية في وقت الكشف) .

توصيات معمارية لأي وكيل برمجي:

• شغّل الوكلاء داخل حاويات/أجهزة افتراضية مع تثبيت دليل المهمة فقط، دون دليل المستخدم المنزلي، دون وكيل SSH، دون مقبس Docker، ودون تعريض أدلة بيانات اعتماد السحابة .
• طبّق ضوابط للاتصالات الصادرة: اسمح بنقاط نهاية استدلال النموذج وخوادم المصادقة، وامنع الرفع المباشر لوحدات التخزين العامة. قم بالتنبيه عند تجاوز النقل 100 ميجابايت .
• استخدم التقاط حزم الشبكة على مستوى النظام، وتسجيل DNS، ومراقبة الشبكة على نقاط النهاية لاكتشاف عمليات الرفع التي تقوم بها عمليات التنسيق الخلفية التي قد تفوتها عدادات البايت الأمامية .
• اختبر الحد الأدنى والحد الأقصى للأوامر تحت التقاط الحزمة — الحالات التي يُطلب فيها من الوكيل عدم قراءة الملفات ضرورية للكشف عن تسريب يتجاوز نافذة السياق .
• قم بتشغيل ثلاثة حالات أوامر على الأقل: (1) "رد بـ'حسناً'، لا تقرأ أي ملفات"، (2) اقرأ ملفاً واحداً محدداً، (3) افحص لغة المشروع — ثم قارن البايتات لكل نقطة نهاية .