xAI: le Grok CLI 0.2.93 uploade secrets et dépôts entiers
TL;DR
- The 27,800x ratio between GCS storage traffic and model-inference traffic proves bulk repository upload was designed architecture, not an incidental logging side effect.
- xAI applied the fix silently via a server-side flag (disable_codebase_upload: true) with no advisory, no changelog entry, and no public disclosure on retention or deletion scope.
- The 'Improve the model' opt-out toggle had zero effect on repository transmission; a separate /v1/storage channel ran independently of user consent settings.
Un chercheur a monté un dispositif de capture réseau autour du Grok CLI 0.2.93 de xAI et a documenté, paquet par paquet, ce que l'outil renvoie effectivement chez son éditeur. Le rapport publié sur gist.github.com sépare proprement ce qui relève du modèle et ce qui relève de l'archivage de session, et c'est cette séparation qui rend les chiffres crédibles.
Trois constats en ressortent. D'abord, les fichiers .env partent sans rédaction: une clé test contenant CANARY7F3A9-SECRET-should-not-leave a été retrouvée verbatim dans le trafic capturé et dans les archives persistées. Ensuite, le CLI n'envoie pas seulement ce que l'agent lit, il uploade tout le dépôt. Sur un dépôt d'environ 12 GB, l'auteur a capturé 5.10 GiB répartis en 73 chunks d'environ 75 MB avant que le stream ne soit tronqué, sans une seule erreur côté stockage. Le canal /v1/storage a transporté 27,800× plus d'octets que le canal /v1/responses sur ce même test, ce qui, selon l'auteur, prouve que le périmètre uploadé est bien le dépôt entier et non ce que le modèle regarde. Des git bundles récupérés depuis les réponses 200 de /v1/storage, une fois clonés, ont rendu des fichiers que l'agent avait été explicitement prié de ne pas ouvrir, historique git compris. Enfin, la destination est un bucket Google Cloud nommé grok-code-session-traces sur storage.googleapis.com, cité dans les chemins binaires et dans un metadata.json capturé.
Le point qui fait basculer l'affaire du technique vers le contractuel est ailleurs. En désactivant le paramètre « Improve the model », les réponses de /v1/settings continuent de renvoyer trace_upload_enabled et upload_enabled à true, et les uploads de dépôt se poursuivent à plein volume. Le levier censé donner le contrôle à l'utilisateur, dans cette version, ne le donne pas.
L'honnête réserve est celle de la portée: l'analyse porte sur la version 0.2.93 et sur ce que l'auteur a pu capturer en un run, et rien dans le document ne dit ce qui est ensuite fait de ces archives (entraînement, débogage, ou rétention pure). Le rapport ne tranche pas non plus l'existence d'un tier entreprise qui changerait la donne, ni la réaction de xAI. Pour un responsable sécurité qui évalue un CLI d'agent sur du code propriétaire, la conclusion pratique est plus simple que le débat sur l'entraînement: la fuite est déjà dans le tuyau, indépendamment du toggle, et c'est un sujet à porter au contrat, pas au menu de préférences.
Ce qu'en disent les autres médias
-
GIGAZINE Lire →
Gigazine surfaces the inference-vs-storage channel split and confirms the 'Improve model' toggle does not gate the upload path — adds international reach to the story.
API keys and passwords read by Grok were included unprocessed in the communications used for inference.
-
International Cyber Digest Lire →
Captures the scale disparity (5.10 GiB storage vs 192 KB inference) and documents xAI's silent server-side mitigation with no advisory, no retention disclosure, and no deletion confirmation.
The tool was not sending what it needed to answer the developer. It was sending the codebase.
-
Penligent Lire →
Most technically granular coverage: separates inference vs storage channels, proves never-read canary files shipped anyway, and provides an incident-response framework for affected organizations.
A Git bundle left the machine through /v1/storage; the captured bundle could be cloned with standard Git tooling.
-
explainx.ai Lire →
Explicitly separates verified transmission facts from unproven claims (training use, employee access), and calls out xAI's documentation gap as the core product failure.
A reproducible test captured successful uploads of complete tracked Git repositories and unredacted fake secrets from a file the agent read.
-
ByteIota Lire →
Wire-level packet analysis showing the 'local-first' marketing was contradicted by observed traffic; documents that the privacy toggle does not block transmission.
5.10 gigabytes transferred in 73 chunks on a 12 GB repository — the storage channel sent 27,800 times more data than the model-turn channel.
-
BASENOR Lire →
The only source covering xAI's official response: Musk's retroactive deletion pledge and the tiered privacy structure (enterprise ZDR vs. /privacy CLI for individuals).
All user data uploaded to SpaceXAI prior to this clarification will be completely deleted — zero anything whatsoever will remain.
-
AI TLDR Lire →
Adds comparative context: Claude Code and Cursor transmit only selected file snippets; Grok Build uploaded the entire git bundle regardless of model reads.
The storage channel uploaded 5.10 GiB across 73 chunks while the model-turn channel moved only 192 KB — a ~27,800x disparity.
Shared on Bluesky by 1 AI expert
Article original publié par gist.github.com
Lire l'article original →Titre original : « Ce que le CLI Grok build de xAI envoie à xAI » : une analyse au niveau du fil révèle l'upload de secrets et de dépôts entiers