Průšvih: Grok Build si tiše stahoval uživatelské GIT repozitáře

Vývojářský nástroj Grok Build od SpaceXAI (dřívější xAI) nahrával při běžné práci celé sledované git repozitáře, včetně plné historie commitů, do cloudového úložiště Google Cloud Storage. Nahrával je zvláštním kanálem vedle komunikace s modelem, dělo se to na pozadí a přepínač soukromí, který měl přenos zastavit, řídil jen souhlas s tréninkem. V nahraných datech skončily i necenzurované klíče z .env souborů a tajemství, která už dávno někdo z historie commitů smazal. Na celý mechanismus přišel bezpečnostní výzkumník vystupující pod přezdívkou cereblab pomocí odposlechu síťového provozu. Firma reagovala během dvou dnů: vypnula upload serverovým přepínačem, přidala příkaz /privacy, Elon Musk slíbil smazání všech dosud nahraných dat a celý Grok Build vyšel jako open source. Ověřit, že se data opravdu smazala, ale nikdo zvenčí nemůže, a nahrávací kód v binárce dál leží, jen zablokovaný.

Pojďme si to projít po pořádku, protože každý z těch kroků má svůj háček.

Ve zkratce:

Grok Build CLI ve verzi 0.2.93 balil celý sledovaný repozitář do git bundle a posílal ho na endpoint /v1/storage do bucketu grok-code-session-traces, nezávisle na tom, které soubory agent pro úkol skutečně otevřel.
V jednom měřeném případě odešlo 5,10 GiB dat, zatímco na samotný úkol stačilo zhruba 192 KB. To je zhruba 27 800násobek toho, co bylo potřeba.
Přepínač „Improve the model” řídil souhlas s tréninkem modelu. Přenos dat z počítače neovlivňoval. Po jeho vypnutí server dál hlásil trace_upload_enabled: true.
V balíku odcházely necenzurované obsahy .env souborů (falešné API klíče a hesla z testu) a plná historie commitů, tedy i tajemství smazaná měsíce předtím.
SpaceXAI vypnula výchozí retenci 12. července, přidala příkaz /privacy a serverový flag disable_codebase_upload, 15. července otevřela zdrojový kód pod licencí Apache 2.0 a resetovala uživatelské limity jako součást pokání.
Muskův příslib úplného smazání dat nikdo nezávisle neověřil. Nahrávací kód zůstává v binárce a lze ho serverovým přepínačem znovu zapnout.
Sběr dával funkční smysl (telemetrie a tréninková data), tenhle účel ale splývá s vlastním zájmem firmy. Zlý úmysl z odposlechu prokazatelně nečouhá, soukromí uživatelů ovšem skončilo poslední v řadě. Což se u AI stává pravidlem.
zajímá vás to detailně? Na konec článku (pod závěr) přidávám sekci Do detailu, kde si přesně vysvětlíme technického detaily toho, co se stalo. Je to fakultativní, pro pochopení samotné podstaty maléru to není třeba studovat.

Co je Grok Build a proč na tom záleží

Nejdřív ke jménu, ať v tom máme jasno. Firma, která Grok Build vyrábí, se do 6. července 2026 jmenovala xAI. Pak proběhl rebranding na SpaceXAI, aby název seděl k mateřské SpaceX, která xAI koupila v únoru 2026. Grok si svoje jméno nechal, takže dál mluvíme o Grok Buildu, jen za ním stojí SpaceXAI. Oficiální účet na síti X vystupuje jako @SpaceXAI.

Grok Build je terminálový agentní nástroj pro programování, takzvaný harness s celoobrazovkovým textovým rozhraním. SGrok Build vyšel v betě zhruba v květnu 2026 (referovali jsme zde) a od 8. července jede na modelu Grok 4.5. Přístup mají předplatitelé SuperGrok. A musím říct, že já jsem s modelem Grok 4.5 a Buildem velmi spokojen, sám jsem ho od vydání této verze velmi často doporučoval, protože je rychlý a výkonný a levný. Je to placený nástroj mířený na profesionální vývojáře, kteří mu svěřují své repozitáře. A přesně to je na celém incidentu ta nepříjemná část.

Proč se ta data vůbec sbírala

