Grok Build сливал весь твой репозиторий в облако — с историей git и .env. Маск признал, но код аплоада всё ещё в бинарнике

Ты запускал grok внутри рабочего проекта? Тогда открывай менеджер паролей — прямо сейчас. Исследователь под ником cereblab снял дамп трафика Grok Build CLI и показал: инструмент от SpaceXAI грузил весь твой репозиторий целиком — с историей коммитов и .env — в облачный бакет xAI. Не файлы, которые читал агент. Всё.

TL;DR: Grok Build CLI (v0.2.93) отправлял полный git-бандл проекта в бакет grok-code-session-traces на Google Cloud — независимо от того, какие файлы открывал агент. На репозитории в 12 ГБ ушло 5.1 ГиБ, в ~27 800 раз больше, чем нужно было модели. Тумблер приватности не останавливал загрузку. Маркетинг обещал «local-first, код не покидает машину». Маск ответил «True» и пообещал всё стереть. Но код аплоада всё ещё лежит в бинарнике 0.2.99 — его держит выключенным серверный флаг, а не патч.

Что именно нашли в трафике

cereblab прогнал Grok Build через mitmproxy на macOS и увидел два разных канала передачи данных, идущих одновременно. Первый ожидаемый, второй — нет.

Канал модели (POST /v1/responses) несёт содержимое файлов, которые агент реально открыл. Это норма для любого облачного кодинг-ассистента: чтобы ответить, модель должна видеть код. Проблема во втором канале — фоновой выгрузке (POST /v1/storage), которая пакует весь воркспейс в git-бандл и отправляет в GCS-бакет grok-code-session-traces, названный прямо в бинарнике.

Чтобы доказать, что это не «файлы задачи», cereblab поставил ловушку: положил файл src/_probe/never_read_canary.txt с уникальным маркером и дал Grok команду «ничего не делай, ответь OK, файлы не открывай». Агент послушно ответил OK — а бандл всё равно улетел (HTTP 200). Клонирование перехваченного бандла вернуло тот самый файл, который никто не читал, вместе с полной историей коммитов. Тест повторили на втором, независимом репозитории — результат тот же.

Числа добивают: на тестовом репо в 12 ГБ канал модели передал ~192 КБ, а канал хранилища — 5.10 ГиБ, 73 чанка примерно по 75 МБ, каждый с ответом 200. Разрыв в ~27 800 раз. Это не «контекст для ответа», это тотальная выгрузка рабочей папки.

Утекал ли .env с секретами?

Да, .env уходил дословно и без маскировки. cereblab заложил в секретный файл канареечные значения API_KEY и DB_PASSWORD — и они появились в открытом виде и в теле запроса к модели, и в архиве session_state, уехавшем в хранилище.

На реальном коде 48-килобайтный запрос с боевыми ключами и паролями к БД ушёл в открытую в течение секунд после того, как агент прочитал файл. И тут важная деталь про историю git: секрет, который ты закоммитил полгода назад, потом удалил из рабочего дерева, но он остался в истории, — тоже попадал в бандл. Разработчикам, которые трогали Grok Build на живых проектах, security-исследователи советуют ротировать вообще все ключи, до которых инструмент мог дотянуться, а не только те, что были в открытых файлах.

Почему тумблер приватности не помог

Потому что «Improve the model» управляет обучением на твоём коде, а не тем, покидает ли код машину, — это два разных переключателя, и наружу вывели только один. cereblab выключил «Improve the model» — Grok всё равно выгрузил репозиторий, а сервер в ответе /v1/settings продолжал возвращать trace_upload_enabled: true.

Вот это и есть главный подвох. Пользователь видел галочку «не обучать на моих данных», отключал её и думал, что защитил код. А выгрузка в бакет жила своей жизнью под отдельным флагом, которого в интерфейсе не было вовсе. Маркетинговые материалы Grok Build прямым текстом обещали «local-first» и «ничего из твоей кодовой базы не передаётся на серверы xAI во время сессии». Дамп трафика говорит ровно обратное.

Как отреагировал xAI

xAI выключил выгрузку 13 июля — но не патчем, а серверным флагом, и код аплоада остался в бинарнике. На той же версии 0.2.93 запросы к /v1/storage прекратились: сервер начал возвращать disable_codebase_upload: true и trace_upload_enabled: false. cereblab перепроверил шесть раз — ноль загрузок. Разработчик Peter Dedene подтвердил тот же флаг на своём аккаунте, так что это не единичное наблюдение.

