Dataexfiltreringsbeteenden som motsäger "Local-First"-marknadsföringen

Forskaren identifierade ** två materiellt olika datavägar** som lämnar utvecklarens maskin :

• Modellvändningskanalen (POST /v1/responses): filer som agenten öppnade serialiserades i modellförfrågningar. Detta är det förväntade beteendet för en molnbaserad kodningsagent.
• Lagringskanalen (POST /v1/storage): hela repot paketerades oberoende som ett git-paket och laddades upp i cirka 75 MB stora bitar till en Google Cloud Storage-bucket som heter grok-code-session-traces .

Skillnaden i skala bevisade att uppladdningen inte drevs av vad agenten läste. På ett 12 GB testrepo flyttade lagringskanalen 5,10 GiB över 73 bitar (alla HTTP 200), medan modellvändningskanalen bara flyttade 192 KB — en faktor på ~27 800× . Även med prompten "svara OK, läs inte några filer" laddade verktyget upp hela repot som ett git-paket; kloning av det avlyssnade paketet återställde en fil (src/_probe/never_read_canary.txt) som agenten uttryckligen hade blivit tillsagd att inte öppna, tillsammans med hela git-commit-historiken .

Typer av hemligheter och filer som överförts utan redigering

• .env-filer som innehåller API-nycklar, databaslösenord och andra autentiseringsuppgifter överfördes ordagrant, utan maskering eller redigering genom båda kanalerna . I kontrollerade tester dök en 48 KB fil med databasautentiseringsuppgifter och API-nycklar upp i klartext i förfrågningskroppen .
• Varje spårad fil i repot, plus hela git-historiken (alla commits, grenar, taggar) paketerades och laddades upp . Detta innebär att borttagna hemligheter som committades för månader sedan men senare roterades fortfarande kan finnas i den uppladdade datan.
• Uppladdningsmekanismen identifierades som en förstaparts Rust-krat (xai-data-collector) som finns i den binära filen, med sökvägar som crates/codegen/xai-data-collector/src/gcs.rs och crates/codegen/xai-grok-shell/src/upload/ .
• I en verklig kodbas på 12 GB med slumpmässiga filer som aldrig lästes, accepterade lagringsslutpunkten uppladdningar utan någon storleksbaserad avvisning; de enda icke-200-svaren var modellanvändningskvoter (402/429), inte lagringsfel .

Opt-Out-omkopplarens misslyckande

Forskaren testade integritetsreglaget "Förbättra modellen" och fann att det inte stoppade uppladdningarna .

• Efter att ha inaktiverat reglaget och startat om, returnerade serverns inställningsslutpunkt fortfarande trace_upload_enabled: true .
• Lagringskanalen fortsatte att acceptera uppladdningar av git-paket i bitar med HTTP 200-svar .
• Ett disable_codebase_upload=true-konfigurationsalternativ finns i inställningarna, men dess relation till serverns beteende är odokumenterad, och forskarens tester visade att servern inte respekterade klientens preferenser .

Rekommenderade åtgärder för berörda utvecklare

Den ursprungliga forskaren och efterföljande analyskällor rekommenderar följande :

Omedelbara åtgärder för team som har använt Grok Build CLI på privata repos:

• Rotera alla autentiseringsuppgifter som funnits i någon .env-fil, konfigurationsfil eller git-historik inom repos som använts med Grok Build, eftersom de kan ha överförts och lagrats i grok-code-session-traces GCS-bucket .
• Granska git-historiken för hemligheter som kan ha funnits i någon tidigare commit, eftersom CLI:t skickade hela commit-historiken .
• Anta att data lagrades, inte bara överfördes — servern returnerade HTTP 200 på alla lagringsförfrågningar, vilket bekräftar acceptans .
• Fråga xAI om bucketen har raderats, vilka åtkomstkontroller som fanns och om ett databehandlingsavtal täckte den (inga publicerades vid tidpunkten för avslöjandet) .

Arkitektoniska åtgärder för alla kodningsagenter:

• Kör agenter i containrar/VM med endast aktivitetskatalogen monterad, ingen hemkatalog, ingen SSH-agent, ingen Docker-socket och inga molnära autentiseringsuppgiftskataloger exponerade .
• Implementera egresskontroll: tillåt modellinferensslutpunkter och autentiseringsvärdar, men neka direkta generiska objektlagringsuppladdningar. Varna för överföringar som överstiger 100 MB .
• Använd paketfångst på hela värden, DNS-loggnings- och slutpunktsnätverkstelemetri för att upptäcka uppladdningar av bakgrundskoordinatorprocesser som förgrundsbyte-räknare skulle missa .
• Testa minsta och maximala prompts under trådavlyssning — fall där agenten blir tillsagd att inte läsa filer är avgörande för att upptäcka exfiltrering utanför kontextfönstret .
• Kör minst tre promptfall: (1) "svara OK, läs inte några filer," (2) läs en specifik fil, (3) inspektera projektspråket — jämför sedan byte per slutpunkt .