Napadne vás otázka: dělal to Grok Build kvůli lepšímu fungování, nebo z toho čouhá nekalý úmysl? Odpověď je nepohodlná, protože obě věci tady splývají.

Nejdřív ke třem větám, které kolují jako „oficiální vysvětlení”: že šlo o neúmyslný bug, že cílem bylo dát agentovi plný kontext repozitáře a že data nešla do tréninku. Autorem těch vět je AI chatbot Grok, který je vyslovil v odpovědích pod vlákny. Firemní prohlášení je neobsahuje. Oficiální stanovisko SpaceXAI z 15. července mluví o ZDR, o výchozí retenci v betě, o smazání dat a o open source. Proč se nahrávaly celé repozitáře, v něm nestojí, a bezpečnostní pokrytí se shoduje, že xAI ten důvod dodnes nevydala. Grok o rozhodnutích inženýrů xAI privilegovanou znalost nemá, generuje pravděpodobně znějící text. Jeho verzi je proto namístě brát jako komunitní dohad. Za doznání firmy ji vydávat nelze.

Dvě z těch Grokových tvrzení navíc narážejí na fakta. „Neúmyslný bug” těžko obstojí vedle toho, že výzkumníci našli v binárce samostatnou sběrnou komponentu s řetězci jako data-collector, repository-state collection a workspace collection. To je napsaný a pojmenovaný kód, tedy záměrná mašinerie. „Plný kontext pro agenta” zase naráží na architekturu: repozitář odešel kanálem /v1/storage do úložiště, zatímco kontext pro samotný model šel zvlášť, v oněch 192 KB. Kopii celé historie ke své odpovědi „OK” agent do promptu nedostal a nepotřeboval.

Funkční důvod existuje a je docela silný. Agentní nástroje na kód se zlepšují dvěma věcmi. Sběrem session traces, tedy záznamů o průběhu konkrétního běhu, na kterých se ladí harness a hledá, kde agent selhal. A sběrem reálných codebase pro reinforcement learning na programátorských úlohách. Grok 4.5 podle SpaceXAI prošel RL fází přes statisíce převážně softwarových úloh, a na to jsou skutečné repozitáře ideální materiál. Bucket se navíc jmenoval grok-code-session-traces, což je pojmenování konzistentní s telemetrií. Existuje tedy verze příběhu, ve které jde o snahu vylepšit produkt. Háček je v tom, že i ta nejhodnější verze je pořád sběr cizího proprietárního kódu ve prospěch SpaceXAI. To „lepší fungování” je fungování jejich produktu, placené vaším kódem.

Čtyři věci ale i tuhle charitativní verzi tlačí přinejmenším do polohy hrubé nedbalosti. Nahrávala se plná historie commitů včetně dávno smazaných, což pro trace aktuálního úkolu nemá hodnotu, zato pro maximalizaci tréninkového korpusu ano. Nahrál se i soubor, který agent dostal výslovný pokyn nečíst, takže sběr byl odpojený od potřeb úkolu. Soubor .env odcházel neredigovaný, přestože rozumně postavená telemetrie tajemství maskuje. A celé to bylo pro uživatele bez ZDR ve výchozím stavu zapnuté, běželo na pozadí, nemělo vlastní ovládací prvek a nebylo v dokumentaci ani changelogu. Každé jednotlivé rozhodnutí náhodou hraje ve prospěch tichého maximálního sběru.

Zůstaňme přesní. Odposlech rozhoduje o přenosu, přijetí, uložení, o výchozím zapnutí a o tom, že přepínač přenos nezastavil. O vnitřním úmyslu nerozhoduje. Neříká, jestli někdo ten kód četl, jestli se na něm trénovalo, ani jestli šlo o záměr klamat, nebo o pohodlně nastavené defaulty. Kdo tvrdí, že zná ten úmysl, ať už ho maluje jako nevinný, nebo zlovolný, dopovídá si nad rámec důkazů.

