Innhold Vis
Hvis du brukte Grok Build før full opplasting av kodearkiver ble stoppet 13. juli 2026, kan hele Git-repositoriet ditt ha blitt lastet opp til en Google Cloud Storage-bøtte kontrollert av SpaceXAI. Det gjelder ikke bare filene kodeagenten åpnet, men også filer den aldri skulle lese og hele Git-historikken. Elon Musk lover nå at alle tidligere opplastede brukerdata skal slettes.
Opplastingen er stoppet. En uavhengig sikkerhetsforsker har testet samme klient etter at en serverstyrt innstilling ble endret, og fikk ikke lenger Grok Build til å sende hele kodearkivet. Det er den gode nyheten. Den mindre behagelige delen er at selskapets egen forklaring om kommandoen /privacy blander sammen to forskjellige ting: hva som sendes fra maskinen, og hva selskapet sier at det lagrer etterpå.
Jeg liker Grok-kodemodellene godt. Nettopp derfor er denne saken verdt å ta på alvor uten å gjøre den større eller mindre enn den er. Det finnes foreløpig ikke bevis for at kildekoden ble offentliggjort eller brukt til modelltrening. Det som er dokumentert, er ille nok: kode og historikk forlot brukerens maskin uten at oppgaven krevde det.
Hva sendte Grok Build til skyen?
Grok Build 0.2.93 pakket hele Git-repositoriet som en Git bundle og sendte den til skylagring, ifølge Cereblabs reproducerbare nettverksanalyse. Pakken inneholdt 47 filer, fire commits og en kontrollfil som agenten uttrykkelig hadde fått beskjed om ikke å åpne. Forskeren klonet den fangede pakken og hentet kontrollfilen tilbake ordrett.
Testen var nesten komisk enkel. Prompten ba Grok Build svare «OK» og ikke åpne noen filer. Likevel gikk en forespørsel til lagringstjenesten, og innholdet begynte med signaturen til en Git bundle. Det betyr at opplastingen ikke bare var en naturlig følge av at modellen måtte lese noen filer for å løse oppgaven. Hele arkivet ble sendt selv når oppgaven ikke krevde kodekontekst i det hele tatt.
Git-historikk gjør problemet større enn mappen du ser foran deg. En API-nøkkel som ble slettet fra siste versjon for flere måneder siden, kan fortsatt ligge i en gammel commit. Cereblab fant slike slettede hemmeligheter i den fangede pakken og gjentok forsøket på et annet kodearkiv. En separat reproduksjon omfattet 269 objekter og 219 MB. Dette var altså ikke bare én rar testmappe som oppførte seg merkelig.
Det passer dårlig med forventningen de fleste har til en kodeagent. Claude Code, Codex og Gemini sender også kode til skytjenester når modellene skal arbeide med den, men Cereblabs sammenligning fant at de åpnet og sendte enkeltfiler agenten faktisk brukte. Grok Build sendte hele repositoriet med historikken. Forskjellen er ikke «lokal mot sky». Den er nødvendig tilgang mot alt den kunne få tak i.
Hvorfor stoppet ikke personvernvalget opplastingen?
Personvernvalget styrte lagring, ikke overføring. Da «Improve the model» ble slått av, viste nettverkstrafikken fortsatt at Grok Build sendte kode og sporingsdata ut av maskinen. Den nye /privacy-kommandoen setter feltet codingDataRetentionOptOut på serveren. I Cereblabs A/B-test var forespørslene ellers de samme med valget av og på.
SpaceXAI skrev i sin offentlige uttalelse om datalagringen at kunder med zero data retention ikke får kode- og sporingsdata lagret. Selskapet opplyste også at /privacy kan slå av lagring og slette data som allerede er synkronisert for brukeren. Det kan være nyttig, men det er ikke det samme som at dataene aldri forlater maskinen.
Det som faktisk stanset opplastingen av hele kodearkiver, var en global serverinnstilling kalt disable_codebase_upload. Da den ble satt til true, sluttet samme klient å sende Git-pakken. Cereblab testet senere Grok Build 0.2.99 og fant at full opplasting fortsatt var slått av. Endringen gjaldt uansett hvilket personvernvalg brukeren hadde valgt.
Dette skillet høres teknisk ut, men er egentlig ganske enkelt. «Jeg sender dataene dine, men lover å ikke beholde dem» er noe annet enn «jeg sender dem ikke». For en vanlig chat kan en serverstyrt sletteregel være godt nok. For privat kildekode, kundeinformasjon og nøkler som åpner skytjenester, er det en vesentlig forskjell. Et personvernvalg bør beskrive hva det faktisk kontrollerer.
Hva har Elon Musk lovet å slette?
Elon Musk sier at alle brukerdata som ble lastet opp før opplastingen av hele kodearkiver ble stoppet, skal slettes fullstendig. I svaret om den varslede slettingen skrev han at ingenting overhodet skal bli igjen. Løftet går dermed lenger enn at hver bruker må finne fram /privacy og be om sletting selv.
Problemet er at et løfte om sletting ikke kan kontrolleres utenfra. The Register, som omtalte saken 14. juli, kunne heller ikke verifisere at dataene faktisk var borte. Det betyr ikke at løftet er tomt. Det betyr at brukeren fortsatt må behandle eventuelle nøkler og tokens som om de kan ha vært eksponert.
Musk ba samtidig brukerne fortsette å dele noe data fordi det hjelper med feilsøking. Det er et helt legitimt ønske for et produkt i tidlig beta, så lenge valget er tydelig og frivillig. SpaceXAI lanserte Grok Build som tidlig beta 25. mai 2026. Beta forklarer at ting kan ryke. Det forklarer ikke hvorfor standarden var å pakke hele kodearkivet når en enkelt fil eller ingen fil var nødvendig.
Det er også viktig å ikke hoppe fra dokumentert opplasting til udokumenterte påstander. Analysen viser ikke at SpaceXAI publiserte repositoriene, solgte innholdet eller trente Grok på det. Den viser at selskapet mottok langt mer enn brukeren med rimelighet kunne forvente. Tillit ryker ofte i akkurat det gapet mellom hva programmet gjør, og hva grensesnittet får deg til å tro at det gjør.
Hva bør tidligere Grok Build-brukere gjøre nå?
Har du brukt Grok Build på et privat kodearkiv før full opplasting ble stoppet 13. juli, bør du først kartlegge hvilke hemmeligheter som fantes i arbeidsmappen og Git-historikken. Aktive API-nøkler, deploy-tokens, databasepassord og SSH-nøkler bør roteres eller tilbakekalles. Ikke vent på bevis for misbruk. En ny nøkkel er billigere enn å finne ut hvor langt en gammel nøkkel rakk etterpå.
Sjekk deretter logger hos tjenestene nøklene ga tilgang til. Se etter ukjente innlogginger, API-kall, ressursbruk og regninger. Hvis kodearkivet tilhører en kunde eller arbeidsgiver, må hendelsen håndteres etter avtalene og rutinene som gjelder der. Et løfte fra leverandøren fjerner ikke behovet for å vite hvilke data som kan ha forlatt maskinen.
Kjør også /privacy hvis du fortsatt bruker Grok Build og ikke vil at SpaceXAI skal lagre kode- og sporingsdata. Men ikke les kommandoen som en lokal brannmur. Forskerens test viser at den styrer serverens lagring etter overføring. Den globale sperren har stanset full opplasting av kodearkivet, mens filer modellen faktisk leser fortsatt må sendes til skymodellen for at den skal kunne arbeide med dem.
Til slutt bør hemmeligheter ut av kodearkivet, også når filen står i .gitignore. Git ignorerer nye filer, men visker ikke automatisk bort gamle commits. Jeg har tidligere skrevet om hvordan API-nøkler blir stjålet fra AI-agenter. Denne saken er en ny påminnelse om at en kodeagent har samme tilgang som prosessen den kjører som. Den trenger ikke være ondsinnet for å gjøre skade. En dårlig standardinnstilling holder lenge.
Betyr dette at Grok Build er ubrukelig?
Nei, men hendelsen endrer hvor mye tillit verktøyet har gjort seg fortjent til. Full opplasting er slått av, og forskeren bekrefter at den ikke lenger skjer i de gjentatte testene. Grok Build er fortsatt en kodeagent som kan planlegge arbeid, vise endringer som diff, kjøre i terminalen og bruke subagenter. Den offisielle Grok Build-dokumentasjonen viser også støtte for scripts, bots og Agent Client Protocol.
Jeg har tidligere sett på plugin-markedsplassen og utvidelsene i Grok Build. Det gjør denne hendelsen ekstra relevant. Jo flere plugins, hooks, MCP-servere og arbeidsflyter en kodeagent får tilgang til, desto viktigere blir en presis grense for hva som sendes videre. Nyttige funksjoner og en dårlig datastandard kan godt finnes i samme produkt samtidig.
Modellen bak Grok Build kan dessuten brukes uten selve CLI-en. Grok 4.5 finnes via xAI API og OpenRouter, noe jeg har gått gjennom i oversikten over Grok 4.5, pris og API-tilgang. Hvis du bygger din egen agentløkke, får du mer kontroll over hvilke filer som leses og sendes. Du får også ansvaret for å sikre den kontrollen selv. Frihet og ansvar kommer dessverre fortsatt i samme pakke.
For bedrifter er konklusjonen strengere enn for et hobbyprosjekt. Ikke koble en ny kodeagent rett til produksjonskode fordi modellen skriver gode funksjoner. Start med et avgrenset testarkiv, kortlivede nøkler og logger som viser nettverkstrafikken. Sikkerheten rundt selvstendige AI-agenter og brede verktøytilganger er ikke pynt rundt produktet. Det er en del av produktet.
Den egentlige tillitsprøven kommer etter løftet
SpaceXAI reagerte raskt. Rapporten ble offentlig kjent, den globale opplastingen ble slått av, en personvernkommando kom på plass, og Musk lovet full sletting. Fra et rent skadebegrensningsperspektiv er det bedre enn uker med stillhet. Tidslinjen viser samtidig at endringen kom etter at en utenforstående hadde fanget trafikken og klonet kodepakken tilbake.
Neste steg bør derfor være en konkret teknisk redegjørelse fra selskapet: hvilke versjoner og kontoer som var berørt, hvor lenge opplastingen var aktiv, hvilke datakopier som eksisterte, når slettingen er fullført, og hvordan den blir kontrollert. «Stol på meg» er en ganske svak sikkerhetsmekanisme, også når den leveres med mange og bestemte ord.
Jeg kommer ikke til å avskrive Grok som kodeverktøy på grunn av én alvorlig hendelse. Men jeg kommer heller ikke til å late som en serverstyrt bryter og et innlegg på X nullstiller saken. En kodeagent får komme tett på noe av det mest verdifulle en utvikler eller bedrift har. Da må standarden være minst mulig data, tydelig informasjon og et reelt valg før opplasting – ikke en sletteknapp etterpå.
Ofte stilte spørsmål
Er opplastingen av hele kodearkiver stoppet?
Ja. Cereblab testet Grok Build etter at SpaceXAI satte disable_codebase_upload til true, og full opplasting sluttet å skje. Filer modellen faktisk åpner kan fortsatt sendes til skytjenesten, fordi modellen må motta innholdet for å arbeide med det.
Sletter /privacy data som allerede er sendt?
SpaceXAI sier at kommandoen slår av lagring og sletter tidligere synkroniserte data for brukeren. Den hindrer ikke nødvendigvis overføring fra maskinen. Musk har i tillegg lovet at alle tidligere opplastede brukerdata skal slettes, men slettingen er foreløpig ikke uavhengig verifisert.
Bør jeg bytte API-nøkler etter bruk av Grok Build?
Ja, hvis aktive nøkler, tokens eller passord lå i kodearkivet eller Git-historikken før full opplasting ble stoppet 13. juli 2026. Tilbakekall dem, opprett nye og kontroller logger for ukjente kall. Sletting hos leverandøren gjør ikke en tidligere eksponert nøkkel trygg igjen.
Beviser saken at xAI trente Grok på privat kode?
Nei. Nettverksanalysen dokumenterer at kodearkiver og Git-historikk ble lastet opp til skylagring. Den dokumenterer ikke at innholdet ble publisert, solgt eller brukt til modelltrening. Det er viktig å holde den bekreftede opplastingen adskilt fra spekulasjoner om senere bruk.