Но чинили не клиент, а сервер. В текущем бинарнике (0.2.99) код выгрузки по-прежнему на месте — его держит выключенным один серверный флаг. Это значит, что xAI теоретически может включить всё обратно, не выкатывая ни одного обновления. Именно это добило доверие сильнее самого инцидента.

Официального security-advisory не было — компания отвечала постами в X. Аккаунт SpaceXAI написал, что энтерпрайз на zero data retention ничего не хранил, что использование через API-ключ уважает ZDR, а обычным пользователям предложил команду /privacy в CLI, чтобы отключить хранение и удалить уже синхронизированное. cereblab возразил: /privacy — это посессионный тумблер retention, а не тот переключатель, который реально всё починил. Маск отреагировал одним словом — «True» — и пообещал, что все ранее загруженные данные «будут полностью и бесповоротно удалены, не останется ни байта». В другом посте он же призвал не отключать шэринг совсем, потому что «немного» данных помогает с отладкой.

Подводные камни

• Фикс держится на честном слове сервера. Код выгрузки остался в бинарнике 0.2.99. Пока стоит флаг disable_codebase_upload: true — тихо, но флаг серверный, и вернуть загрузку можно без апдейта, о котором ты узнаешь. Это не исправленная уязвимость, это пауза.
• /privacy — не то, что тебя спасло. Команда отключает retention на сессию и удаляет синхронизированное, но саму дыру закрыл глобальный серверный свитч, а не она. Полагаться на /privacy как на защиту от повторения — ошибка.
• История git — отдельная мина. В бандл попадали удалённые из рабочего дерева, но живые в истории секреты. Если ты хоть раз коммитил ключ и «убрал» его следующим коммитом — считай, что он утёк. Ротация только «текущих» .env тут не спасает.
• Никаких цифр от xAI. Нет отчёта об инциденте, нет срока удаления, нет числа затронутых пользователей, нет способа проверить, что твои данные реально стёрли, и нет объяснения, сколько времени выгрузка работала до находки cereblab.

Альтернативы

Тут «альтернатива» — это другой кодинг-агент с другим отношением к твоим данным. В том же сравнении cereblab прогнал конкурентов на идентичном тесте:

• Claude Code — в холостом тесте не отправил ни одного бандла репозитория, только файлы, которые агент реально открывал. Это всё ещё облачный инструмент, «local-only» про него говорить нельзя, но тотальной выгрузки воркспейса нет.
• OpenAI Codex CLI — так же: бандл всего репо не уходил, в канал шли лишь прочитанные файлы. Плюс у Codex есть режим ZDR через API-ключ, если нужен контроль над retention.
• Локальный агент на open-weight модели (например, Laguna XS или Qwen-Coder через Ollama) — единственный способ, при котором код физически не уходит с машины. Медленнее и слабее флагманов, зато «local-first» тут не слоган, а факт.

Вердикт

Если ты трогал Grok Build на любом непубличном коде — сегодня ротируй все ключи, к которым он мог дотянуться (включая то, что жило в истории git), и выполни /privacy, чтобы удалить синхронизированное. Не потому что паранойя, а потому что дамп трафика показал реальную выгрузку, а компания не дала способа проверить удаление. Ставить Grok Build обратно на боевые репозитории пока не стоит: пока код аплоада лежит в бинарнике под серверным флагом, ты доверяешь не архитектуре, а обещанию не нажимать кнопку. Для xAI это второй звонок за месяц — Grok 4.5 учили на чужих сессиях кодинга в Cursor, теперь весь репозиторий уезжает в бакет. Паттерн виден невооружённым глазом.

Что делать прямо сейчас

1. Ротируй секреты. Все API-ключи, токены и пароли из .env и из любого tracked-файла проектов, где ты запускал Grok Build. Не забудь про то, что лежит в истории коммитов.
2. Выполни /privacy в Grok Build CLI, чтобы отключить retention и удалить уже синхронизированные данные с твоего аккаунта.
3. Проверь, что версия не грузит. Убедись, что сервер отдаёт disable_codebase_upload: true — но не считай это гарантией на будущее.
4. Перенеси боевые проекты на агент, который не выгружает весь воркспейс: Claude Code или Codex CLI на идентичном тесте бандл репо не слали.
5. Читай дамп сам. Разбор cereblab воспроизводимый, с SHA-256 артефактов — оригинальный gist и подробности у The Verge и The Hacker News.