CLI-інструмент Grok Build від xAI, призначений для допомоги у написанні коду, за даними дослідника, завантажував у хмарне сховище xAI не лише файли, необхідні для виконання завдання, а цілі Git-репозиторії разом із повною історією комітів. Проблема стосувалася щонайменше версії 0.2.93 і потенційно могла торкатися будь-якого розробника, який використовував інструмент до 13 липня. При цьому користувацьке налаштування відмови від навчання моделі не зупиняло передавання даних. Усім, хто працював із Grok Build, рекомендується негайно ротувати будь-які секрети, які могли міститися у відстежуваних файлах або в історії комітів.
Що показав аналіз мережевого трафіку
Дослідник, який публікується під псевдонімом cereblab, провів детальний аналіз мережевого трафіку Grok Build версії 0.2.93. Інструмент використовував два окремі канали передавання даних: один — для взаємодії з мовною моделлю через ендпоінт /v1/responses, другий — для завантаження даних у сховище через /v1/storage.
Масштаб розбіжності між цими каналами показовий. На репозиторії розміром 12 ГБ, файли якого модель не читала, трафік до моделі склав близько 192 КБ, тоді як на канал сховища пішло 5,10 ГіБ — різниця приблизно в 27 800 разів. Завантаження виконувалося 73 фрагментами по ~75 МБ, кожен з яких отримував відповідь HTTP 200. Обсяг завантаження, як повідомляється, масштабувався пропорційно до розміру репозиторію.
Цільове сховище — бакет grok-code-session-traces у Google Cloud Storage — було ідентифіковано як у бінарному файлі інструменту, так і в проміжному файлі metadata.json, що містив шляхи на кшталт gs://grok-code-session-traces/.
Канарейковий тест і проблема секретів
Для підтвердження факту передавання дослідник розмістив у репозиторії файл src/_probe/never_read_canary.txt з унікальним маркером і прямо вказав агенту не відкривати цей файл. Після перехоплення завантаженого бандла та його клонування канарейковий файл був відновлений дослівно разом із повною історією комітів. Тест був відтворений на другому, не пов’язаному репозиторії з аналогічним результатом.
Окрема проблема стосувалася обробки секретів. Коли Grok читав відстежуваний файл .env у межах завдання, його вміст — включно з тестовими значеннями API_KEY і DB_PASSWORD — передавався в модельний контекст без будь-якого редагування і додатково зберігався в архіві session_state, який надсилався в сховище. Секрети в тесті були підставними, але сам механізм — надсилання та збереження облікових даних без фільтрації — становить системний ризик.
Важливо: дослідження фіксує факт передавання, приймання та збереження даних, але не стверджує, що xAI використовувала код для навчання моделі або що співробітники компанії мали до нього доступ. Також зазначається, що файли з .gitignore, які ніколи не потрапляли до комітів, до бандла не включалися.
Налаштування приватності працювало не так, як очікувалося
Ключовий аспект інциденту — поведінка користувацьких налаштувань. За даними дослідника, за вимкненої опції «Improve the model» інструмент продовжував завантажувати репозиторій, а відповідь сервера на запит /v1/settings як і раніше містила trace_upload_enabled: true. Це означає, що перемикач керував лише використанням даних для навчання моделі, але не контролював сам факт надсилання коду з машини користувача. Два різні механізми — передавання даних і їх використання для навчання — були розділені, але користувач мав змогу керувати лише другим.
Порівняння з конкурентами
У порівняльному аналізі, проведеному тим самим дослідником, Claude Code і Codex не надсилали бандли репозиторіїв. Gemini не надсилав бандл у тесті без активного завдання, хоча тест із реальним завданням не був завершений через вичерпання квоти. Grok Build виявився єдиним інструментом, що виконував масове завантаження робочого простору. Водночас усі хмарні інструменти для роботи з кодом надсилають файли, які вони відкривають, — повністю локальна модель роботи до них не застосовна.
Реакція xAI та поточний статус
13 липня той самий бінарний файл версії 0.2.93 припинив звернення до /v1/storage. Дослідник провів шість повторних тестів — жодного завантаження в сховище. Сервер почав повертати disable_codebase_upload: true і trace_upload_enabled: false. Оскільки клієнт залишався на тій самій версії, це було серверне блокування, а не оновлення застосунку. Розробник Пітер Дедене підтвердив аналогічну зміну прапорців у своєму акаунті.
Компанія xAI відреагувала через публікації в X, а не через формальне повідомлення з безпеки. Акаунт @SpaceXAI повідомив, що корпоративні клієнти з режимом нульового зберігання даних (ZDR) ніколи не піддавалися збереженню коду або трасувань, а індивідуальні користувачі можуть виконати команду /privacy у CLI для вимкнення зберігання та видалення раніше синхронізованих даних. Ілон Маск заявив, що всі раніше завантажені користувацькі дані будуть «повністю й беззастережно видалені», однак це твердження зроблене в соціальній мережі без супровідної технічної документації.
Суттєва деталь: незалежний аналіз версії 0.2.99 показав, що код завантаження як і раніше присутній у бінарному файлі, але деактивований серверним прапорцем. Це означає, що xAI може повторно ввімкнути функціональність без випуску оновлення клієнта.
Рекомендації
- Ротація секретів: замініть усі облікові дані, які Grok Build міг прочитати — вміст відстежуваних файлів, дані з історії комітів, зокрема секрети, які були закомічені, а потім видалені з робочого дерева. Видалення файла з поточної гілки не видаляє його з історії Git.
- Команда /privacy: якщо ви продовжуєте використовувати Grok Build, виконайте
/privacyу CLI для вимкнення зберігання та запиту на видалення раніше синхронізованих даних. - Аудит мережевого трафіку: працюючи з будь-яким хмарним інструментом для роботи з кодом, контролюйте вихідний трафік. Обсяг даних, які інструмент надсилає, має бути співмірним із виконуваним завданням.
- Зберігання секретів: не розміщуйте реальні облікові дані у файлах, що відстежуються Git. Використовуйте менеджери секретів і змінні середовища, які завантажуються із захищених сховищ.
xAI досі не опублікувала формальне повідомлення з безпеки і не відповіла на три ключові запитання: навіщо повні репозиторії завантажувалися за замовчуванням, як довго дані зберігалися і скількох користувачів це зачепило. Код завантаження залишається в бінарному файлі та керується серверним прапорцем, який може бути змінений у будь-який момент. Для розробників, які працювали з Grok Build, пріоритетна дія — ротація всіх секретів, які будь-коли потрапляли у відстежувані файли або історію комітів відповідних репозиторіїв.
