Grok Build (xAI) po cichu wysyłał całe repozytoria na serwery, także pliki .env

Niezależna analiza bezpieczeństwa opublikowana 13 lipca 2026 wykazała, że Grok Build, agent kodujący działający w terminalu, w tle wysyłał całe repozytorium projektu na serwery producenta, w tym pliki .env z kluczami API i innymi sekretami. Upload obejmował pliki, których agent nigdy nawet nie otworzył, i odbywał się niezależnie od tego, czy w ustawieniach włączona była opcja poprawy modelu. Dzień później firma zareagowała: wydała oświadczenie, zatrzymała uploady flagą po stronie serwera, a Elon Musk zapowiedział skasowanie zebranych danych. Aktualizacja z 16 lipca opisująca reakcję jest w sekcji Reakcja producenta na końcu tekstu.

Uwaga nazewnicza: producent Grok Build, czyli dawne xAI, po fuzji ze SpaceX nosi od 7 lipca 2026 nazwę SpaceXAI. Tak podpisany jest kod („Copyright 2023-2026 SpaceXAI“ w licencji) i tak firma mówi o sobie w komunikatach, dlatego w dalszej części używamy tej nazwy.

Co dokładnie ustalono

Analizę przeprowadził niezależny audytor bezpieczeństwa AI działający pod nazwą cereblab. Metoda była prosta i weryfikowalna: przechwycenie ruchu sieciowego (analiza wire-level) generowanego przez Grok Build w wersji grok 0.2.93 na macOS z procesorem Apple Silicon. Zamiast opierać się na deklaracjach producenta, audytor po prostu podejrzał, co narzędzie realnie wysyła w sieć podczas normalnej sesji.

Ustalenie jest konkretne. Grok Build wykonywał w tle żądanie POST /v1/storage i przesyłał cały git bundle repozytorium do bucketa Google Cloud Storage pod adresem gs://grok-code-session-traces/. Kluczowy szczegół: nie chodziło tylko o pliki, które agent czytał czy edytował w danej sesji. Do paczki trafiała zawartość całego katalogu projektu, łącznie z plikami, do których agent nigdy się nie odwołał.

Najpoważniejszy element dotyczy sekretów. W teście plik .env zawierał specjalnie spreparowany klucz-pułapkę o wartości w rodzaju API_KEY=CANARY7F3A9-SECRET-should-not-leave. Taki klucz-kanarek służy właśnie do wykrywania wycieków: jeśli pojawi się w ruchu wychodzącym, wiadomo, że dane opuściły maszynę. I pojawił się. Klucz trafił do żądania dosłownie, bez żadnej redakcji ani maskowania.

Przełącznik, który niczego nie wyłączał

Wiele narzędzi AI daje opcję w stylu „pomóż ulepszyć model“, która teoretycznie decyduje o tym, czy Twoje dane są zbierane. W przypadku Grok Build ta opcja, według analizy, nie zatrzymywała uploadu. Niezależnie od stanu przełącznika serwer w odpowiedzi zwracał "trace_upload_enabled": true, czyli sygnalizował, że wysyłka śladów sesji jest aktywna. Innymi słowy, użytkownik mógł być przekonany, że wyłączył zbieranie danych, podczas gdy repozytorium i tak wędrowało na serwery.

Ustalenia nie stoją na relacji jednej osoby. Pojawiła się niezależna reprodukcja wyników w osobnym repozytorium na GitHubie, a sama sprawa była szeroko dyskutowana na Hacker News, gdzie w ciągu dwóch dób trafiła na pierwszą stronę w kilku osobnych wątkach. To miara zainteresowania tematem, a nie dowód techniczny sam w sobie, ale pokazuje skalę odzewu.

Reakcja producenta (aktualizacja 16 lipca)

Pierwotna wersja tego newsa kończyła się zdaniem, że firma milczy. To już nieaktualne, więc prostujemy i opisujemy, co wydarzyło się od 14 lipca.