Nejúspornější vysvětlení je sebestředná telemetrie plus sběr tréninkových dat, zabalené do nedbalého soukromí typického pro betu ve stylu „posbíráme všechno, soukromí vyřešíme potom”. Na promyšlenou špionáž to nevypadá, na to je celé moc hlučné a moc špatně schované. Nedbalost tohohle rozsahu, na placeném vývojářském nástroji, s tajemstvími v balíku, je ale vážné selhání bez ohledu na úmysl. Zlý úmysl z toho prokazatelně nečouhá. Čouhá z toho, že soukromí uživatelů skončilo úplně poslední v řadě.

Jak reagovala SpaceXAI

Na časové ose je nejlíp vidět, co firma udělala sama od sebe a co až pod tlakem.

Kolem 12. července, po zveřejnění analýzy, vypnula SpaceXAI upload serverovou stranou. Přidala flag disable_codebase_upload a zakázala výchozí retenci pro všechny uživatele. Oficiální changelog přitom 12. července uváděl jako poslední verzi 0.2.98 a o nahrávání repozitářů v něm nebylo ani slovo. Žádné bezpečnostní upozornění, žádný security advisory. Firma komunikovala přes příspěvky na síti X.

Dne 14. července, když se věc dostala na titulku Hacker News, vydala SpaceXAI oficiální vyjádření. Znělo zhruba takto: firmám v režimu zero data retention (ZDR) se žádná data neukládají, totéž platí pro použití přes API klíč, a kdo ZDR zapnutý nemá, může příkazem /privacy retenci vypnout a smazat dříve nasynchronizovaná data. K tomu firma přiznala, že v rané betě byla retence pro uživatele bez ZDR zapnutá ve výchozím stavu a že to po zpětné vazbě změnili. Elon Musk šel dál a slíbil, že všechna dosud nahraná uživatelská data budou úplně a beze zbytku smazána. Sam Altman, šéf OpenAI, celé chování označil za znepokojivé, což je v kontextu rivality mezi oběma firmami poznámka, kterou je dobré vážit s rezervou.

Pak 15. července přišel největší krok. SpaceXAI otevřela celý Grok Build jako open source pod licencí Apache 2.0 na adrese github.com/xai-org/grok-build a zároveň resetovala uživatelské limity. Argument firmy dává smysl: když si kód může kdokoli prohlédnout a spustit lokálně s vlastním inferencem, nemusí věřit marketingu a může si chování ověřit sám.

Tady je ovšem důležité oddělit dvě věci, které se v přenosu často slily dohromady. Open source samotného Grok Buildu je hotová věc, kód je na GitHubu. Muskův samostatný příslib otevřít celou codebase sítě X „bez výjimek” je zatím jen slib do budoucna, podmíněný revizí bezpečnostních zranitelností a nezávislým ověřením třetí stranou. To druhé zatím nikdo neviděl.

Co ukazuje zveřejněný kód

Open source přinesl pár konkrétních čísel a jedno nepříjemné zjištění. Grok Build má podle rozboru Simona Willisona 844 530 řádků Rustu, přičemž jen asi 3 % jsou převzatý cizí kód. Terminálové vývojové nástroje jsou tedy podstatně složitější stroje, než by se mohlo zdát. Repozitář má zatím jediný commit, takže z něj o vývoji kódu v čase nic nevyčteme.

Podstatnější je, že nahrávací kód v binárce zůstal. Soubor xai-grok-shell/src/upload/gcs.rs obsahuje logiku pro upload do GCS bucketu a funkce upload_session_state() v upload/trace.rs teď vrací natvrdo zadanou chybu session_state_upload_unavailable. Jinými slovy, mechanismus je zablokovaný, ale přítomný. Samostatný rozbor pozdějšího buildu 0.2.99 potvrdil totéž: upload kód v binárce zůstává a drží ho při zemi jen serverový flag. SpaceXAI ho tedy může zase zapnout bez toho, aby vám na počítač dorazila nová verze binárky.

To je jádro celé nejistoty. Serverový přepínač je pohodlná záplata. Funkční bezpečnostní hranici na straně klienta ale nenahradí, protože vzdálené přepínače funkcí se dají změnit bez vašeho vědomí.

Jak jsou na tom konkurenti

