Blog

Grok Build nahrával celé repozitáře na cloud. A teď se hasí důvěra

Výzkumníci zjistili, že Grok Build CLI odesílal na Google Cloud celé codebase, včetně souborů mimo zadání a smazaných tajemství. SpaceXAI upload vypnula, Elon Musk slibuje kompletní smazání dat.

Zase jednou bezpečnost a AI v praxi: Grok Build, programátorský nástroj od SpaceXAI, posílal na Google Cloud celé repozitáře uživatelů. Ne jen kousek kontextu pro odpověď, ale balík všeho — včetně toho, co výslovně neměl otevírat.

Co přesně prasklo

Cereblab popsal, že Grok Build CLI (command-line interface, tedy nástroj ovládaný z terminálu) balil a uploadoval celé codebase. Codebase = kompletní zdrojové kódy projektu i s historií. Do balíku se dostaly i soubory „mimo záběr“ a dokonce tajemství smazaná z historie. Tohle je úplně jiný level retence dat (retence = jak dlouho a co si služba ponechá) než u podobných nástrojů typu Claude Code.

Podle testů výzkumníků teď servery SpaceXAI vrací flag „disable_codebase_upload: true“ a nahrávání už nespouští. Elon Musk k tomu na X napsal, že všechna dříve nahraná data budou „zcela a naprosto smazána“. Zároveň tvrdí, že „privacy settings jsou vždy respektovány“, a prosí uživatele, aby přesto s retencí pomohli kvůli ladění chyb.

Co mě na tom zaráží

Všimla jsem si dvou věcí. Zaprvé, SpaceXAI původně ukazovala na příkaz „/privacy“ v CLI jako na řešení. Cereblab ale říká, že jde o per‑session přepínač — dočasný toggle pro dané sezení, nikoli trvalé vypnutí mechaniky uploadu. To je rozdíl, který v bezpečnosti rozhoduje, a komunikačně je to prostě matoucí.

Zadruhé, objem a typ dat. Nejde jen o „víc kontextu pro model“. Bezpečnostní analytik Lukasz Olejnik to označil za nadměrné a dává to smysl: v takovém dumpu mohou být proprietární kód, informace o zranitelnostech, osobní údaje, infrastruktura i přihlašovací údaje. Git historie není skartovačka, je to kronika vašich hříchů — a posílat ji někam mimo kontrolu firmy je recept na problém s compliance i riziko úniku.

Co si z toho vzít do praxe

  • Nastavení „zero data retention“ (nulová retence dat) berte jako výchozí, ne výjimku. Pokud nástroj něco ukládá, chtějte jasný, trvalý přepínač na úrovni organizace.
  • Omezte, co může CLI vidět: spouštějte asistenty nad vybranými složkami, ne v rootu monorepa. Ideálně přes sandboxovaný workspace.
  • Sledujte odchozí provoz. Proxy s allowlistem, DLP (data loss prevention) a audit logy jsou nuda, dokud vám jednou nezachrání reputaci.
  • Udržujte tajemství mimo repo a historii. Skenery tajemství v CI jsou levná pojistka; rotace credů po incidentech patří do plánu.
  • Pro citlivé kódy zvažte lokální/offline asistenty nebo on‑premise varianty se smluvně ošetřenou retencí.

Co zatím nevíme

  • Jak dlouho a v jakém přesném rozsahu se repozitáře nahrávaly a kde všude byla data uložena kromě Google Cloudu.
  • Zda existuje nezávisle ověřitelný důkaz o „kompletním smazání“ dříve nahraných dat a jak bude mazání auditováno.
  • K čemu přesně byla data používána (ladění vs. trénování modelů) a jaké interní kontroly je chránily.

Upřímně doufám, že z toho vznikne dobrý post‑mortem a jasná pravidla. Důvěra v AI nástroje pro vývojáře se buduje pomalu a rozbije se jedním špatným uploadem.

Zdroje

Došlo k neočekávané chybě. Obnovit 🗙

Rejoining the server...

Rejoin failed... trying again in seconds.

Failed to rejoin.
Please retry or reload the page.

The session has been paused by the server.

Failed to resume the session.
Please retry or reload the page.