Разбор трафика: CLI-инструмент Grok от xAI отправляет на серверы компании содержимое файлов и весь репозиторий целиком

Исследователь под ником cereblab, называющий себя независимым проверяющим безопасности ИИ, опубликовал воспроизводимый разбор сетевого трафика официального CLI-инструмента для написания кода Grok Build от xAI (бинарник grok версии 0.2.93, macOS, июль 2026). Методика: локальный MITM-прокси mitmproxy на собственной машине, тестовый репозиторий с «канареечными» фиктивными секретами вместо реальных учётных данных, все выводы подкреплены сохранёнными артефактами (эндпоинт, HTTP-метод, код ответа, размер в байтах, SHA-256-хеши) и командами для повтора.

Первая находка: когда Grok читает файл, в том числе файл с секретами вроде .env или secrets.env, его содержимое дословно и без какой-либо редакции уходит на серверы xAI сразу по двум каналам. Первый, тело живого обращения к модели (POST /v1/responses): в перехваченном 48-килобайтном запросе секреты API_KEY и DB_PASSWORD присутствуют в открытом виде. Второй, архив session_state, который загружается и принимается (HTTP 200) через POST /v1/storage и оседает в бакете Google Cloud Storage grok-code-session-traces; при распаковке перехваченного архива те же секреты обнаруживаются и там. Контрольный запуск с промптом «не читай никакие файлы» подтвердил: незапрошенный файл в тело обращения к модели не попадает, утечка привязана именно к тем файлам, которые агент реально прочитал.

Вторая находка куда серьёзнее: независимо от того, что именно прочитал агент, инструмент заливает весь репозиторий целиком, все отслеживаемые git файлы плюс историю коммитов, отдельным каналом через POST /v1/storage. Это доказано напрямую: на промпте «ответь ровно OK, не открывай никакие файлы» Grok всё равно выгрузил весь репозиторий в виде git bundle; после клонирования этого бандла в нём обнаружился файл src/_probe/never_read_canary.txt с уникальной меткой, который агенту явно запретили открывать, вместе с полной историей git. Масштаб подтверждён на репозитории объёмом 12 ГБ: за время перехвата через /v1/storage ушло 5,10 ГиБ данных семьюдесятью тремя чанками примерно по 75 МБ, и ни один запрос не завершился ошибкой, тогда как канал живого диалога с моделью за то же время передал всего 192 КБ, разница примерно в 27 800 раз. Поскольку модель физически не могла «увидеть» гигабайты через 192-килобайтный канал, а данные всё равно ушли, это однозначно снимок всего рабочего каталога, а не то, что агент реально читал. Дополнительно найденный на диске манифест загрузки перечисляет тот же никогда не читанный файл среди реальных исходников кодовой базы, присваивая каждому файлу адрес назначения в том же GCS-бакете.

Третья находка касается места хранения и настроек: данные складываются не в AWS S3, а в бакет Google Cloud Storage grok-code-session-traces, имя зашито прямо в бинарнике и в перехваченном metadata.json. Автор не нашёл упоминания этого механизма в установочных материалах и быстром старте CLI (не проводя при этом полного аудита документации); механизм включён по умолчанию, а отключение настройки «Improve the model» его не выключает, эндпоинт /v1/settings по-прежнему возвращает trace_upload_enabled: true.

Автор прямо оговаривает границы доказанного: исследование не доказывает, что xAI действительно обучает модели на этих данных, это отдельный вопрос политики компании, вынесенный за скобки. Доказаны только сами факты передачи, приёма серверами (код 200) и сохранения в постоянное хранилище. Также отдельно отмечено: не проверено, распространяется ли утечка на файлы, добавленные в .gitignore, в тестах файл с секретами был отслеживаемым git-файлом.

Ключевые факты

CLI-инструмент Grok Build (xAI) пересылает на серверы компании содержимое прочитанных агентом файлов, включая .env с секретами, дословно и без какой-либо редакции, сразу по двум каналам: в теле обращения к модели и в архиве, загружаемом в облачное хранилище.
Независимо от того, что прочитал агент, инструмент заливает весь репозиторий целиком, все файлы плюс git-история, в виде git bundle; на промпте «не читай файлы» в загрузку всё равно попал файл, который агенту явно запретили открывать.
На тестовом репозитории объёмом 12 ГБ через канал загрузки ушло 5,10 ГиБ данных, тогда как через канал диалога с моделью, только 192 КБ: разница примерно в 27 800 раз доказывает, что загружается снимок всей кодовой базы, а не только прочитанное.
Данные оседают в бакете Google Cloud Storage grok-code-session-traces; механизм включён по умолчанию, не упомянут в документации по установке, и отключение настройки «Improve the model» его не отключает.
Исследование не доказывает, что xAI использует эти данные для обучения моделей, это отдельный вопрос политики компании; доказаны только сами факты передачи, приёма и хранения.

Почему это важно

Кодовые ИИ-агенты по своей природе читают чувствительный код и нередко наталкиваются на файлы с секретами. Разбор показывает, что официальный инструмент крупной ИИ-компании не просто передаёт модели то, что явно нужно для задачи, а тихо копирует в облако весь рабочий каталог целиком, включая файлы, которые агент никогда не открывал, причём это не описано в документации и не отключается штатной настройкой приватности.

Кому это важно

Разработчикам и командам, уже использующим Grok Build или рассматривающим его для работы с проприетарным или содержащим секреты кодом; специалистам по безопасности, оценивающим ИИ-инструменты для разработки перед внедрением в компании; всем, кто хранит ключи и пароли в .env-файлах внутри репозитория, к которому имеет доступ ИИ-агент.

Как это применить

Не хранить реальные секреты в файлах, которые физически лежат в рабочем каталоге, доступном агенту, выносить их в отдельные менеджеры секретов или переменные окружения вне репозитория. Перед подключением любого ИИ-CLI к чувствительному коду стоит самостоятельно проверить его сетевой трафик через прокси вроде mitmproxy, как это сделал автор разбора. Компаниям с обязательствами по защите данных клиентов стоит явно уточнить у xAI политику хранения и использования session_state-архивов, а не полагаться на переключатель «Improve the model», который, по данным разбора, ничего не меняет.

Можно ли доверять

Разбор методологически сильный: автор перехватывал только собственный трафик на собственной машине, использовал заведомо фиктивные «канареечные» секреты, приводит SHA-256-хеши артефактов и точные команды для воспроизведения, а также честно указывает, какие наблюдения были сделаны вживую, но не сохранены как файлы, и что именно не доказано (например, поведение с .gitignore-файлами и факт использования данных для обучения). Публикация не рецензируется независимо и размещена автором самостоятельно, но воспроизводимость методики позволяет любому желающему перепроверить выводы.

Риски и подводные камни

Секреты и проприетарный код могут попадать за пределы компании без её ведома, даже если разработчик ни разу не спросил у агента ничего о конкретном файле. Настройка, которая по названию должна отключать передачу данных, на деле не отключает загрузку в хранилище. Остаётся открытым вопрос, распространяется ли утечка на файлы из .gitignore и как долго и с какой целью xAI хранит загруженные архивы, для компаний с юридическими обязательствами по защите данных это может обернуться риском несоответствия требованиям.

«Ничто из этого не доказывает, что xAI обучает модели на этих данных, это отдельный вопрос политики компании. Доказаны лишь сами факты передачи, приёма и хранения.»

— cereblab, независимый исследователь безопасности ИИ, автор разбора