Byt ut varje hemlighet som Grok Build har sett

Filen som aldrig öppnades

Forskaren lade ut ett lockbete. En enda fil i ett testrepositorium som assistenten aldrig ombads öppna och aldrig hänvisade till: en kanariefågel. Sedan lades trafiken bakom en proxy för att se vad Grok Build, xAI:s kommandoradsverktyg för kodning, faktiskt skickade hem. Kanariefågeln kom tillbaka i det uppfångade paketet. Den hade lämnat maskinen utan att någonsin ha lästs.

Den publicerade analysen på trafiknivå av version 0.2.93 beskriver två separata kanaler. Den första är den som alla väntar sig av en molnbaserad kodassistent: en modellkanal som bär de filer agenten verkligen läser, så att den kan svara. Den andra är en bakgrundskanal för lagring som skickar en ögonblicksbild av hela arbetsytan till en lagringsbucket, oavsett om agenten tittade på de filerna eller inte.

Glappet mellan de två är själva fyndet. I ett testrepositorium på 12 gigabyte flyttade modellkanalen omkring 192 kilobyte. Bakgrundskanalen flyttade 5,10 gibibyte, i 73 delar om ungefär 75 megabyte styck. Det är en skillnad på ungefär 27 800 gånger. Den ena kanalen gjorde jobbet. Den andra kopierade hela byggnaden.

Bland filerna som gick i väg fanns en spårad .env, alltså precis den filkonvention som utvecklare använder för att förvara det som aldrig får resa någonstans: API-nycklar och databaslösenord. Den skickades ordagrant och omaskerad.

Reglaget på skärmen var inte reglaget i trafiken

Varje AI-verktyg för utvecklare levereras i dag med ett reglage som säger någon variant av "hjälp till att förbättra modellen". Det är den kontroll som inköp frågar om, som ett dataskyddsombud skriver in i bedömningen och som en utvecklingschef pekar på när någon undrar om koden är säker.

Forskaren stängde av reglaget. Sedan kontrollerades vad servern själv sa. Inställningsslutpunkten fortsatte att returnera trace_upload_enabled som true. Uppladdningarna fortsatte.

Det här är den del som är värd att skilja från rubriken. Felet var inte att en kodassistent skickar kod till en server, för det är hela premissen för en molnbaserad kodassistent och skälet till att man läser villkoren innan man installerar den. Felet är att samtyckeskontrollen och datavägen aldrig kopplades ihop. Reglaget styrde träningen. Uppladdningen gick i ett annat rör, och ingenting på skärmen nådde dit.

En kontroll som inte kontrollerar något är sämre än ingen kontroll alls, eftersom ett team som ser den slutar leta.

Rättningen på serversidan är det verkliga fyndet

Den 13 juli 2026 upphörde uppladdningarna. Det lärorika är hur. Ingen ny klientversion, ingen höjning av versionsnumret, ingen ändringslogg för användarna att granska och godkänna. Samma binär 0.2.93 slutade helt enkelt göra lagringsanrop, eftersom servern började svara med en ny flagga som stängde av uppladdningen av kodbasen. Elon Musk sade att de uppgifter som redan hade laddats upp skulle bli, med hans ord, "completely and utterly deleted", alltså fullständigt och totalt raderade.

Läs den sekvensen igen ur ett styrningsperspektiv. Programvarans beteende på era utvecklares datorer ändrades på distans, av leverantören, utan att den artefakt ni hade godkänt ens rördes. Alltså kunde den ha ändrats åt andra hållet på precis samma sätt, och det hade sett likadant ut från er sida.

Det är den strukturella lärdomen, och den gäller långt bortom xAI. Om ett verktygs databeteende avgörs av flaggor på serversidan, då säger en granskning av klienten er bara vad den gjorde den dag ni tittade. Den säger inget om vad den gör nu. Att låsa en version, läsa versionsnoterna och skriva under är en process byggd för programvara som bär sitt beteende i binären. Det gör de flesta AI-verktyg inte längre.

xAI har inte redovisat varför uppladdningarna fanns, hur länge uppgifterna sparades, vilka som kunde nå dem eller hur många användare som berördes. De fyra svaren är vad en kund behöver för att bedöma incidentens omfattning, och att de saknas är i sig information.

Vad ett europeiskt team är skyldigt sina kunder nu

Börja med det antagande som kostar minst att ha fel om: behandla varje hemlighet som har legat i ett repositorium som öppnats med Grok Build som röjd. Byt ut API-nycklar, databaslösenord, signeringsnycklar och tokens. Gör det utifrån vilka repositorier som öppnades, inte utifrån vilka filer ni tror att assistenten läste, för hela poängen med fyndet är att de två mängderna inte är desamma.

Kontrollera sedan vad mer som låg i de repositorierna. Enbart källkod är ett kommersiellt problem. Personuppgifter, eller inloggningsuppgifter till system som innehåller personuppgifter, är ett juridiskt. Enligt GDPR är en AI-leverantör som behandlar ert repositorium på ert uppdrag ett personuppgiftsbiträde, och en kopia av det repositoriet som landar i en lagringsbucket utanför det avtalade ändamålet är ett röjande som ni måste bedöma. Rör det personuppgifter är det IMY som ni i egenskap av personuppgiftsansvarig anmäler till, och fristen löper från när ni fick kännedom, inte från när leverantören rättar sitt fel.

Väsentliga och viktiga verksamhetsutövare enligt NIS2 bör hantera det här som en incident i leveranskedjan och logga den som en sådan, för det är precis vad det är: en brist i en leverantörs produkt som flyttade era uppgifter någonstans ni inte hade valt. CERT-SE hos MSB är den nationella referensen när incidenten ska bedömas och rapporteras.

Inget av detta kräver visshet om vad xAI gjorde med uppgifterna. Det kräver bara att ni just nu inte kan bevisa att det saknade betydelse.

Så köper man ett AI-kodverktyg efter det här

Den nyttiga förändringen är inte ett förbud. Team som förbjuder AI-kodassistenter rakt av upptäcker för det mesta att utvecklarna installerade en ändå, och nu loggar ingen det. Den nyttiga förändringen är att sluta behandla klienten som gränsen.

Ställ tre frågor till en leverantör innan nästa verktyg hamnar på en dator. Vilka slutpunkter talar verktyget med, och kan vi se det i vårt eget nät i stället för i er dokumentation. Kan er server ändra vad den installerade klienten skickar utan att ni släpper en ny version, och i så fall, vad talar om för oss när det sker. Om en inställning är avstängd hos oss, hur representeras den inställningen på serversidan, och får vi verifiera det själva.

Gör sedan svaren testbara i stället för avtalade. En proxy och en eftermiddag räckte för att hitta det här. Det är en billigare kontroll än vilket säkerhetsformulär som helst, och den enda som mäter beteende i stället för avsikt. Hemligheter ska för övrigt inte ligga i ett repositorium som en kodagent över huvud taget kan se: injicerade miljövariabler vid körning och en hanterad tjänst för hemligheter gör den här sortens incident till en axelryckning i stället för en läcka.

Verktygen är värda att ha. Det som inte är värt att ha är en granskningsprocess som läser etiketten och aldrig tittar på trafiken.

Läs vidare: Waferpriser stiger nu på varje avancerad nod  |  Inget AI-lab fick högre än ett C+ på säkerhet