Grok Build CLI envoyait des dépôts Git entiers vers le stockage xAI par défaut

De quoi s’agit-il ?

Le 12 juillet 2026, un chercheur publiant sous le nom de cereblab a diffusé une analyse au niveau réseau du CLI de codage Grok Build de xAI (version 0.2.93), relayée par The Hacker News le 14 juillet. Il ne s’agit pas d’un exploit distant mais d’une exposition de données liée au comportement par défaut : Grok Build téléversait l’intégralité du dépôt Git suivi et tout son historique de commits vers un bucket Google Cloud Storage exploité par xAI — et non les seuls fichiers nécessaires à la tâche. Les captures établissent la transmission, l’acceptation et le stockage du code ; elles n’affirment pas que xAI l’a utilisé pour l’entraînement ni que des employés l’ont consulté.

Le sujet intéresse nos lecteurs car il illustre concrètement un problème plus large : les agents de codage cloud ne sont pas « local-first », et le réglage que la plupart des développeurs croient protecteur — l’option anti-entraînement — régit tout autre chose.

Comment ça marche

Tout agent de codage cloud doit envoyer du code source à un modèle distant pour fonctionner ; ce canal-là est attendu. Le problème tient à l’ampleur de ce qui a quitté la machine et au canal emprunté.

Le chercheur a instrumenté le CLI et séparé deux canaux. Sur un dépôt de test de 12 Go composé de fichiers que le modèle n’a jamais ouverts, le trafic « model-turn » vers /v1/responses atteignait environ 192 Ko, tandis qu’un canal de stockage distinct vers /v1/storage déplaçait environ 5,10 Gio — un écart d’environ 27 800× entre ce dont le modèle avait besoin et ce qui a été téléversé. Le transfert s’est fait en 73 blocs d’environ 75 Mo, chacun renvoyant un HTTP 200, et son volume suivait la taille totale du dépôt. Le bucket de destination, grok-code-session-traces, était nommé dans le binaire comme dans un fichier metadata.json préparé.

Pour prouver le caractère indiscriminé du téléversement, le chercheur a planté un fichier-témoin jamais lu (src/_probe/never_read_canary.txt) porteur d’un marqueur unique, a explicitement demandé à l’agent de ne pas l’ouvrir, puis a cloné le bundle Git extrait de la requête interceptée et récupéré le témoin à l’identique, avec l’historique complet du dépôt. Un second dépôt sans lien avec le premier a reproduit le résultat.

Un autre chemin, plus simple, concerne les secrets : lorsque Grok lisait un fichier durant une tâche, son contenu entrait dans le « model turn », et un .env suivi partait sans expurgation (valeurs API_KEY et DB_PASSWORD factices plantées), pour finir aussi dans une archive session_state destinée au stockage.

Point crucial : le réglage que la plupart des développeurs auraient activé ne servait à rien. « Improve the model » désactivé, Grok téléversait quand même le dépôt, et la réponse /v1/settings du serveur continuait de renvoyer trace_upload_enabled: true. Ce commutateur régit le fait que vos données entraînent le modèle — pas le fait que votre code quitte la machine. Ce sont deux contrôles distincts, et un seul était exposé à l’utilisateur.

Pourquoi c’est important

Un dépôt, c’est bien plus que son arbre de travail courant. Il peut contenir du code propriétaire, des URL internes, des données clients et des identifiants retirés de l’arbre de travail mais toujours présents dans l’historique de commits. Téléverser l’ensemble du dépôt suivi et son historique constitue une frontière bien plus large que l’envoi des quelques fichiers ouverts par une tâche. Dans la comparaison inter-outils du chercheur, Claude Code et Codex n’envoyaient aucun bundle de dépôt, et Gemini n’en envoyait pas lors d’un test à vide ; Grok Build faisait exception. Tous restent des outils cloud qui transmettent les fichiers qu’ils ouvrent — « local uniquement » est donc le mauvais modèle mental pour n’importe quel agent de codage — mais la collecte en bloc de l’espace de travail était ici propre à Grok Build.

Défenses

Faites d’abord tourner vos identifiants. Si vous avez utilisé l’outil, changez tout ce que Grok a pu envoyer : ce qu’il a lu, ce qui figure dans un fichier suivi, et ce qui se trouve dans l’historique Git transporté par le bundle — y compris un secret jadis commité puis supprimé. Supprimer un fichier ne l’efface pas de l’historique.

Utilisez le vrai contrôle de données, pas l’option d’entraînement. Pour les abonnés individuels Grok, le contrôle annoncé par xAI consiste à lancer /privacy dans le CLI pour désactiver la conservation et supprimer les données déjà synchronisées ; les équipes entreprise en « zero data retention » (ZDR) sont décrites comme n’ayant jamais eu de code ni de traces stockés. Vérifiez le comportement par vous-même plutôt que de vous fier à une option d’entraînement, qui ne régit pas l’exfiltration.

Gardez les secrets hors des fichiers suivis et de l’historique. Utilisez un gestionnaire de secrets et l’injection par variables d’environnement plutôt que des .env commités, ajoutez les secrets au .gitignore avant le premier commit, et scannez puis purgez l’historique des identifiants déjà commités.

Traitez le trafic sortant de l’agent comme une frontière. Quand c’est possible, surveillez au niveau réseau ce qu’un agent de codage envoie réellement, préférez les outils qui ne transmettent que les fichiers nécessaires à une tâche, et gardez à l’esprit qu’un chemin de collecte désactivé par un simple drapeau serveur peut être réactivé sans mise à jour du client.

Statut

Élément	Référence	Notes
Divulgation	Analyse réseau de cereblab, 2026-07-12	CLI Grok Build 0.2.93 ; téléversement dépôt + historique vers grok-code-session-traces
Couverture	The Hacker News, 2026-07-14	Confirme la séparation des canaux, la récupération du témoin, le .env non expurgé
Réponse éditeur	xAI / @SpaceXAI / E. Musk, sur X	Coupure côté serveur le 2026-07-13 ; /privacy pour les particuliers ; ZDR en entreprise ; suppression promise mais non vérifiée indépendamment
Code latent	Analyse du build 0.2.99	Code de téléversement toujours présent dans le binaire, bloqué par un drapeau serveur — réactivable sans mise à jour
Classification	Exposition de données / vie privée	Pas de CVE ; les captures montrent transmission et stockage, pas d’entraînement

La leçon durable est une question de gouvernance : un bouton « ne pas entraîner sur mes données » n’est pas la garantie que votre code reste sur votre machine. Pour tout agent de codage cloud, traitez la sortie du dépôt comme une surface de contrôle à part entière, gardez les identifiants hors de l’historique suivi, et vérifiez ce qui quitte réellement la machine.