xAI: le Grok CLI 0.2.93 uploade secrets et dépôts entiers
TL;DR
- Le Grok CLI 0.2.93 transmet les fichiers .env sans rédaction: une clé test « CANARY7F3A9-SECRET-should-not-leave » est apparue verbatim dans le trafic capturé.
- L'outil uploade des dépôts entiers vers le bucket Google Cloud « grok-code-session-traces », jusqu'à 5.10 GiB en 73 chunks pour un dépôt test de 12 GB.
- Désactiver « Improve the model » ne stoppe rien: /v1/settings renvoie toujours trace_upload_enabled et upload_enabled à true, les uploads continuent à plein volume.
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.
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