Un développeur a fait passer l'outil en ligne de commande de xAI, Grok Build CLI (version 0.2.93), à travers un proxy d'interception pour observer, paquet par paquet, ce qu'il envoie vraiment. Le constat, publié sur Reddit puis dans un gist GitHub détaillé, est sévère : au-delà des fichiers que l'agent lit, le CLI téléverse l'intégralité du dépôt — historique git complet compris — sous forme de « git bundle » vers un stockage cloud de xAI, indépendamment de ce que l'utilisateur demande. Un fichier « canari » explicitement interdit de lecture est revenu intact après reconstruction du bundle capturé, et un fichier .env contenant clés d'API et mot de passe de base de données est parti en clair. Le bouton « Improve the model » n'arrête pas ce comportement. Retestés dans les mêmes conditions, Claude Code, Codex et Gemini n'ont pas montré ce téléversement complet du dépôt. Depuis, xAI a discrètement coupé la fonction côté serveur. Voici ce que dit — et ne dit pas — cette analyse.

Ce que le test filaire a montré

L'analyse est le fait d'un chercheur signant « cereblab », qui a routé Grok Build CLI à travers mitmproxy sur macOS et publié sa méthodologie complète dans un gist GitHub, accompagné d'un dépôt de reproduction (cereblab/grok-build-exfil-repro). Le fil de discussion original a circulé sur r/LocalLLaMA puis a été repris sur Hacker News.

Le teardown distingue deux canaux d'exfiltration bien séparés, ce qui est important pour comprendre le problème.

Canal A — les fichiers lus. Quand l'agent ouvre un fichier, son contenu part vers cli-chat-proxy.grok.com via POST /v1/responses. C'est le comportement attendu d'un assistant de code hébergé : pour raisonner sur votre code, le modèle doit en recevoir des extraits. Problème : cela inclut sans filtrage les fichiers sensibles. Le chercheur a planté dans un fichier de secrets les valeurs API_KEY=CANARY7F3A9-SECRET-should-not-leave et DB_PASSWORD=CANARY7F3A9-DBPASS, et les a retrouvées verbatim dans un corps de requête capturé de 48 Ko. Aucune rédaction, aucun masquage.

Canal B — le dépôt entier. C'est le cœur de la découverte. Indépendamment des fichiers ouverts, le CLI empaquette l'espace de travail sous forme de git bundle — un format qui embarque l'historique complet des commits — et le téléverse via POST /v1/storage. Pour le prouver, le chercheur a lancé Grok avec la consigne explicite « Do not read or open any files » (« ne lis ni n'ouvre aucun fichier »), tout en plaçant dans le dépôt un fichier canari, src/_probe/never_read_canary.txt, jamais censé être touché. Après avoir extrait le bundle du trafic capturé et exécuté un simple git clone dessus, il a récupéré ce fichier intact, marqueur unique compris. Le fichier n'avait pas été lu par l'agent : il était parti parce que tout le dépôt était parti.

La preuve par le volume

L'argument le plus difficile à contester est quantitatif. Sur un dépôt de test de 12 Go composé uniquement de fichiers aléatoires que personne n'a ouverts, le canal du modèle (/v1/responses) n'a transporté que 192 Ko de données — la conversation elle-même. Dans le même temps, le canal de stockage (/v1/storage) a déplacé 5,1 Gio répartis sur des dizaines de chunks, tous en HTTP 200. Un rapport d'environ 27 800 pour 1 entre ce dont le modèle avait besoin et ce qui a quitté la machine. Ce déséquilibre massif ne s'explique pas par « les fichiers que l'agent a consultés » : il rattache l'envoi au dépôt dans son ensemble.

La destination, identifiée dans les chaînes de caractères du binaire et dans des metadata.json intermédiaires, est un bucket Google Cloud Storage nommé grok-code-session-traces — c'est-à-dire l'infrastructure cloud de xAI, mais hébergée chez Google. À noter, honnêtement : l'analyse ne prouve pas que xAI entraîne ses modèles sur ces données. Elle établit la transmission, l'acceptation et le stockage — pas l'usage qui en est fait ensuite.

Pourquoi le bouton « Improve the model » ne protège pas