Incident je potřeba zasadit do kontextu, protože ne každý agentní nástroj se chová stejně. Podle Cereblabovy analýzy Claude Code, Gemini CLI i OpenAI Codex otevírají jednotlivé soubory podle potřeby a posílají je s modelem, místo aby balily celý repozitář s historií a nahrávaly ho na pozadí. Retence dat u Grok Buildu tedy šla podle výzkumníka dál než u srovnatelných nástrojů. U Claude Code a Cursoru se sice objevily případy, kdy agent omylem nabral .env tajemství a poslal je dál, zdokumentovala je bezpečnostní firma Knostic. V takovém rozsahu, hromadné nahrání celého repozitáře i s historií na pozadí, se ale konkurenci nic podobného nestalo.

Ostatní agenti tím z principu bezpečné nejsou. Jde o rozdíl mezi „posílám modelu soubory, které mám otevřít” a „posílám na server celý strom včetně toho, co jsem si přečíst neměl”.

Závěrem: Co dělat teď a na co si ještě počkat

Když jste Grok Build 0.2.93 pustili na cokoli citlivého před 13. červencem, berte to jako potenciální únik k třetí straně a podle toho postupujte. Konkrétně:

Rotujte všechny přihlašovací údaje, které mohl nástroj vidět. To zahrnuje cokoli, co četl, cokoli ve sledovaných souborech a cokoli v historii commitů, tedy i tajemství, která jste kdysi commitli a později smazali.
Spusťte v CLI příkaz /privacy, zkontrolujte nastavení retence a smažte dříve nasynchronizovaná data. Výstup si pro jistotu uložte.
Pro citlivou práci zvažte enterprise plán se smluvně definovanou retencí, schválený lokální model, nebo harness, který posílá jen vybraný kontext. Open source Grok Buildu vám nově umožňuje běh plně lokálně, s vlastním inferencem přes úpravu config.toml.

A na co si počkat, než tomu uvěříte úplně. Muskův příslib smazání dat je zatím jen tweet. Auditovaný fakt z něj nikdo neudělal a nezávislé ověření nikdo nezveřejnil. Cereblab navíc upozornil, že upload ve skutečnosti zastavil globální serverový flag disable_codebase_upload. Příkaz /privacy je jen přepínač retence pro jednotlivá sezení, s odchodem dat nepohnul. Správný výchozí stav je vypnuto, a žádný vývojář by neměl po každém sezení spouštět odhlašování, aby udržel vlastní kód mimo cizí servery.

Reakce SpaceXAI je na poměry v oboru rychlá a otevření zdrojového kódu je krok správným směrem. Pořád je to ale hlavně obnova důvěry. Technickou záruku, že se data opravdu smazala a že se kanál znovu nezapne, tím nikdo nedostal. Rozdíl mezi „netrénujeme na datech firem” a „vaše data neopustí váš stroj” je přesně ten, který celý incident odhalil. A ten zacelí jedině ověřitelné chování. Sliby na to nestačí.

A teď už ty volitelné detaily, pokud byste chtěli či potřebovali detailnější rozbor…

Do detailu: co se dělo?

Bezpečnostní výzkumník publikující pod přezdívkou cereblab si vzal Grok Build CLI verze 0.2.93 a prohnal ho odposlechem síťového provozu. Použil k tomu mitmproxy, volně dostupný nástroj, který se posadí mezi klienta a server a čte, co mezi nimi lítá. Svou analýzu zveřejnil jako veřejný gist a 14. července se dostala na titulku Hacker News. Detailní rekonstrukci publikoval mimo jiné The Hacker News.

Co se ukázalo: klient posílal data dvěma paralelními kanály. Jeden byl normální modelový provoz na endpoint /v1/responses, tedy to, co agent skutečně potřeboval přečíst a poslat modelu, aby odpověděl. Druhý byl samostatný úložný kanál na /v1/storage, který balil celý sledovaný repozitář do git bundle, přidal plnou historii commitů a poslal ho do bucketu na Google Cloud Storage pojmenovaného grok-code-session-traces. Ten název je zapsaný přímo v binárce i v přiloženém metadata.json, jehož cesty ukazovaly na gs://grok-code-session-traces/.