Dataexfiltreringsbeteenden som motsäger "Local-First"-marknadsföringen

Forskaren identifierade ** två materiellt olika datavägar** som lämnar utvecklarens maskin :

• Modellvändningskanalen (POST /v1/responses): filer som agenten öppnade serialiserades i modellförfrågningar. Detta är det förväntade beteendet för en molnbaserad kodningsagent.
• Lagringskanalen (POST /v1/storage): hela repot paketerades oberoende som ett git-paket och laddades upp i cirka 75 MB stora bitar till en Google Cloud Storage-bucket som heter grok-code-session-traces .

Skillnaden i skala bevisade att uppladdningen inte drevs av vad agenten läste. På ett 12 GB testrepo flyttade lagringskanalen 5,10 GiB över 73 bitar (alla HTTP 200), medan modellvändningskanalen bara flyttade 192 KB — en faktor på ~27 800× . Även med prompten "svara OK, läs inte några filer" laddade verktyget upp hela repot som ett git-paket; kloning av det avlyssnade paketet återställde en fil (src/_probe/never_read_canary.txt) som agenten uttryckligen hade blivit tillsagd att inte öppna, tillsammans med hela git-commit-historiken .

Typer av hemligheter och filer som överförts utan redigering

• .env-filer som innehåller API-nycklar, databaslösenord och andra autentiseringsuppgifter överfördes ordagrant, utan maskering eller redigering genom båda kanalerna . I kontrollerade tester dök en 48 KB fil med databasautentiseringsuppgifter och API-nycklar upp i klartext i förfrågningskroppen .
• Varje spårad fil i repot, plus hela git-historiken (alla commits, grenar, taggar) paketerades och laddades upp . Detta innebär att borttagna hemligheter som committades för månader sedan men senare roterades fortfarande kan finnas i den uppladdade datan.
• Uppladdningsmekanismen identifierades som en förstaparts Rust-krat (xai-data-collector) som finns i den binära filen, med sökvägar som crates/codegen/xai-data-collector/src/gcs.rs och crates/codegen/xai-grok-shell/src/upload/ .
• I en verklig kodbas på 12 GB med slumpmässiga filer som aldrig lästes, accepterade lagringsslutpunkten uppladdningar utan någon storleksbaserad avvisning; de enda icke-200-svaren var modellanvändningskvoter (402/429), inte lagringsfel .

Opt-Out-omkopplarens misslyckande

Forskaren testade integritetsreglaget "Förbättra modellen" och fann att det inte stoppade uppladdningarna .

• Efter att ha inaktiverat reglaget och startat om, returnerade serverns inställningsslutpunkt fortfarande trace_upload_enabled: true .
• Lagringskanalen fortsatte att acceptera uppladdningar av git-paket i bitar med HTTP 200-svar .
• Ett disable_codebase_upload=true-konfigurationsalternativ finns i inställningarna, men dess relation till serverns beteende är odokumenterad, och forskarens tester visade att servern inte respekterade klientens preferenser .

Rekommenderade åtgärder för berörda utvecklare

Den ursprungliga forskaren och efterföljande analyskällor rekommenderar följande :

Omedelbara åtgärder för team som har använt Grok Build CLI på privata repos:

• Rotera alla autentiseringsuppgifter som funnits i någon .env-fil, konfigurationsfil eller git-historik inom repos som använts med Grok Build, eftersom de kan ha överförts och lagrats i grok-code-session-traces GCS-bucket .
• Granska git-historiken för hemligheter som kan ha funnits i någon tidigare commit, eftersom CLI:t skickade hela commit-historiken .
• Anta att data lagrades, inte bara överfördes — servern returnerade HTTP 200 på alla lagringsförfrågningar, vilket bekräftar acceptans .
• Fråga xAI om bucketen har raderats, vilka åtkomstkontroller som fanns och om ett databehandlingsavtal täckte den (inga publicerades vid tidpunkten för avslöjandet) .

Arkitektoniska åtgärder för alla kodningsagenter:

• Kör agenter i containrar/VM med endast aktivitetskatalogen monterad, ingen hemkatalog, ingen SSH-agent, ingen Docker-socket och inga molnära autentiseringsuppgiftskataloger exponerade .
• Implementera egresskontroll: tillåt modellinferensslutpunkter och autentiseringsvärdar, men neka direkta generiska objektlagringsuppladdningar. Varna för överföringar som överstiger 100 MB .
• Använd paketfångst på hela värden, DNS-loggnings- och slutpunktsnätverkstelemetri för att upptäcka uppladdningar av bakgrundskoordinatorprocesser som förgrundsbyte-räknare skulle missa .
• Testa minsta och maximala prompts under trådavlyssning — fall där agenten blir tillsagd att inte läsa filer är avgörande för att upptäcka exfiltrering utanför kontextfönstret .
• Kör minst tre promptfall: (1) "svara OK, läs inte några filer," (2) läs en specifik fil, (3) inspektera projektspråket — jämför sedan byte per slutpunkt .