Data-eksfiltreringsadfærd i modstrid med 'Lokal-først'-markedsføring

Forskeren identificerede to væsentligt forskellige datastrømme, der forlod udviklerens maskine :

• Model-turn-kanalen (POST /v1/responses): Filer, som agenten åbnede, blev serialiseret i modelanmodninger. Dette er den forventede adfærd for en cloud-baseret kodeagent.
• Opbevaringskanalen (POST /v1/storage): Hele repositoriet blev uafhængigt pakket som et git bundle og uploadet i ~75 MB store bidder til en Google Cloud Storage-bucket ved navn grok-code-session-traces .

Skala-forskellen beviste, at uploadet ikke var drevet af, hvad agenten læste. På et 12 GB test-repositorium flyttede opbevaringskanalen 5,10 GiB på tværs af 73 bidder (alle HTTP 200), mens model-turn-kanalen kun flyttede 192 KB – et ~27.800× forhold . Selv med prompten 'svar OK, læs ikke nogen filer' uploadede værktøjet hele repositoriet som et git bundle; en klon af det opfangede bundle genskabte en fil (src/_probe/never_read_canary.txt), som agenten eksplicit var blevet bedt om ikke at åbne, samt den fulde Git-commithistorik .

Typer af hemmeligheder og filer, der blev sendt uden redigering

• .env-filer indeholdende API-nøgler, databaseadgangskoder og andre legitimationsoplysninger blev sendt ordret, uden maskering eller redigering gennem begge kanaler . I kontrollerede tests optrådte en 48 KB fil med databaselegitimationsoplysninger og API-nøgler i klartekst i anmodningens brødtekst .
• Hver eneste sporede fil i repositoriet samt den fulde Git-historik (alle commits, branches, tags) blev bundlet og uploadet . Det betyder, at fjernede hemmeligheder, der blev committede for måneder siden, men senere roteret, stadig kan eksistere i de uploadede data.
• Upload-mekanismen blev identificeret som en first-party Rust crate (xai-data-collector) i binæren, med kilde-stier som crates/codegen/xai-data-collector/src/gcs.rs og crates/codegen/xai-grok-shell/src/upload/ .
• På en rigtig 12 GB kodebase med tilfældige filer, som aldrig blev læst, accepterede opbevaringsendepunktet uploads uden nogen størrelsesbaseret afvisning; de eneste ikke-200-svar var model-brugs-kvote-fejl (402/429), ikke opbevaringsfejl .

Opt-out-kontaktens svigt

Forskeren testede privatlivskontakten 'Forbedr modellen' og fandt, at den ikke stoppede uploads .

• Efter at have slået kontakten fra og genstartet, returnerede serverens indstillingsendepunkt stadig trace_upload_enabled: true .
• Opbevaringskanalen fortsatte med at acceptere chunkede git-bundle-uploads med HTTP 200-svar .
• En disable_codebase_upload=true konfigurationsindstilling findes i harness-indstillingerne, men dens forhold til server-side-adfærd er udokumenteret, og forskerens tests viste, at serveren ikke respekterede klient-side-præferencer .

Anbefalede afværgeforanstaltninger for berørte udviklere

Den oprindelige forsker og efterfølgende analysemedier anbefaler følgende :

Øjeblikkelige handlinger for teams, der har brugt Grok Build CLI på private repositorier:

• Roter alle legitimationsoplysninger, der har eksisteret i en .env-fil, konfigurationsfil eller Git-historik inden for repositorier brugt med Grok Build, da de kan være blevet sendt og gemt i grok-code-session-traces GCS-bucketen .
• Gennemgå Git-historikken for hemmeligheder, der kan have eksisteret i tidligere commits, da CLI'en sendte hele commithistorikken .
• Antag, at data blev gemt, ikke kun sendt – serveren returnerede HTTP 200 på alle opbevaringsanmodninger, hvilket bekræfter accept .
• Spørg xAI, om bucketen er blevet slettet, hvilke adgangskontroller der var, og om en databehandlingsaftale (DPA) dækkede den (ingen var offentliggjort på offentliggørelsestidspunktet) .

Arkitektoniske afværgeforanstaltninger for enhver kodeagent:

• Kør agenter i containere/VM'er med kun opgavemappen monteret, ingen hjemmemappe, ingen SSH-agent, ingen Docker-socket og ingen cloud-legitimationsmapper udsat .
• Implementer egress-kontrol: Tillad model-inferens-endepunkter og autentificeringsværter, men nægt direkte generiske objektlager-uploads. Advar ved overførsler, der overstiger 100 MB .
• Brug fuld host-pakkefangst, DNS-logning og endpoint-netværkstelemetri til at opdage uploads af baggrundskoordinatorprocesser, som byte-tællere i forgrunden ville gå glip af .
• Test minimum- og maximum-prompts under wire-fangst – tilfælde, hvor agenten bliver bedt om ikke at læse filer, er afgørende for at opdage eksfiltration ud over kontekstvinduet .
• Kør mindst tre prompt-tilfælde: (1) 'svar OK, læs ikke nogen filer', (2) læs én specifik fil, (3) inspicer projektets sprog – og sammenlign derefter bytes pr. endepunkt .