Poměr, který z toho vyšel, mluví sám za sebe. Na repozitáři, jehož soubory model vůbec nečetl, odešlo modelovým kanálem přibližně 192 KB. Úložným kanálem odešlo 5,10 GiB. To je zhruba 27 800násobek. Nahrávání běželo jako 73 bloků po zhruba 75 MB, každý vracel HTTP 200, a napříč měřeními objem rostl s velikostí repozitáře. Objem přenosu tedy určovala velikost repozitáře na disku, úkol s ním neměl nic společného.

Aby vyloučil, že jde jen o soubory, které si agent sám vyžádal, provedl cereblab canary test. Dal agentovi neškodný prompt: odpověz „OK” a neotevírej žádné soubory. Do repozitáře přitom umístil soubor src/_probe/never_read_canary.txt s unikátní značkou. Agent poslušně odpověděl OK. A ten soubor se přesto objevil v nahraném git bundle, doslova a do písmene, spolu s celou historií repozitáře. Test zopakoval na druhém, nesouvisejícím repozitáři se stejným výsledkem.

Tady je potřeba zůstat přesný, protože kolem podobných kauz rychle narůstá zkreslení. Odposlech prokazuje tři věci: že data opustila testovaný stroj, že je server přijal a že skončila v úložišti. Neprokazuje, že SpaceXAI na tom kódu trénovala, že ho někdo ze zaměstnanců četl, ani že se do balíku vždy dostanou i soubory v .gitignore. Drát ukázal sledované soubory plus historii. To je vážné dost samo o sobě, přehánět není proč.

Přepínač soukromí, který nic nepřepínal

Grok Build nabízel přepínač „Improve the model”. Většina vývojářů si pod ním logicky představí kontrolu nad tím, jestli se jejich data někam posílají. Skutečnost byla jiná.

Cereblab přepínač vypnul a test zopakoval. Git bundle se nahrál dál a serverový endpoint /v1/settings dál vracel trace_upload_enabled: true. Ten přepínač totiž řídil souhlas s tréninkem modelu, tedy jestli SpaceXAI smí data použít pro trénink budoucích verzí Groku. S tím, jestli data vůbec odejdou z počítače, neměl nic společného. To jsou dvě různé věci na úrovni architektury, a Grok Build dal uživateli do ruky jen jednu z nich.

Vypnutím té volby jste tedy odmítli konkrétní pozdější použití dat, která už dávno odešla. Zabránit odchodu samotnému jste tou volbou nemohli. Pro produkt, který se marketingově prezentoval jako local-first, je to dost zásadní rozpor.

Klíče a hesla v balíku

Druhá cesta, kterou tajemství odcházela, je jednodušší. Když Grok Build nějaký soubor přečte, jeho obsah putuje do modelového tahu. Cereblab do repozitáře vložil sledovaný .env soubor s falešnou hodnotou API_KEY a DB_PASSWORD. Odešly neredigované, jak v modelovém tahu, tak v archivu session_state mířícím do úložiště.

A protože se nahrávala plná historie commitů, odcházela i tajemství, která do repozitáře kdysi někdo vložil a měsíce předtím zase smazal. To je klasická past. Vývojář commitne klíč, uvědomí si chybu, klíč smaže dalším commitem a žije v přesvědčení, že je to za ním. V git historii ten klíč zůstává a Grok Build ho poslal dál.

Objevila se i drsnější hlášení. Jeden uživatel popsal, že nástroj spustil ve svém domovském adresáři a ten se nahrál celý: SSH klíče, databáze správce hesel, dokumenty, fotky, videa, cituje ho Simon Willison. Tady je namístě opatrnost. Odposlechem potvrzené chování se týká sledovaných souborů repozitáře a historie. Případ s domovským adresářem je uživatelské hlášení, které do stejné roviny důkazu nepatří. Naznačuje ale, že rozsah mohl být širší než jen git bundle, a to je důvod, proč bezpečnostní výzkumníci doporučují brát věc vážně napříč celým adresářem, ve kterém nástroj běžel.

Praktický závěr je nepříjemně jasný. Kdo Grok Build 0.2.93 pustil na repozitář se skutečnými přihlašovacími údaji, měl by ty údaje považovat za potenciálně kompromitované a rotovat je. Bez ohledu na to, co říkalo nastavení soukromí v tu chvíli.