Perilaku Pengambilan Data yang Bertentangan dengan Klaim 'Local-First'

Peneliti mengidentifikasi dua jalur data yang berbeda secara material yang meninggalkan mesin pengembang :

• Saluran model-turn (POST /v1/responses): file yang dibuka agen diserialkan ke dalam permintaan model. Ini adalah perilaku yang diharapkan dari agen coding berbasis cloud.
• Saluran penyimpanan (POST /v1/storage): seluruh repositori secara independen dikemas sebagai git bundle dan diunggah dalam potongan ~75 MB ke bucket Google Cloud Storage bernama grok-code-session-traces .

Perbedaan skala membuktikan bahwa unggahan tersebut tidak didorong oleh apa yang dibaca agen. Pada repositori uji coba sebesar 12 GB, saluran penyimpanan memindahkan 5,10 GiB dalam 73 potongan (semua HTTP 200), sementara saluran model-turn hanya memindahkan 192 KB — rasio ~27.800× . Bahkan dengan perintah 'jawab OK, jangan baca file apa pun', alat tersebut tetap mengunggah seluruh repositori sebagai git bundle; meng-kloning bundle yang ditangkap memulihkan file (src/_probe/never_read_canary.txt) yang secara eksplisit diperintahkan untuk tidak dibuka, bersama dengan seluruh riwayat commit Git .

Jenis Rahasia dan File yang Dikirim Tanpa Redaksi

• File .env yang berisi kunci API, kata sandi database, dan kredensial lainnya dikirimkan secara verbatim, tanpa ditutupi atau direaksi melalui kedua saluran . Dalam pengujian terkontrol, file sebesar 48 KB berisi kredensial database dan kunci API muncul dalam teks biasa di badan permintaan .
• Setiap file yang terlacak di repositori, plus riwayat Git lengkap (semua commit, cabang, tag) dikemas dan diunggah . Ini berarti rahasia yang sudah dihapus berbulan-bulan lalu tetapi kemudian diganti mungkin masih ada dalam data yang diunggah.
• Mekanisme unggahan diidentifikasi sebagai Rust crate pihak pertama (xai-data-collector) yang ada di dalam biner, dengan jalur sumber seperti crates/codegen/xai-data-collector/src/gcs.rs dan crates/codegen/xai-grok-shell/src/upload/ .
• Pada basis kode nyata sebesar 12 GB berisi file acak yang tidak pernah dibaca, endpoint penyimpanan menerima unggahan tanpa penolakan berbasis ukuran; satu-satunya respons non-200 adalah kesalahan kuota penggunaan model (402/429), bukan kegagalan penyimpanan .

Tombol Privasi Tidak Berfungsi

Peneliti menguji tombol privasi 'Improve the model' dan menemukan bahwa tombol tersebut tidak menghentikan unggahan .

• Setelah menonaktifkan tombol dan memulai ulang, endpoint pengaturan server tetap mengembalikan trace_upload_enabled: true .
• Saluran penyimpanan terus menerima unggahan git bundle yang dipotong-potong dengan respons HTTP 200 .
• Opsi konfigurasi disable_codebase_upload=true ada di pengaturan harness, tetapi hubungannya dengan perilaku sisi server tidak terdokumentasi, dan pengujian peneliti menunjukkan server tidak menghormati preferensi sisi klien .

Rekomendasi Mitigasi untuk Pengembang yang Terdampak

Peneliti asli dan outlet analisis selanjutnya merekomendasikan hal berikut :

Tindakan segera untuk tim yang telah menggunakan Grok Build CLI di repositori pribadi:

• Ganti semua kredensial yang pernah ada di file .env, file konfigurasi, atau riwayat git dalam repositori yang digunakan dengan Grok Build, karena mungkin telah dikirim dan disimpan di bucket GCS grok-code-session-traces .
• Audit riwayat Git untuk rahasia yang mungkin pernah ada di commit masa lalu, karena CLI mengirimkan riwayat commit lengkap .
• Asumsikan data telah disimpan, tidak hanya dikirim — server mengembalikan HTTP 200 pada semua permintaan penyimpanan, mengonfirmasi penerimaan .
• Tanyakan ke xAI apakah bucket telah dihapus, kontrol akses apa yang ada, dan apakah Perjanjian Pemrosesan Data mencakupnya (tidak ada yang diterbitkan saat pengungkapan) .

Mitigasi arsitektural untuk agen coding apa pun:

• Jalankan agen dalam kontainer/VM hanya dengan direktori tugas yang dipasang, tanpa direktori rumah, tanpa agen SSH, tanpa soket Docker, dan tanpa direktori kredensial cloud yang diekspos .
• Terapkan kontrol lalu lintas keluar (egress): izinkan endpoint inferensi model dan host autentikasi, tetapi tolak unggahan penyimpanan objek generik langsung. Beri peringatan pada transfer yang melebihi 100 MB .
• Gunakan full-host packet capture, DNS logging, dan endpoint network telemetry untuk mendeteksi unggahan oleh proses koordinator latar belakang yang mungkin terlewatkan oleh penghitung byte latar depan .
• Uji perintah minimum dan maksimum di bawah wire capture — kasus di mana agen diperintahkan untuk tidak membaca file sangat penting untuk mendeteksi pengambilan data di luar jendela konteks .
• Jalankan setidaknya tiga kasus perintah: (1) 'jawab OK, jangan baca file apa pun,' (2) baca satu file tertentu, (3) periksa bahasa proyek — lalu bandingkan byte per endpoint .

