Nowości

xAI udostępnia kod źródłowy Grok Build kilka dni po aferze z wyciekiem repozytoriów

ProgramowaniePatryk Raba2
Fot. xAI, GitHub (zrzut ekranu)

xAI opublikowało na GitHubie kod źródłowy Grok Build, swojego terminalowego agenta do programowania, i pozwoliło na uruchamianie go w pełni lokalnie. Decyzja zapada niecały tydzień po ujawnieniu, że narzędzie wysyłało całe repozytoria kodu na serwery firmy bez zgody użytkowników.

Spis treści
  1. Co dokładnie opublikowano
  2. Praca w pełni lokalna
  3. Cień afery z wyciekiem danych
  4. Co to znaczy dla polskich programistów

xAI udostępniło publicznie kod źródłowy Grok Build, swojego terminalowego agenta do programowania, w repozytorium xai-org/grok-build na GitHubie. To narzędzie konkurujące z Claude Code i Codexem od kilku dni znajdowało się pod ostrzałem po tym, jak niezależny badacz wykazał, że wysyłało ono całe repozytoria kodu, wraz z historią commitów i niezaszyfrowanymi sekretami, na serwery firmy bez wyraźnej zgody użytkowników.

Co dokładnie opublikowano

Repozytorium zawiera pełny kod agenta i interfejsu tekstowego (TUI), które odpowiadają za rozumienie kodu, edycję plików, wykonywanie poleceń powłoki, przeszukiwanie sieci oraz zarządzanie długotrwałymi zadaniami. Narzędzie działa interaktywnie w terminalu, headlessowo w skryptach i automatyzacjach CI, a także jako komponent innych aplikacji poprzez Agent Client Protocol.

Kod jest synchronizowany okresowo z wewnętrznym monorepo xAI, więc nie jest to typowy projekt społecznościowy rozwijany na bieżąco przez zewnętrznych deweloperów. Plik CONTRIBUTING.md wprost zaznacza, że firma nie przyjmuje pull requestów z zewnątrz, co jest nietypowe jak na projekt reklamowany jako otwarty.

W ogłoszeniu xAI napisało, że publikacja kodu to najbardziej bezpośredni sposób na zbudowanie solidnego i wiarygodnego narzędzia. Deweloperzy mogą teraz prześledzić dokładnie, jak działa agent, od budowania kontekstu po dyspozycję wywołań narzędzi, co ułatwia rozszerzanie go o własne skille, wtyczki, hooki i serwery MCP.

Praca w pełni lokalna

Kluczową nowością jest możliwość uruchomienia Grok Build w pełni lokalnie: użytkownik może samodzielnie skompilować narzędzie, wskazać własny lokalny model wnioskujący i skonfigurować całość przez plik config.toml, bez konieczności komunikacji z chmurą xAI. Wcześniej agent działał wyłącznie w oparciu o modele i infrastrukturę firmy.

Repozytorium zawiera też kod pochodzący z innych projektów open source, w tym elementy zapożyczone z openai/codex i sst/opencode oraz stos do generowania diagramów Mermaid, opisane w plikach z informacjami licencyjnymi stron trzecich.

Cień afery z wyciekiem danych

Decyzja o otwarciu kodu zbiega się w czasie z głośną aferą wokół tego samego narzędzia. Badacz działający pod pseudonimem Cereblab wykazał w analizie ruchu sieciowego, że wersja Grok Build 0.2.93 wysyłała na zewnętrzny bucket Google Cloud Storage całe repozytoria git, łącznie z pełną historią commitów i plikami, których model nigdy nie odczytał.

Skala rozbieżności była uderzająca: na testowym repozytorium liczącym 12 GB ruch samego modelu do końcówki odpowiedzi wyniósł około 192 KB, podczas gdy kanał przesyłu do magazynu danych przesłał 5,1 GB, czyli około 27 800 razy więcej niż potrzebował sam agent. Badacz udowodnił to, umieszczając w repozytorium plik-pułapkę o nazwie never_read_canary.txt, który mimo polecenia niedotykania plików trafił w całości do przechwyconej paczki danych.

Cofnięcie ustawienia poprawy modelu nie miało żadnego wpływu na przesył repozytorium - serwer nadal zwracał trace_upload_enabled: true, a pełny upload przebiegał normalnie.

Problem dotyczył też bezpieczeństwa danych uwierzytelniających: gdy Grok Build odczytywał pliki .env z testowymi kluczami API i hasłami do baz danych, trafiały one do archiwów sesji bez żadnej redakcji. xAI wyłączyło mechanizm przesyłu po stronie serwera 13 lipca, dzień po publikacji analizy, ale nie opublikowało formalnego raportu incydentu ani harmonogramu usuwania już zebranych danych.

Co to znaczy dla polskich programistów

Dla zespołów w Polsce korzystających z agentów kodujących otwarcie kodu Grok Build oznacza realną możliwość weryfikacji, co narzędzie faktycznie robi z lokalnym repozytorium, zamiast polegać wyłącznie na zapewnieniach producenta. To istotne szczególnie po serii doniesień o narzędziach AI do kodowania nadużywających dostępu do danych czy sekretów w projektach.

Możliwość uruchomienia agenta w pełni lokalnie, z własnym modelem wnioskującym, może zainteresować firmy z restrykcyjnymi politykami bezpieczeństwa danych, dla których wysyłanie kodu do zewnętrznej chmury było dotąd barierą nie do przejścia. Jednocześnie brak przyjmowania kontrybucji z zewnątrz oznacza, że społeczność nie będzie mogła samodzielnie łatać błędów ani dodawać funkcji do samego rdzenia narzędzia.

Sprawa Grok Build wpisuje się w szerszy trend rosnącej nieufności programistów wobec agentów AI z dostępem do pełnych repozytoriów, w tym wcześniejszych doniesień o lukach w innych narzędziach tej klasy. Otwarcie kodu nie usuwa automatycznie wątpliwości co do przeszłych praktyk zbierania danych, ale daje niezależnym badaczom narzędzie do dalszej weryfikacji zachowania agenta.

Udostępnij: