Přejít k hlavnímu obsahu

Grok Build od SpaceXAI nahrával kompletní kód vývojářů do cloudu

Ilustrační obrázek
AI programovací nástroj Grok Build od SpaceXAI (dříve xAI) nahrával celé gitové repozitáře vývojářů na cloudové úložiště Google — včetně souborů, které měl ignorovat, a tajných klíčů dávno smazaných z historie. Na problém upozornil nezávislý výzkumník stojící za projektem Cereblab, který provoz CLI nástroje zachytil na drátě a data zpětně zrekonstruoval. Elon Musk slibuje kompletní smazání všech dat, ale incident otevírá zásadní otázky o důvěryhodnosti AI nástrojů, které pouštíme do svého kódu.

Co se přesně stalo: Celý repozitář na cizím serveru

V pondělí 13. července 2026 zveřejnil nezávislý bezpečnostní projekt Cereblab detailní analýzu chování CLI nástroje Grok Build od SpaceXAI. Výzkumník zachytil veškerou síťovou komunikaci nástroje pomocí mitmproxy a zjistil šokující věc: Grok Build posílal na cloudové úložiště Google (gs://grok-code-session-traces) kompletní git bundle — tedy zabalenou kopii celého repozitáře včetně kompletní git historie. Nejznepokojivější na celém nálezu je, že k uploadu došlo i ve chvíli, kdy výzkumník nástroji zadal naprosto neutrální prompt: "odpověz OK, neotvírej žádné soubory". Grok Build přesto odeslal kompletní balík s kódem na server. V datech se ocitly i soubory, které měl nástroj explicitně ignorovat, včetně .env souborů s API klíči a hesly, jež byly z historie smazány před měsíci.

Důkaz na drátě: 269 blobů, 219 MB

Cereblab svůj nález reprodukoval na dvou různých kódových základnách a další výzkumníci jej nezávisle potvrdili na vlastních privátních repozitářích — v jednom případě šlo o 269 blobů o velikosti 219 MB. Zachycená data bylo možné pomocí git clone plně zrekonstruovat do původní podoby. Binární soubor Grok Build CLI verze 0.2.93 (SHA-256 2a97ba67…d767c) odesílal HTTP POST požadavek na endpoint /v1/storage s kompletním git bundle v těle odpovědi.

O kolik víc dat Grok sbíral oproti konkurenci

Cereblab provedl srovnání s konkurenčními AI programovacími nástroji a rozdíl je propastný:
Nástroj Co odesílá na server
Claude Code Pouze soubory, které otevře (čte)
OpenAI Codex Pouze soubory, které otevře (čte)
Google Gemini CLI Pouze soubory, které otevře (čte)
Grok Build Celý repozitář + kompletní git historie
Zatímco Claude Code od Anthropicu, OpenAI Codex i Gemini od Googlu odesílají na své servery pouze ty soubory, se kterými skutečně pracují, Grok Build posílal všechno. A nešlo jen o aktuální verzi kódu — odesílal se celý git history, tedy i soubory a tajemství, která vývojáři v minulosti smazali právě proto, že tam neměla co dělat.

Reakce SpaceXAI a Elona Muska: Sliby versus realita

SpaceXAI na odhalení zareagovalo dvěma způsoby. Nejdříve firma na síti X uvedla, že uživatelé mohou použít příkaz /privacy pro vypnutí uchovávání dat. Jenže — jak upozornil Cereblab — /privacy je pouze přepínač retence na straně serveru, nikoliv vypínač samotného odesílání. Data z vašeho počítače tak odcházela i po aktivaci tohoto přepínače, jen je server následně neukládal. Elon Musk v reakci na incident napsal, že veškerá dříve nahraná data budou "kompletně a naprosto smazána". V dalším příspěvku dodal, že "nastavení soukromí je vždy respektováno", ale zároveň požádal uživatele, aby SpaceXAI povolili data uchovávat — prý je to "užitečné pro ladění chyb".

Co skutečně zastavilo upload: tichý globální přepínač

Klíčové zjištění Cereblabu je, že upload byl zastaven server-side příznakem disable_codebase_upload: true, který SpaceXAI potichu aktivovalo 13. července. Nešlo tedy o opravu na straně klienta — uživatelé nemuseli nic aktualizovat. SpaceXAI jednoduše vypnulo funkci na serveru. Současně firma vydala novou verzi CLI (0.2.99), která přidává příkaz /privacy opt-out a mění výchozí nastavení uploadu na vypnuto.

Bezpečnostní expert varuje: "Nadměrné zadržování dat"

Dr. Lukasz Olejnik, nezávislý bezpečnostní výzkumník z King's College London, pro The Verge potvrdil, že rozsah sběru dat nástrojem Grok Build byl "nadměrný" (excessive). Podle Olejnika mohla být ohrožena data zahrnující "proprietární zdrojový kód, informace o bezpečnostních zranitelnostech, osobní údaje, detaily infrastruktury a přihlašovací údaje". To je zásadní varování nejen pro jednotlivé vývojáře, ale především pro firmy, které AI nástroje nasazují do svých vývojových workflow. Pokud vývojář pracující na bankovním systému nebo zdravotnickém softwaru spustil Grok Build, mohl nevědomky odeslat citlivá data na cizí servery.

Co to znamená pro evropské a české vývojáře

Pro vývojáře v České republice a celé Evropské unii má tento incident zvláštní význam. GDPR vyžaduje, aby organizace měly pod kontrolou, kam putují data — a to včetně zdrojového kódu, pokud obsahuje osobní údaje (například jména v konfiguracích, e-mailové adresy v testovacích datech nebo API klíče propojené s konkrétními účty). SpaceXAI provozuje své servery primárně v USA a data odesílaná na Google Cloud Storage mohla být uložena kdekoliv na světě. Pro evropské firmy to znamená potenciální porušení pravidel o přeshraničním přenosu dat. I když Grok Build pravděpodobně používalo méně vývojářů v Česku než Claude Code nebo GitHub Copilot, princip je univerzální: před nasazením jakéhokoliv AI nástroje do firemního workflow je nutné ověřit, jaká data odesílá.

Širší kontext: Kam až sahá důvěra k AI nástrojům

Incident s Grok Build přichází v době, kdy AI programovací nástroje zažívají raketový růst. Podle posledních dat používá nějakou formu AI asistenta při vývoji přes 70 % profesionálních programátorů. Firmy jako Anthropic, OpenAI, Google a Microsoft investují miliardy do vývoje agentních AI, které nejen radí, ale rovnou píší, testují a nasazují kód. Jenže čím více práv těmto nástrojům dáváme, tím větší je riziko. Grok Build není první případ — v minulosti se objevily obavy ohledně GitHub Copilota a trénování na privátních repozitářích, a bezpečnostní firmy jako Snyk varují před "agentjackingem" — útoky, při kterých útočník přiměje AI agenta spustit škodlivý kód. Případ Grok Build je ale specifický tím, že nešlo o chybu nebo zneužití třetí stranou — byl to zamýšlený design. SpaceXAI zkrátka navrhlo nástroj tak, aby kompletní kód odesílal na své servery. Až do zveřejnění analýzy Cereblabem to nebylo nikde transparentně komunikováno.

Praktická doporučení pro vývojáře

Pokud používáte (nebo jste používali) Grok Build, měli byste:
  • Zkontrolovat, zda váš repozitář neobsahoval citlivé údaje, které mohly uniknout
  • Rotovat všechny API klíče a tokeny, které byly v kódové základně (včetně git historie)
  • Aktualizovat Grok Build CLI na verzi 0.2.99 nebo novější
  • Zvážit, zda pro firemní vývoj nezvolit nástroj s transparentnější politikou nakládání s daty (např. Claude Code nebo Codex)

Ponaučení pro celý obor

Kauza Grok Build ukazuje, že trh s AI programovacími nástroji potřebuje jasnější standardy. Vývojáři by nikdy neměli muset zpětně zjišťovat, co jejich nástroje odesílají na server — tato informace by měla být transparentní, ověřitelná a ve výchozím stavu minimalistická. Projekt Cereblab, za kterým stojí jediný nezávislý výzkumník, zároveň demonstruje důležitost komunitního dohledu nad AI nástroji. Bez jeho práce by vývojáři po celém světě dál nevědomky odesílali svůj kód na servery SpaceXAI.

Byl Grok Build jediný AI nástroj, který něco takového dělal?

Podle dostupných informací ano — v takto extrémní podobě. Claude Code, OpenAI Codex a Google Gemini CLI odesílají pouze soubory, které skutečně čtou nebo upravují. Žádný z těchto nástrojů neodesílá slepě celý repozitář včetně git historie. Grok Build byl v tomto ohledu výjimkou, což potvrzuje i srovnávací analýza Cereblabu.

Jak můžu zjistit, jestli můj AI nástroj neposílá citlivá data?

Nejspolehlivější metodou je zachytit a analyzovat síťový provoz nástroje pomocí proxy nástroje jako mitmproxy, Wireshark nebo Charles Proxy. Alternativně lze sledovat DNS dotazy a odchozí spojení pomocí firewall logů. Pro běžného vývojáře je ale nejpraktičtější spolehnout se na nezávislé audity (jako ten od Cereblabu) a oficiální dokumentaci výrobce — a vždy si ověřit, že nástroj má jasně definovanou politiku retence dat.

Může se podobný incident stát i u jiných AI nástrojů?

Ano, riziko existuje vždy. AI nástroje jsou komplexní software a každá aktualizace může změnit, jaká data odesílají. Výrobci mohou také kdykoliv upravit podmínky služby. Doporučujeme sledovat nezávislé bezpečnostní projekty jako Cereblab a při nasazení AI nástrojů do firemního prostředí provádět vlastní audity síťového provozu.

X

Nezmeškejte novinky!

Přihlaste se k odběru novinek a aktualit.