Grok Build open source: sprawdziliśmy kod

SpaceXAI opublikowało kod Grok Build jako open source na licencji Apache 2.0, kilka dni po tym, jak niezależna analiza wykazała, że narzędzie wysyłało w tle całe repozytoria na serwery firmy. Sklonowaliśmy to repozytorium i sprawdziliśmy dokładnie tę część kodu, wokół której toczy się spór. Wnioski są mieszane: mechanizm uploadu faktycznie jest wyłączony, ale nie został usunięty, a repozytorium nie zawiera historii, więc kodu sprzed afery nie da się w nim obejrzeć.

Co dokładnie opublikowano

Repozytorium xai-org/grok-build jest publiczne, na licencji Apache 2.0, i zebrało ponad 8 tysięcy gwiazdek. Kod jest napisany w Rust i liczy ponad 2200 plików źródłowych. Opis mówi wprost, czym to jest: obudowa agenta kodującego wraz z interfejsem terminalowym.

Pierwsza rzecz, która rzuca się w oczy przy sprawdzaniu, to nie kod, tylko jego historia. A raczej jej brak. Repozytorium ma dokładnie jeden commit, bez commita nadrzędnego, wrzucony przez konto bota 16 lipca o 5:46 czasu UTC, mimo że samo repozytorium założono 14 lipca wieczorem. Nie ma tagów, nie ma gałęzi poza główną, nie ma śladu rozwoju.

To rozróżnienie ma znaczenie praktyczne. „Open source“ znaczy tutaj: opublikowany zrzut kodu w takim stanie, w jakim jest dzisiaj. Nie znaczy: otwarty rozwój, w którym można prześledzić, kto i kiedy dodał wysyłkę repozytoriów ani kiedy ją wyłączono. Akurat to pytanie jest sednem całej sprawy i akurat na nie opublikowany kod nie odpowiada.

Zajrzeliśmy do mechanizmu uploadu

W kodzie jest osobny moduł poświęcony wysyłce, a w nim plik trace.rs z funkcją upload_session_state(). To ta ścieżka, która wysyłała stan sesji na serwery. Dziś jest zaślepiona: funkcja przyjmuje argumenty, ignoruje je (nazwy poprzedzone podkreśleniem to w Rust konwencja oznaczająca „nieużywane“) i zawsze zwraca ten sam błąd o wymownej nazwie session_state_upload_unavailable. Nic nie wychodzi w sieć, bo nie ma czym.

Podobnie wygląda config_files.rs, czyli moduł od wysyłania plików konfiguracyjnych, a więc tej kategorii, do której należą pliki .env z kluczami API. Komentarz na górze pliku mówi wprost, że artefakt jest „currently disabled“, a jedyne, co funkcja robi, to odnotowanie pominięcia z powodem config_content_upload_disabled. Słowo „currently“, czyli „obecnie“, jest tu całą treścią.

Rusztowanie zostało jednak nietknięte. Zaślepiona funkcja nadal jest wywoływana z ośmiu miejsc w kodzie agenta. Adapter do Google Cloud Storage wciąż siedzi w pliku gcs.rs i wciąż opisuje w komentarzach żądanie POST /v1/storage, czyli dokładnie ten endpoint, którym płynęły repozytoria. Innymi słowy: silnik wymontowano, ale cała instalacja pod niego została, łącznie z rurami.

Uczciwie: to normalna praktyka inżynierska, a nie dowód złej woli. Wyłącza się funkcję zaślepką, zanim posprząta się kod. Warto jednak wiedzieć, że przywrócenie wysyłki w tej wersji wymagałoby zmiany kodu i wydania nowej wersji programu, a nie samego przestawienia przełącznika na serwerze. To realna różnica na korzyść użytkownika wobec stanu sprzed publikacji.

Porada, która krąży po sieci i nie działa

Przy okazji sprawdziliśmy coś, co warto sprostować. Po sieci krąży rada, żeby zablokować wysyłkę repozytoriów, ustawiając disable_codebase_upload = true w pliku ~/.grok/config.toml. W opublikowanym kodzie ta nazwa nie występuje ani razu, w żadnym pliku. To flaga, którą zwraca serwer w odpowiedzi, a nie opcja, którą program czyta z konfiguracji. Wpisanie jej sobie do pliku nie zrobi nic poza dodaniem linijki, która nikogo nie obchodzi.

Sprawdziliśmy też komendę /privacy, do której odsyła sama firma. Istnieje i jest opisana w kodzie jednoznacznie: kontroluje, czy SpaceXAI może przechowywać dane z sesji kodowania i trenować na nich. To jest ustawienie retencji i trenowania, a nie wyłącznik wysyłki. Cała afera wzięła się dokładnie z tego rozjechania: użytkownik był przekonany, że przełącznik prywatności zatrzymuje wysyłkę, a on decydował o czymś innym.

Co z tego wynika dla Ciebie

Jeśli używasz Grok Build do prywatnego kodu, otwarcie źródeł jest dobrą wiadomością, ale z gwiazdką. Dobrą, bo każdy może dziś sprawdzić, co narzędzie robi, zamiast wierzyć komunikatom prasowym. Z gwiazdką, bo opublikowany kod to zrzut bez historii, a to, czy binarka, którą masz na dysku, odpowiada dokładnie temu kodowi, jest osobnym pytaniem, na które publikacja nie odpowiada.

Praktycznie: jeśli uruchamiałeś tego agenta na repozytorium z sekretami przed 14 lipca, zalecenie z poprzedniego tekstu nie zmienia się ani o jotę. Rotacja kluczy jest jedyną rzeczą, która realnie zamyka sprawę, bo żadna późniejsza poprawka ani obietnica skasowania danych nie cofa tego, co już wyszło z Twojego komputera. A do nowych projektów obowiązuje ta sama zasada co zawsze, niezależnie od marki agenta: klucz, którego rotacja byłaby bolesna, nie powinien leżeć w katalogu otwartym w narzędziu, któremu ufasz tylko trochę.