Grok Build отправлял приватные репозитории в облако: что случилось с приватностью ИИ-инструмента xAI

CLI-инструмент Grok Build от xAI без ведома пользователей выгружал их приватные репозитории в облако, об этом 14 июля 2026 года написал The Register. Проблему вскрыл ИИ-безопасник под ником Cereblab, опубликовавший разбор в воскресенье. После огласки xAI внесла серверное изменение и остановила выгрузку, а Илон Маск публично пообещал полностью удалить все ранее загруженные данные.

Когда Grok Build читал или обрабатывал файл, его содержимое уходило в бакет Google Cloud Storage без редактирования. Секреты никто не вырезал. Инструмент упаковывал репозитории целиком в виде Git-бандлов и грузил их на серверы, вместо того чтобы отправлять только те файлы, что нужны для ответа на запрос.

Как Grok Build отправлял приватные репозитории в облако

Cereblab поставил чистый эксперимент. Он дал CLI безобидный промпт: ответить «OK», и явно запретил открывать любые файлы. Grok Build всё равно выгрузил весь репозиторий вместе с полной Git-историей, а в ней лежали секреты, удалённые ещё несколько месяцев назад. Результат воспроизвели на отдельном репозитории.

Почему Git-история делает утечку опаснее

Из-за Git-истории проблема серьёзнее, чем кажется. Удаление файла в текущем коммите не стирает его из истории: старые ключи и токены остаются доступными, пока историю не переписали через инструменты вроде git filter-repo и не ротировали сами секреты. Grok Build отправлял в облако именно этот пласт данных.

Дошло до SSH-ключей и паролей

Один из пользователей сообщил о худшем: у него был открыт и выгружен весь домашний каталог, включая SSH-ключи и базы менеджеров паролей.

Чем это отличалось от Claude Code, Gemini и Codex

Удержание данных у Grok Build выходило далеко за рамки других CLI. По данным исследователя, Claude Code, Gemini и Codex открывают отдельные файлы, а не целые приватные репозитории с их Git-историей. Grok Build же грузил всё разом: с историей, ветками, следами давно удалённого кода.

Выгрузку остановил не пользовательский переключатель приватности, который рекомендовала сама компания, а «тихий» глобальный серверный флаг disable_codebase_upload: true. Когда разработчики выставили его, Grok Build перестал передавать репозитории на серверы. Значит, корень проблемы в неверной настройке по умолчанию, а не в выборе пользователя.

Обещание Маска и просьба «делиться дальше»

xAI заявила, что для клиентов с включённым режимом нулевого удержания данных (ZDR) «код и данные никогда не удерживаются». Остальным предложили команду /privacy в CLI, которая отключает удержание и удаляет ранее синхронизированные данные. Заверения повторяли технические сотрудники Andrew Milich и Jason Ginsberg.

Маск высказался прямо: «Все пользовательские данные, загруженные до этого момента, будут полностью и бесповоротно удалены… Ничего абсолютно не останется». Правда, в отдельном посте он попросил пользователей продолжать делиться данными, поскольку сохранение «части» помогает с отладкой. Слова коллеги он подтвердил фирменным «true».

Почему исследователь не согласен

Cereblab с таким решением не согласен. По его словам, /privacy отключает удержание в рамках сессии, но утечку устранил не он, а глобальный флаг disable_codebase_upload, работающий независимо от того, включил пользователь опцию или нет. Главный тезис исследователя: правильное значение по умолчанию это «выключено», и разработчик не должен запускать opt-out после каждой сессии, чтобы его код не утекал на чужие серверы.

Выводы: приватность ИИ-инструмента по умолчанию

Если вы из России и СНГ работаете с ИИ-инструментами для кода, оценивайте их не по наличию галочки «отключить сбор данных», а по тому, что включено по умолчанию. И держите секреты вне репозиториев: ротация ключей и переписанная история надёжнее, чем «удалить файл». Дополнительный слой контроля над трафиком и данными даёт Sigma.

Источники

The Register, Grok Build выгружал целые репозитории в облако, Маск пообещал их удалить