Маск оголосив про відкриття коду Grok Build: розробники можуть локально збирати, загасили пожежу після зливу?

xAI 15 липня відкрила повністю вихідний код термінального програмного агента Grok Build на GitHub: розробники можуть самостійно зібрати (скомпілювати) його в себе локально та покроково перевірити код, не покладаючись більше на хмарні обчислення.
（Передісторія: Grok Build, як з’ясувалося, викрав дані користувача «весь домашній каталог» та таємно завантажив їх у хмару; розробники були в шоці: витекло абсолютно все）
（Додатковий контекст: Маск xAI запустив «Grok Build», кидаючи виклик Claude: до 8 паралельних AI agents, контекстне вікно до 2 млн tokenів）

Зміст

Toggle

• Grok Build — відкрито вихідний код
• Розгорнутий вихідний код, від якого не сховатися витокам
• Поза відкритим кодом, чого ще не вистачає

Маск цього (16) ранку опублікував допис і заявив: SpacexAI повністю оприлюднила вихідний код Grok Build на GitHub, тож розробники можуть самі скомпілювати його локально та перевірити покроково. Але, як виявилося, подарунок був на диво невчасним: Grok Build лише кілька днів тому почали розбирати після витоку даних. Дані користувачів — паролі та ключі — тихо пакували й відправляли в хмару.

Це щирий прояв намірів чи гасіння пожежі?

Grok Build is now open source https://t.co/LbGepmRB3l

— Elon Musk (@elonmusk) July 15, 2026

Grok Build — відкрито вихідний код

Grok Build — це нативний AI-агент для програмування в терміналі, який xAI (також відомий як SpaceXAI) випустив у травні 2026 року. Офіційно заявляють про максимум 8 паралельних AI-агентів, контекстне вікно до 2 млн tokenів; мета — кинути виклик Anthropic Claude Code та Cursor.

Тепер xAI відкрила повний вихідний код Grok Build у проєкті xai-org/grok-build на GitHub: розробники можуть самостійно збирати його локально, змінювати конфігурацію config.toml і запускати виконання з локальним виведенням, не відправляючи дані в хмару xAI.

Цей крок офіційно позиціонують як формальну відповідь на закиди щодо приватності та прозорості з боку зовнішніх сторін. Теоретично, після публікації коду будь-хто зможе сам перевірити, що саме робить інструмент «за лаштунками», і не доведеться покладатися лише на одну сторону — офіційну.

Розгорнутий вихідний код, від якого не сховатися витокам

Нещодавня хвиля обурення розгорілася через версію Grok Build 0.2.93. Один AI дослідник із безпеки виявив, що Grok Build кожного разу, коли читає й обробляє файл, розглядає це як частину запиту на виклик моделі. Всередині інструмента прихована окрема прихована фоновa схема завантаження: це не лише передача локальних файлів, потрібних для виконання задачі, а пакування всієї Git-репозиторії користувача разом із повним набором програмного коду проєкту та історією змін; далі воно пакується у Git bundle та завантажується на простір зберігання SpaceXAI у Google-хмарі. Дані повністю не деідентифіковані.

Наскільки це масштабно? Під час одного практичного тесту з’ясувалося, що для виконання завдання насправді потрібно лише 192 KB даних, тоді як Grok Build завантажив 5.1 GB — у 26 тисяч разів більше, ніж потрібно. Разом із цим було запаковано й відправлено ще журнал операцій, фонові паролі та API-ключі. «Приватні перемикачі», які стверджують, що їх можна вимкнути, за фактом не дали жодного ефекту.

Перший крок xAI був не публічні вибачення, а тихе протиснення виправлення на стороні сервера, щоб заблокувати аномальне завантаження; без публікації повідомлення про безпеку, і в описі оновлення нової версії також не було жодного слова. Лише доки Маск не втрутився особисто: він публічно пообіцяв повністю та назавжди видалити всі раніше завантажені користувацькі дані, без залишення резервних копій. Для користувачів, які не вмикали збереження нульових даних і не належать до корпоративних, офіційно надали одну команду — щоб користувачі самостійно видалили дані, які раніше збиралися.

Поза відкритим кодом, ще чого бракує

Питань усе ще чимало. Виправлення на стороні сервера наразі підтверджено лише для одного пристрою та одного акаунта: чи воно вже повністю запрацювало глобально — офіційно не пояснюють; також невідомо, чи дані справді видалені, і немає незалежного третього аудиту, який можна було б підтвердити.

Дехто з експертів вважає, що правильний підхід полягає в тому, щоб на стороні сервера напряму заборонити завантаження цілого репозиторію коду, а не покладатися на ручні команди користувача як на тимчасове виправлення. Реакція спільноти була прямою: важко довіряти AI-помічнику, який має найвищі права доступу до комп’ютера. Для компаній і незалежних розробників, які віддають весь розробницький середовище AI-агенту, ця подія фактично стала «дзвінком»: що вища надана авторизація інструменту, то тим суворішим мають бути механізми аудиту.