Кодиращият CLI инструмент Grok Build на xAI е качвал цели Git хранилища, включително пълната история на комитите, в кофа за съхранение в Google Cloud Storage, управлявана от xAI, вместо само файловете, необходими за конкретната задача.
Изследовател, публикуващ под псевдонима cereblab, тествайки версия 0.2.93, е прихванал едно от тези качвания, клонирал е git архива (bundle) от прихванатия запит и е възстановил файл, който изрично е бил инструктиран да не отваря.
Качването се е извършвало по отделен канал от самия модел. При хранилище от 12 GB с файлове, които моделът никога не е чел, трафикът към /v1/responses е бил около 192 KB, докато каналът за съхранение към /v1/storage е прехвърлил 5.10 GiB – приблизително 27 800 пъти повече данни от необходимото.
Когато Grok чете файл, съдържанието му отива в модела, като по този начин проследяван .env файл е бил изпратен нередактиран, заедно с тестови API ключове и пароли. Същото съдържание е попаднало и в архива session_state, изпратен към хранилището.
Опцията „Improve the model“ (Подобри модела) не е спряла това поведение. При изключена опция Grok все още е качвал хранилището, тъй като сървърният отговор е съдържал параметър trace_upload_enabled: true. Тази настройка управлява дали данните ви обучават модела, а не дали кодът напуска машината ви.
В сравнение с други инструменти като Claude Code и Codex, те не са изпращали архив на хранилището. На 13 юли същата версия 0.2.93 на Grok е спряла да прави заявки за съхранение, след като сървърът е променил флаговете на disable_codebase_upload: true и trace_upload_enabled: false – сървърна промяна, а не фикс в клиента.
От xAI коментираха в мрежата X, че корпоративните екипи с политика за нулево запазване на данни (ZDR) не се засягат, а потребителите могат да изпълнят командата /privacy в CLI, за да деактивират запазването и да изтрият синхронизираните данни. Препоръчва се на всички, ползвали инструмента, да ротират своите акаунти и ключове, които са били част от историята на Git или прочетени от инструмента.