Матеріал автора має інформаційний характер і виражає лише його думку.
AI-асистенти для програмування стали буденним інструментом: вони читають ваш код, підказують рішення, виправляють помилки й навіть самостійно вносять зміни. Але що саме вони при цьому відправляють на сервери своїх творців? Для більшості розробників це «чорна скринька»: ти бачиш відповідь у терміналі, але не бачиш, які саме дані поїхали в хмару. Історія з Grok Build від компанії xAI показала, що відповідь на це питання може бути дуже неприємною: інструмент завантажував у хмару весь ваш репозиторій, навіть ті файли, які жодного разу не відкривав, і навіть тоді, коли користувач намагався це заборонити.
Розберемо докладно, що сталося, чому це важливо навіть для тих, хто не користується саме Grok, і що кожному розробнику варто зробити вже сьогодні.
Коротко: суть історії за 30 секунд
- AI-асистент Grok Build (CLI від xAI) архівував увесь Git-репозиторій і відправляв його в хмарне сховище.
- У хмару летіли навіть файли, які інструмент не читав, історія комітів, приватний код і незамасковані секрети.
- Перемикач «Improve the model» стосувався лише згоди на навчання моделі, а не факту передачі коду, і його вимкнення не зупиняло завантаження.
- На репозиторії 12 ГБ у сховище пішло понад 5 ГіБ, тобто фактично весь проєкт.
- Після розголосу xAI тихо вимкнула механізм серверним прапорцем, без офіційної заяви про обсяг, зберігання чи видалення даних.
Що таке AI-асистенти для коду і чому вони бачать так багато
Щоб зрозуміти масштаб проблеми, варто згадати, як узагалі працюють такі інструменти. AI-асистент на кшталт Grok Build, Claude Code, Codex чи Gemini CLI, це програма, яку ви запускаєте у своєму проєкті. Щоб допомогти, їй потрібен контекст: назви файлів, фрагменти коду, структура проєкту, іноді історія змін.
Тут і криється ключове питання приватності: скільки саме контексту інструмент забирає? Є два принципово різні підходи:
- Мінімально необхідний. Інструмент читає й відправляє лише ті файли або фрагменти, які потрібні для конкретного запиту. Що менше даних залишає машину, то краще.
- «Забрати все про запас». Інструмент завантажує весь проєкт цілком, щоб «мати повний контекст», незалежно від того, що ви просили.
Grok Build, як з'ясувалося, діяв за другим сценарієм, причому робив це неочевидно для користувача.
Що сталося: хронологія
12 липня 2026 року дослідник безпеки під ніком Cereblab опублікував розбір роботи Grok Build версії 0.2.93. Замість того щоб вірити маркетингу, він зробив те, що й має робити дослідник безпеки: перехопив і проаналізував мережевий трафік інструмента, щоб побачити, які дані і куди він насправді надсилає.
Результат виявився показовим. Grok Build не просто читав потрібні для запиту файли, він архівував весь Git-репозиторій у так званий Git-бандл і відправляв його в хмарне сховище. Тобто досить було під'єднати інструмент до проєкту, щоб уся кодова база, з усією історією змін, поїхала на чужі сервери.
Після того як розбір поширився на Reddit і в X (колишній Twitter), тема набула широкого розголосу, і xAI відреагувала, але, як побачимо нижче, дуже тихо.
Технічний розбір: що таке Git-бандл і як працювало завантаження
Git-бандл (git bundle), це один файл, у який пакується весь репозиторій разом з історією комітів, гілками й тегами. По суті, це «зліпок» усього проєкту, який можна перенести куди завгодно. Зручний механізм для резервних копій, але вкрай небезпечний, якщо він тихо їде на сторонній сервер.
Дослідник помітив, що трафік інструмента йшов двома різними каналами:
- Канал моделі (запит до AI і відповідь), умовно, ендпоінт для «розмови» з моделлю.
- Канал сховища, окремий ендпоінт, куди вивантажувався той самий Git-бандл.
Саме розділення на два канали й робило проблему непомітною: користувач бачив звичайну роботу асистента, тоді як паралельно, іншим маршрутом, у хмару перекачувався весь проєкт.
Пастка в налаштуваннях: коли «вимкнено» не означає вимкнено
Найтривожніше в цій історії, це не сам факт завантаження, а те, як користувача фактично вводили в оману інтерфейсом налаштувань. Це класичний приклад так званого «темного патерну» (dark pattern), коли дизайн підштовхує до хибного розуміння.
Grok Build має перемикач «Improve the model» («покращувати модель»). Практично будь-який розробник прочитає це як «не збирати й не використовувати мої дані» і вимкне його. Логічне очікування: код не піде нікуди.
Але цей тумблер керував лише згодою на навчання моделі, а не тим, чи залишає код вашу машину взагалі. Cereblab перевірив: навіть після вимкнення цієї опції сервер продовжував відповідати trace_upload_enabled: true, і передача репозиторію відбувалася як зазвичай.
Різниця тонка, але критична:
- «Не використовувати мої дані для навчання», це про те, чи побачить ваш код чужа нейромережа під час тренування.
- «Не передавати мої дані», це про те, чи взагалі код залишає ваш комп'ютер.
Користувач вимикав перше, вважаючи, що вимикає друге. А друге продовжувало працювати.
Що саме витікало
За даними дослідження, у сховище потрапляли:
- Файли, які агент навіть не читав для виконання завдання.
- Повна історія комітів проєкту (а це часто вся еволюція продукту).
- Приватний, закритий код, зокрема комерційна таємниця.
- Незамасковані секрети: паролі, API-ключі, SSH-ключі, токени доступу.
Останній пункт особливо болючий. Багато розробників, попри всі рекомендації, тримають ключі й паролі прямо в коді або у файлах конфігурації. Якщо такий репозиторій цілком їде на сторонній сервер, це вже не просто витік коду, це потенційна компрометація доступів до баз даних, хмар, платіжних систем.
Масштаб проблеми в цифрах
Цифри показують різницю між «прочитати потрібне» і «забрати все». На репозиторії розміром 12 ГБ, який модель навіть повністю не читала:
- Канал самої моделі (запит-відповідь) отримав близько 192 КБ трафіку.
- Канал сховища перекачав 5.10 ГіБ, тобто фактично весь проєкт.
Різниця, у десятки тисяч разів. Дані, за інформацією дослідників, вивантажувалися у бакет Google Cloud. Тобто йшлося не про якісь службові метадані, а про повноцінне резервне копіювання вашого коду туди, куди ви його свідомо не відправляли.
Як роблять інші інструменти
Для порівняння, інші популярні AI-асистенти для коду поводяться інакше. Claude Code, Codex і Gemini CLI передають лише ті файли або фрагменти, які потрібні для виконання конкретного запиту, а не копію всього проєкту.
Це принципова різниця у філософії: мінімально необхідні дані проти «завантажити все про запас». Вона не робить інші інструменти автоматично «ідеальними», будь-який хмарний асистент щось відправляє на сервери, але сам обсяг і прозорість передачі критично відрізняються. Урок не в тому, що «Grok поганий, а решта хороші», а в тому, що поведінку конкретного інструмента треба перевіряти, а не вгадувати за назвою тумблера.
Реакція xAI
Після розголосу xAI відключила цей механізм, але зробила це показово тихо. Подальші тести Cereblab виявили цікаву деталь: публічно додана команда /privacy насправді не була тим, що зупинило завантаження. Реальним «вимикачем» став окремий серверний прапорець disable_codebase_upload: true.
Іншими словами, проблему прибрали на боці сервера, а не дали користувачеві надійного контролю у самому інструменті. При цьому компанія не зробила офіційної заяви про:
- обсяг уже зібраних даних;
- терміни їх зберігання;
- можливість видалення на запит користувача.
Розробники, чий код уже поїхав у хмару, залишилися без відповідей на найважливіші питання.
Юридичний і комплаєнс-вимір (особливо у Швейцарії)
Для тих, хто працює у Швейцарії чи ЄС, ця історія, це не лише про технічну гігієну, а й про закон і контракти.
- Захист даних. Якщо в репозиторії є персональні дані (клієнтів, користувачів), їх неконтрольована передача третій стороні може порушувати швейцарський nFADP (новий Закон про захист даних) та європейський GDPR.
- Комерційна таємниця й NDA. Багато трудових договорів і угод з клієнтами прямо забороняють передавати код і документацію третім особам без дозволу. Використання інструмента, який тихо вивантажує весь проєкт, може стати порушенням NDA.
- Клієнтський код. Якщо ви фрилансер або підрядник, код часто належить клієнту. Витік такого коду, це вже питання вашої відповідальності перед замовником.
Висновок для компаній простий: вибір AI-інструментів для розробки має проходити не лише через оцінку зручності, а й через юридичну та безпекову перевірку.
Що робити розробнику: покроково
Ця історія, це нагадування, що зручність AI-інструментів має ціну, і платити її можна власними даними. Кілька практичних кроків:
- Розрізняйте «навчання» і «передачу даних». Тумблер про покращення моделі не гарантує, що код не залишає машину. Шукайте в документації та політиці приватності саме розділ про передачу й зберігання даних.
- Не тримайте секрети в коді. Паролі, ключі й токени виносьте у змінні середовища або менеджери секретів (наприклад, .env файли поза Git, спеціалізовані сховища). Додавайте чутливі файли в .gitignore. Тоді навіть у разі витоку найцінніше не постраждає.
- Регулярно ротуйте секрети. Якщо є підозра, що ключі могли витекти, згенеруйте нові й відкличте старі. Це базова гігієна, а не паніка.
- Перевіряйте мережеву поведінку. Для чутливих проєктів варто хоча б раз подивитися, куди і скільки даних відправляє інструмент, за допомогою проксі чи мережевого монітора. Різкий стрибок вихідного трафіку, це сигнал.
- Ізолюйте чутливі проєкти. Не запускайте невідомі AI-асистенти в репозиторіях з комерційною таємницею чи персональними даними. Спочатку протестуйте інструмент на «порожньому» проєкті.
- Розгляньте локальні або self-hosted моделі. Для по-справжньому чутливого коду існують рішення, які працюють без відправлення даних у чужу хмару.
- Оновлюйте інструменти й стежте за новинами безпеки. Уразливості й сумнівні механізми часто виправляють тихо, без гучних оголошень, тому корисно читати профільні джерела.
Що робити, якщо ви вже користувалися Grok Build
- Виходьте з припущення, що вміст ваших репозиторіїв міг бути завантажений, і дійте відповідно.
- Терміново відкличте й перевипустіть усі секрети, які могли бути в коді: API-ключі, паролі, SSH- і доступові токени.
- Перевірте логи доступу до сервісів, ключі яких зберігалися в репозиторії, на предмет підозрілої активності.
- Якщо йдеться про клієнтський код або дані під NDA, повідомте відповідальних осіб і юридичний відділ, приховування може коштувати дорожче за сам інцидент.
Ширший контекст: це не перший і не останній випадок
Проблема довіри до AI-інструментів ширша за один Grok Build. У міру того як асистенти отримують дедалі глибший доступ до наших файлів, терміналів і навіть облікових записів, зростає й ризик, що зручність переможе обережність. Історія показова саме тим, що йшлося не про якийсь підпільний вірус, а про офіційний продукт великої компанії. Це означає, що «бренд» і «популярність» не є гарантією приватності, перевіряти треба поведінку, а не репутацію.
Часті запитання (FAQ)
Чи означає це, що всі AI-асистенти небезпечні? Ні. Усі хмарні інструменти щось відправляють на сервери, але обсяг і прозорість критично різняться. Проблема Grok Build, це поєднання надмірного завантаження й оманливих налаштувань.
Я вимкнув «Improve the model», хіба цього не досить? У випадку Grok Build, ні: ця опція стосувалася навчання моделі, а не факту передачі коду. Завжди перевіряйте окремо, чи є контроль саме над передачею даних.
Чи можна повністю уникнути ризику? Повністю, лише офлайн або на self-hosted рішеннях. Для більшості завдань достатньо базової гігієни: не тримати секрети в коді, ізолювати чутливі проєкти, читати політику приватності.
Глосарій
- CLI (Command Line Interface), інструмент, яким керують через командний рядок термінала.
- Репозиторій (repo), сховище коду проєкту разом з історією змін.
- Git-бандл, один файл, що містить увесь репозиторій з історією; зручний для перенесення, небезпечний при тихій передачі.
- Коміт (commit), зафіксована зміна в історії проєкту.
- Секрети, паролі, API-ключі, токени, SSH-ключі, усе, що дає доступ до систем.
- Бакет (bucket), контейнер для зберігання файлів у хмарі (наприклад, у Google Cloud).
Висновок
Grok Build не був зловмисним вірусом, це офіційний інструмент великої компанії. І саме тому випадок показовий: межа між «допомагаю тобі писати код» і «забираю весь твій код собі» може проходити всередині одного застосунку, а керувати нею користувач фактично не міг. Головний урок простий: перш ніж дати AI-інструменту доступ до проєкту, з'ясуйте, що саме він відправляє на сервери і чи справді ви можете це зупинити. Зручність не має коштувати вам контролю над власним кодом.