Perilaku Pengambilan Data yang Bertentangan dengan Klaim 'Local-First'

Peneliti mengidentifikasi dua jalur data yang berbeda secara material yang meninggalkan mesin pengembang :

• Saluran model-turn (POST /v1/responses): file yang dibuka agen diserialkan ke dalam permintaan model. Ini adalah perilaku yang diharapkan dari agen coding berbasis cloud.
• Saluran penyimpanan (POST /v1/storage): seluruh repositori secara independen dikemas sebagai git bundle dan diunggah dalam potongan ~75 MB ke bucket Google Cloud Storage bernama grok-code-session-traces .

Perbedaan skala membuktikan bahwa unggahan tersebut tidak didorong oleh apa yang dibaca agen. Pada repositori uji coba sebesar 12 GB, saluran penyimpanan memindahkan 5,10 GiB dalam 73 potongan (semua HTTP 200), sementara saluran model-turn hanya memindahkan 192 KB — rasio ~27.800× . Bahkan dengan perintah 'jawab OK, jangan baca file apa pun', alat tersebut tetap mengunggah seluruh repositori sebagai git bundle; meng-kloning bundle yang ditangkap memulihkan file (src/_probe/never_read_canary.txt) yang secara eksplisit diperintahkan untuk tidak dibuka, bersama dengan seluruh riwayat commit Git .

Jenis Rahasia dan File yang Dikirim Tanpa Redaksi

• File .env yang berisi kunci API, kata sandi database, dan kredensial lainnya dikirimkan secara verbatim, tanpa ditutupi atau direaksi melalui kedua saluran . Dalam pengujian terkontrol, file sebesar 48 KB berisi kredensial database dan kunci API muncul dalam teks biasa di badan permintaan .
• Setiap file yang terlacak di repositori, plus riwayat Git lengkap (semua commit, cabang, tag) dikemas dan diunggah . Ini berarti rahasia yang sudah dihapus berbulan-bulan lalu tetapi kemudian diganti mungkin masih ada dalam data yang diunggah.
• Mekanisme unggahan diidentifikasi sebagai Rust crate pihak pertama (xai-data-collector) yang ada di dalam biner, dengan jalur sumber seperti crates/codegen/xai-data-collector/src/gcs.rs dan crates/codegen/xai-grok-shell/src/upload/ .
• Pada basis kode nyata sebesar 12 GB berisi file acak yang tidak pernah dibaca, endpoint penyimpanan menerima unggahan tanpa penolakan berbasis ukuran; satu-satunya respons non-200 adalah kesalahan kuota penggunaan model (402/429), bukan kegagalan penyimpanan .

Tombol Privasi Tidak Berfungsi

Peneliti menguji tombol privasi 'Improve the model' dan menemukan bahwa tombol tersebut tidak menghentikan unggahan .

• Setelah menonaktifkan tombol dan memulai ulang, endpoint pengaturan server tetap mengembalikan trace_upload_enabled: true .
• Saluran penyimpanan terus menerima unggahan git bundle yang dipotong-potong dengan respons HTTP 200 .
• Opsi konfigurasi disable_codebase_upload=true ada di pengaturan harness, tetapi hubungannya dengan perilaku sisi server tidak terdokumentasi, dan pengujian peneliti menunjukkan server tidak menghormati preferensi sisi klien .

Rekomendasi Mitigasi untuk Pengembang yang Terdampak

Peneliti asli dan outlet analisis selanjutnya merekomendasikan hal berikut :

Tindakan segera untuk tim yang telah menggunakan Grok Build CLI di repositori pribadi:

• Ganti semua kredensial yang pernah ada di file .env, file konfigurasi, atau riwayat git dalam repositori yang digunakan dengan Grok Build, karena mungkin telah dikirim dan disimpan di bucket GCS grok-code-session-traces .
• Audit riwayat Git untuk rahasia yang mungkin pernah ada di commit masa lalu, karena CLI mengirimkan riwayat commit lengkap .
• Asumsikan data telah disimpan, tidak hanya dikirim — server mengembalikan HTTP 200 pada semua permintaan penyimpanan, mengonfirmasi penerimaan .
• Tanyakan ke xAI apakah bucket telah dihapus, kontrol akses apa yang ada, dan apakah Perjanjian Pemrosesan Data mencakupnya (tidak ada yang diterbitkan saat pengungkapan) .

Mitigasi arsitektural untuk agen coding apa pun:

• Jalankan agen dalam kontainer/VM hanya dengan direktori tugas yang dipasang, tanpa direktori rumah, tanpa agen SSH, tanpa soket Docker, dan tanpa direktori kredensial cloud yang diekspos .
• Terapkan kontrol lalu lintas keluar (egress): izinkan endpoint inferensi model dan host autentikasi, tetapi tolak unggahan penyimpanan objek generik langsung. Beri peringatan pada transfer yang melebihi 100 MB .
• Gunakan full-host packet capture, DNS logging, dan endpoint network telemetry untuk mendeteksi unggahan oleh proses koordinator latar belakang yang mungkin terlewatkan oleh penghitung byte latar depan .
• Uji perintah minimum dan maksimum di bawah wire capture — kasus di mana agen diperintahkan untuk tidak membaca file sangat penting untuk mendeteksi pengambilan data di luar jendela konteks .
• Jalankan setidaknya tiga kasus perintah: (1) 'jawab OK, jangan baca file apa pun,' (2) baca satu file tertentu, (3) periksa bahasa proyek — lalu bandingkan byte per endpoint .