Data-eksfiltreringsadfærd i modstrid med 'Lokal-først'-markedsføring

Forskeren identificerede to væsentligt forskellige datastrømme, der forlod udviklerens maskine :

• Model-turn-kanalen (POST /v1/responses): Filer, som agenten åbnede, blev serialiseret i modelanmodninger. Dette er den forventede adfærd for en cloud-baseret kodeagent.
• Opbevaringskanalen (POST /v1/storage): Hele repositoriet blev uafhængigt pakket som et git bundle og uploadet i ~75 MB store bidder til en Google Cloud Storage-bucket ved navn grok-code-session-traces .

Skala-forskellen beviste, at uploadet ikke var drevet af, hvad agenten læste. På et 12 GB test-repositorium flyttede opbevaringskanalen 5,10 GiB på tværs af 73 bidder (alle HTTP 200), mens model-turn-kanalen kun flyttede 192 KB – et ~27.800× forhold . Selv med prompten 'svar OK, læs ikke nogen filer' uploadede værktøjet hele repositoriet som et git bundle; en klon af det opfangede bundle genskabte en fil (src/_probe/never_read_canary.txt), som agenten eksplicit var blevet bedt om ikke at åbne, samt den fulde Git-commithistorik .

Typer af hemmeligheder og filer, der blev sendt uden redigering

• .env-filer indeholdende API-nøgler, databaseadgangskoder og andre legitimationsoplysninger blev sendt ordret, uden maskering eller redigering gennem begge kanaler . I kontrollerede tests optrådte en 48 KB fil med databaselegitimationsoplysninger og API-nøgler i klartekst i anmodningens brødtekst .
• Hver eneste sporede fil i repositoriet samt den fulde Git-historik (alle commits, branches, tags) blev bundlet og uploadet . Det betyder, at fjernede hemmeligheder, der blev committede for måneder siden, men senere roteret, stadig kan eksistere i de uploadede data.
• Upload-mekanismen blev identificeret som en first-party Rust crate (xai-data-collector) i binæren, med kilde-stier som crates/codegen/xai-data-collector/src/gcs.rs og crates/codegen/xai-grok-shell/src/upload/ .
• På en rigtig 12 GB kodebase med tilfældige filer, som aldrig blev læst, accepterede opbevaringsendepunktet uploads uden nogen størrelsesbaseret afvisning; de eneste ikke-200-svar var model-brugs-kvote-fejl (402/429), ikke opbevaringsfejl .

Opt-out-kontaktens svigt

Forskeren testede privatlivskontakten 'Forbedr modellen' og fandt, at den ikke stoppede uploads .

• Efter at have slået kontakten fra og genstartet, returnerede serverens indstillingsendepunkt stadig trace_upload_enabled: true .
• Opbevaringskanalen fortsatte med at acceptere chunkede git-bundle-uploads med HTTP 200-svar .
• En disable_codebase_upload=true konfigurationsindstilling findes i harness-indstillingerne, men dens forhold til server-side-adfærd er udokumenteret, og forskerens tests viste, at serveren ikke respekterede klient-side-præferencer .

Anbefalede afværgeforanstaltninger for berørte udviklere

Den oprindelige forsker og efterfølgende analysemedier anbefaler følgende :

Øjeblikkelige handlinger for teams, der har brugt Grok Build CLI på private repositorier:

• Roter alle legitimationsoplysninger, der har eksisteret i en .env-fil, konfigurationsfil eller Git-historik inden for repositorier brugt med Grok Build, da de kan være blevet sendt og gemt i grok-code-session-traces GCS-bucketen .
• Gennemgå Git-historikken for hemmeligheder, der kan have eksisteret i tidligere commits, da CLI'en sendte hele commithistorikken .
• Antag, at data blev gemt, ikke kun sendt – serveren returnerede HTTP 200 på alle opbevaringsanmodninger, hvilket bekræfter accept .
• Spørg xAI, om bucketen er blevet slettet, hvilke adgangskontroller der var, og om en databehandlingsaftale (DPA) dækkede den (ingen var offentliggjort på offentliggørelsestidspunktet) .

Arkitektoniske afværgeforanstaltninger for enhver kodeagent:

• Kør agenter i containere/VM'er med kun opgavemappen monteret, ingen hjemmemappe, ingen SSH-agent, ingen Docker-socket og ingen cloud-legitimationsmapper udsat .
• Implementer egress-kontrol: Tillad model-inferens-endepunkter og autentificeringsværter, men nægt direkte generiske objektlager-uploads. Advar ved overførsler, der overstiger 100 MB .
• Brug fuld host-pakkefangst, DNS-logning og endpoint-netværkstelemetri til at opdage uploads af baggrundskoordinatorprocesser, som byte-tællere i forgrunden ville gå glip af .
• Test minimum- og maximum-prompts under wire-fangst – tilfælde, hvor agenten bliver bedt om ikke at læse filer, er afgørende for at opdage eksfiltration ud over kontekstvinduet .
• Kør mindst tre prompt-tilfælde: (1) 'svar OK, læs ikke nogen filer', (2) læs én specifik fil, (3) inspicer projektets sprog – og sammenlign derefter bytes pr. endepunkt .