Claude Code og Codex sendte ingen repo-pakke i den samme testen. Grok Build sendte 5,10 GiB. Det er målingen til sikkerhetsforskeren som publiserer under navnet cereblab, gjengitt av The Hacker News: xAIs kodeagent lastet opp hele git-repoer, full commit-historikk inkludert, til en skylagringsbøtte drevet av xAI.
Opplastingen gikk i en egen kanal ved siden av selve modellsamtalen, og byte-fordelingen er vanskelig å bortforklare. På et repo på 12 GB som modellen aldri leste, brukte modelltrafikken mot /v1/responses rundt 192 KB, mens lagringskanalen mot /v1/storage flyttet 5,10 GiB. Forskeren plantet en fil kalt never_read_canary.txt som agenten fikk klar beskjed om å ikke åpne, fanget opplastingen i transitt, klonet git-pakken ut av forespørselen og fikk filen tilbake ordrett. Testen ble gjentatt på et annet repo med samme resultat.
«Det opptakene fastslår er overføring, mottak og lagring, ikke trening» — cereblab, sikkerhetsforsker
Forbeholdet er forskerens eget. Han hevder verken at xAI trente på koden, at ansatte leste den, eller at gitignore-filer alltid feies med.
Bryteren de fleste utviklere ville lett etter, hjalp ikke. Med «Improve the model» slått av lastet Grok Build fortsatt opp repoet, og serverens eget svar på /v1/settings fortsatte å returnere trace_upload_enabled: true. Den bryteren styrer om dataene dine trener modellen. Den styrer ikke om koden din forlater maskinen, og bare den første var eksponert for brukeren.
Hemmelighetene fulgte en enklere vei. Når Grok Build leser en fil, går innholdet inn i modellsamtalen, og en sporet .env-fil gikk med uredigert, med API-nøkkel og databasepassord intakt. Verdiene i testen var falske, men oppførselen står igjen: en legitimasjonsfil agenten leste ble sendt ut og lagret uten maskering.
- juli sluttet den samme binærfila å gjøre lagringsforespørsler. cereblab testet seks ganger på nytt og så null opplastinger, og serveren returnerte nå disable_codebase_upload: true. Utvikleren Peter Dedene rapporterte samme flagg på sin konto. Klienten sto på samme versjon mens serverinnstillingene endret seg, så dette var en serverside-bryter, ikke en retting levert i en oppdatering. En egen analyse av en nyere build fant opplastingskoden fortsatt i binærfila, holdt tilbake av serverflagget. xAI kan slå den på igjen uten å sende ut noen ny versjon.
Selskapet har svart på X framfor gjennom en sikkerhetsvarsling. Kontoen @SpaceXAI skriver at bedriftsteam med null datalagring aldri får kode eller sporingsdata lagret, og at privatkunder kan kjøre /privacy i CLI-en for å skru av lagring og slette data som allerede er synkronisert.
«Fullstendig og totalt slettet» — Elon Musk, om brukerdata som er lastet opp til nå
Alle sky-baserte kodeagenter sender filene de åpner, så «kjører lokalt» er feil mental modell uansett verktøy. Innsamling av hele arbeidsområdet var likevel spesifikt for Grok Build, og et repo rommer ofte interne URL-er, kundedata og legitimasjon som er fjernet fra arbeidstreet, men fortsatt ligger i historikken. xAI har ikke sagt hvorfor repoene ble lastet opp som standard, hvor lenge de ble lagret, eller hvor mange brukere det gjelder.
Hva bør du gjøre?
- Roter alle nøkler og passord som lå i repoer du har kjørt Grok Build mot, inkludert hemmeligheter du slettet fra arbeidstreet, men som fortsatt finnes i commit-historikken.
- Kjør /privacy i CLI-en hvis du er privatkunde. Null datalagring dekker bare bedriftsteam og API-bruk.
- Regn ikke med at trenings-bryteren stopper opplasting. Den styrer trening, ikke hva som forlater maskinen.