Sikkerhetsforskeren Cereblab avlyttet trafikken fra Grok Build (versjon 0.2.93) med mitmproxy og fant to separate datakanaler: én som sendte filene modellen faktisk leste, og én som pakket hele arbeidsområdet, alle git-sporede filer pluss full commit-historikk, og lastet det opp til bøtten «grok-code-session-traces». Funnet ble publisert 12. juli.
For å bevise at opplastingen var uavhengig av oppgaven, plantet forskeren en fil verktøyet uttrykkelig fikk beskjed om ikke å åpne. Den dukket likevel opp ordrett i git-bundlen som ble lastet opp. Personverninnstillingen «Improve the model» stanset ingenting: serveren rapporterte trace_upload_enabled som på uansett hvordan bryteren sto.
xAI skrudde av mekanismen server-side dagen etter, via et flagg kalt disable_codebase_upload, men uten en formell sikkerhetsvarsling til brukerne. Ifølge Cereblab ligger opplastingskoden fortsatt i binæren og styres bare av dette serverflagget, som xAI i prinsippet kan slå på igjen uten en ny programvareutgivelse.
«Improve the model»-bryteren var en retensjonsbryter per økt, ikke bryteren som faktisk fikset dette. — Cereblab
Hva bør du gjøre?
- Roter alle hemmeligheter (API-nøkler, databasepassord og cloud-tokens) i repoer der Grok Build har kjørt, også dem du senere har slettet, siden hele git-historikken ble lastet opp.
- Behandle alle git-sporede filer som eksponert, ikke bare filene modellen leste under økten.
- Ikke stol på «Improve the model» som en opplastingssperre; den styrer bare databruk til trening, ikke selve opplastingen.