SpaceXAI wydało oficjalne oświadczenie. Firma odwołuje się w nim do zerowej retencji danych (ZDR) dla zespołów, deklaruje, że przy ZDR żadne ślady sesji ani kod nie są przechowywane, i kieruje pozostałych użytkowników do komendy /privacy w CLI, która ma wyłączyć retencję i skasować wcześniej zsynchronizowane dane.

Musk zapowiedział skasowanie danych. W jego słowach: „As a precautionary measure, all user data that was uploaded to SpaceXAI before now will be completely and utterly deleted“. W osobnym wpisie poprosił jednak, żeby użytkownicy dalej udostępniali część danych, bo „retaining some data helps with debugging“. Deklaracja skasowania to obietnica, nie audytowalny fakt: nikt z zewnątrz nie potwierdzi, że dane faktycznie zniknęły.

Uploady zatrzymała flaga serwerowa. W retestach cereblab serwer zaczął zwracać disable_codebase_upload: true oraz trace_upload_enabled: false, a wysyłki ustały. Kluczowe zastrzeżenie: to zmiana po stronie serwera, a nie łatka w programie. Firma może ją cofnąć bez aktualizacji, której użytkownik musiałby zainstalować.

Kod trafił na GitHuba. 14 lipca SpaceXAI opublikowało Grok Build jako open source na licencji Apache 2.0. Sprawdziliśmy ten kod sami i widać w nim, że mechanizm uploadu został wyłączony, ale nie usunięty. Szczegóły z konkretnymi plikami opisujemy w osobnym tekście: Grok Build jest już open source.

Jedna praktyczna uwaga na koniec, bo krąży myląca porada. Ustawianie disable_codebase_upload = true w pliku ~/.grok/config.toml nic nie daje: w opublikowanym kodzie klienta ta nazwa nie występuje ani razu, bo to flaga zwracana przez serwer, a nie opcja konfiguracyjna programu. Sprawdziliśmy to w otwartym repozytorium 16 lipca.

Co to znaczy dla Ciebie, jeśli używasz Grok Build

Sedno problemu dla osoby pracującej nad realnym projektem jest takie: klucz API w pliku .env to często dostęp do płatnych usług, bazy danych albo cudzych danych. Jeśli taki plik trafił bez Twojej wiedzy na zewnętrzny serwer, sam fakt, że później przestano go pobierać, nie cofa tego, co już zostało wysłane.

Praktycznie, jeśli używałeś Grok Build z prawdziwym repozytorium:

• Sprawdź, co masz w .env i w innych plikach z sekretami w projektach, na których uruchamiałeś tego agenta. Wypisz wszystkie klucze, tokeny i hasła.
• Rozważ rotację tych kluczy, czyli wygenerowanie nowych i unieważnienie starych, zwłaszcza jeśli dają dostęp do płatnych API, produkcyjnej bazy albo danych klientów. Rotacja to jedyny pewny sposób, żeby wyciek przestał mieć znaczenie.
• Uruchom /privacy w CLI, bo to jedyna ścieżka, którą sam producent wskazuje do wyłączenia retencji i skasowania zsynchronizowanych danych. Pamiętaj o rozróżnieniu: to ustawienie dotyczy przechowywania i trenowania na Twoich danych, a nie samego faktu wysyłki (dokładnie o to rozjechanie się rozbiła się cała sprawa).
• Przy prywatnym kodzie z sekretami zachowaj ostrożność mimo poprawki. Uploady wstrzymuje dziś flaga serwerowa, a nie zmiana w programie, więc ochrona zależy od ustawienia po stronie firmy. Do publicznych projektów bez wrażliwych danych ryzyko jest oczywiście inne niż przy poważnym, zamkniętym repozytorium.

To dobra okazja, żeby w ogóle przejrzeć, jak trzymasz sekrety w projektach. Zasada jest prosta i nie zależy od tego, którego narzędzia używasz: żaden klucz, którego rotacja byłaby dla Ciebie bolesna, nie powinien leżeć w repozytorium otwartym w agencie, któremu do końca nie ufasz.