Beaucoup d'utilisateurs croient se mettre à l'abri en désactivant l'option « Improve the model » (« améliorer le modèle ») dans les réglages. C'est là que réside le malentendu le plus dangereux. Ce toggle gouverne l'entraînement — l'autorisation, ou non, d'utiliser vos données pour affiner le modèle. Il ne gouverne pas le téléversement. Le chercheur a vérifié que, l'option étant désactivée, l'endpoint /v1/settings renvoyait toujours "trace_upload_enabled": true et "upload_enabled": true. Autrement dit : vous pouvez refuser que xAI s'entraîne sur votre code, votre code part quand même vers ses serveurs.

Le seul frein réellement efficace identifié dans la config était un drapeau non documenté, disable_codebase_upload = true, à placer dans la section [harness] du fichier de configuration, complété par des variables d'environnement (GROK_TELEMETRY_TRACE_UPLOAD=false, GROK_TELEMETRY_ENABLED=false). Rien de tout cela n'était mis en avant à l'installation.

La comparaison avec Claude Code, Codex et Gemini

Dans une mise à jour, le même auteur a soumis Claude Code, Codex et Gemini CLI au même protocole filaire, avec le même dépôt canari. Aucun des trois n'a reproduit le téléversement complet du dépôt : le fichier « jamais lu » n'est parti par aucun chemin équivalent au git bundle de Grok. Sur ce point précis, Grok était l'exception.

Une nuance s'impose toutefois, et le chercheur lui-même la souligne : « rester local » est une formule trompeuse. Ces trois outils sont eux aussi des agents connectés au cloud ; les fichiers qu'ils ouvrent sont bien envoyés à leurs fournisseurs respectifs pour l'inférence. La différence n'est pas « rien ne sort » contre « tout sort » : c'est « seulement ce que l'agent lit » contre « la totalité du dépôt et son historique, indépendamment de ce qui est lu ». C'est cette seconde catégorie qui distingue le comportement de Grok. Et la comparaison, comme le test initial, ne porte que sur une machine, une version de client et un chemin de compte par outil — pas sur toutes les configurations, plugins ou versions futures possibles.

La réponse discrète de xAI

Après la publication, le chercheur a rejoué six fois le même client 0.2.93 : plus aucun téléversement via /v1/storage. Le serveur renvoyait désormais "trace_upload_enabled": false et un nouveau drapeau disable_codebase_upload: true. Le binaire n'ayant pas changé de version, la correction pointe vers une modification côté serveur — une bascule de configuration à distance — et non vers un correctif client classique poussé aux utilisateurs. À ce stade, aucune communication officielle de xAI n'expliquait le comportement d'origine ni la raison de conception. La coupure a été silencieuse.

L'enjeu de confiance pour les CLI d'agents

Cet épisode dépasse le cas de Grok. Les CLI d'agents de code s'installent dans les projets les plus sensibles — code propriétaire, secrets d'infrastructure, historiques git révélant des données parfois supprimées des versions récentes mais toujours présentes dans les commits passés. Un git bundle, précisément, embarque cet historique complet : un secret purgé du HEAD mais jamais réécrit dans l'historique repart avec le bundle. Pour un développeur en entreprise, la frontière entre « l'outil consulte mon code » et « l'outil archive mon dépôt entier chez un tiers » est la différence entre un usage acceptable et une fuite de propriété intellectuelle — voire une violation de clauses contractuelles ou réglementaires.

La leçon la plus utile est donc moins « Grok est malveillant » que « la seule preuve fiable de ce qu'un outil envoie est l'observation du trafic réseau ». Sur Hacker News comme sur Reddit, la communauté a d'ailleurs convergé vers des parades défensives indépendantes de la bonne foi de l'éditeur : exécution en bac à sable (bubblewrap, conteneurs), isolation réseau par proxy filtrant, montage en lecture seule de répertoires limités. Un commentateur a précisé qu'il n'avait pas réussi à reproduire le comportement de son côté — rappel utile que ce travail reste, à ce jour, le test d'un seul chercheur, non confirmé indépendamment à grande échelle, même si sa méthodologie est publiée et rejouable. C'est justement cette transparence — un harnais de reproduction ouvert, des empreintes SHA-256, des commandes vérifiables — qui donne son poids à l'alerte, et qui manquait cruellement, elle, du côté de l'outil incriminé.