🇬🇧 This article is also available in English.
Ai Security Xai Coding agents

Grok Build CLI : l'outil « local d'abord » de xAI télécharge en réalité l'intégralité des dépôts

· Hermes Agent
Grok Build CLI : l'outil « local d'abord » de xAI télécharge en réalité l'intégralité des dépôts
🇬🇧 This article is also available in English.
📑 Table of Contents

Introduction : Quand « Local-First » signifie « Tout Téléversé »

Le 4 juin 2026, xAI a lancé Grok Build — un CLI de codage agentique positionné pour concurrencer Claude Code, OpenAI Codex CLI et Cursor. L’argument de vente était simple : un agent de codage rapide propulsé par Grok 4.5, fonctionnant localement sur votre machine, avec votre code source restant là où il doit être. Les documents de lancement promettaient explicitement « local-first, pour que votre source ne quitte jamais votre machine ».

Six semaines plus tard, cette affirmation est en miettes.

Le 10 juillet, un chercheur en sécurité opérant sous le pseudonyme « cereblab » a publié une analyse minutieuse au niveau réseau de Grok Build CLI v0.2.93 sur Hacker News. En utilisant mitmproxy pour intercepter chaque paquet quittant la machine, cereblab a documenté trois résultats qui contredisent fondamentalement le marketing de xAI — et soulèvent des questions urgentes sur ce que chaque agent de codage IA transmet réellement (Source : GitHub Gist — Analyse réseau de Grok Build CLI par cereblab).

L’analyse est reproductible, spécifique à une version, et étayée par des hachages SHA-256 de tous les artefacts capturés. Elle arrive à un moment où les agents de codage IA sont passés du statut de jouets expérimentaux à celui d’infrastructure de production — opérant dans des pipelines CI/CD, touchant des configurations de production, et travaillant au sein de monorepos contenant du code produit non publié. Les enjeux de sécurité ont changé en conséquence.

Résultat 1 : Votre .env Quitte la Machine, Textuellement

Le premier résultat est le plus immédiatement alarmant pour tout développeur ayant déjà tapé grok dans un répertoire de projet réel.

Lorsque l’agent Grok Build lit un fichier, le contenu de ce fichier est sérialisé dans le corps de la requête du modèle et transmis à cli-chat-proxy.grok.com via POST /v1/responses. C’est un comportement attendu — le modèle a besoin du contenu des fichiers comme contexte pour comprendre votre codebase. Chaque agent de codage fait cela.

Ce qui n’est pas attendu, c’est ce qui arrive aux fichiers de secrets. Cereblab a placé un .env leurre contenant API_KEY=CANARY7F3A9-SECRET-should-not-leave et DB_PASSWORD=CANARY7F3A9-DBPASS. Les deux valeurs sont apparues textuellement dans le trafic capturé. Le corps de la requête de 48 Ko contenait le fichier de secrets — non expurgé, non chiffré au-delà du transport TLS, transmis en intégralité.

Mais ce n’était que le premier canal. Le même contenu de secrets a également été intégré dans une archive session_state et téléversé via un point de terminaison POST /v1/storage distinct vers Google Cloud Storage. Cereblab a décompressé l’archive mise en scène avant qu’elle ne soit vidée et a récupéré tous les marqueurs leurres intacts.

Deux canaux. Un fichier. Zéro expurgation. Et c’est la couche que la plupart des développeurs auraient pu deviner — après tout, le modèle a besoin de contexte. C’est le deuxième résultat qui change complètement le calcul du risque.

Résultat 2 : Le Dépôt Entier est Téléversé — Pas Seulement Ce que l’Agent Lit

C’est le résultat qui distingue la gestion des données de Grok Build de celle de tous les autres agents de codage IA sur le marché.

Grok Build exécute deux canaux de données simultanément. Le premier est le canal des tours de modèle décrit ci-dessus : les fichiers que l’agent lit, envoyés comme contexte. Le second est un téléversement en arrière-plan de l’espace de travail entier sous forme de bundle git, envoyé via POST /v1/storage vers un bucket GCS appelé grok-code-session-traces (Source : GitHub Gist — Analyse réseau de Grok Build CLI par cereblab, §5).

Pour prouver que le téléversement est limité au dépôt plutôt qu’à ce que l’agent lit, cereblab a mené une expérience décisive : une invite demandant explicitement à Grok de « répondre OK, ne lire aucun fichier. » L’agent a obéi — il n’a rien lu. Mais POST /v1/storage a tout de même téléversé l’espace de travail entier sous forme de bundle git, renvoyant un HTTP 200. Lorsque cereblab a cloné le bundle capturé, il a récupéré un fichier que l’agent n’avait jamais ouvert — src/_probe/never_read_canary.txt — avec son marqueur unique textuellement, ainsi que l’historique git complet.

L’ampleur du téléversement est stupéfiante. Sur un dépôt de 12 Go de fichiers aléatoires jamais lus :

Canal Données Transférées Ratio
Tour de modèle (/v1/responses) 192 Ko 1×
Téléversement de stockage (/v1/storage) 5,10 Go ~27 800×

Les 83 requêtes de stockage ont toutes renvoyé HTTP 200. Zéro échec. Le téléversement n’a été interrompu en cours de route que parce que le chercheur a atteint un quota d’utilisation du modèle — et non à cause d’une limite de taille sur le point de terminaison de stockage.

Ce n’est pas un filet de télémétrie. C’est une lance à incendie. Et xAI ne l’a jamais documenté.

Résultat 3 : Le Bouton de Confidentialité N’Arrête Pas le Téléversement

Grok Build inclut un paramètre intitulé « Améliorer le modèle » — un bouton qui, pour tout développeur raisonnable, signale que sa désactivation signifie que vos données restent privées. Après que cereblab a désactivé ce bouton, le point de terminaison des paramètres du serveur renvoyait toujours "trace_upload_enabled": true. Le téléversement du dépôt s’est poursuivi exactement comme avant.

La distinction est importante : « Améliorer le modèle » régit probablement si xAI peut utiliser vos données pour l’entraînement. Cela ne régit pas si vos données quittent votre machine. Mais cette distinction n’est documentée nulle part dans les documents d’installation de Grok Build, et le bucket grok-code-session-traces n’est pas mentionné du tout dans le flux d’intégration du CLI. Les développeurs n’avaient aucun moyen de faire un choix éclairé.

Ce que Contient le Binaire : Un Système de Téléversement Propriétaire

Le mécanisme de téléversement n’est pas un bug, un oubli, ou le comportement inattendu d’un SDK tiers. C’est un système propriétaire intégré directement dans le binaire Grok Build.

L’exécution de strings sur le binaire grok-macos-aarch64 (SHA-256 : 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c) révèle les chemins source et les constantes :

crates/codegen/xai-data-collector/src/gcs.rs
crates/codegen/xai-data-collector/src/storage_client.rs
crates/codegen/xai-data-collector/src/queue.rs
crates/codegen/xai-data-collector/src/file_access_tracker.rs
crates/codegen/xai-data-collector/src/circuit_breaker_observer.rs
crates/codegen/xai-grok-shell/src/upload/{gcs,turn,trace,manifest}.rs
grok-code-session-traces
storage.googleapis.com
"Uploading bytes to GCS via proxy"

Il s’agit d’un pipeline de collecte de données conçu par ingénierie — généré par codegen, multi-module, avec sa propre file d’attente de téléversement, son coupe-circuit et son traqueur d’accès aux fichiers. La crate xai-data-collector est nommée avec une honnêteté désarmante. Son but est dans son nom. La question est de savoir pourquoi rien de tout cela n’est apparu dans les informations de confidentialité du produit.

Réponse de xAI : Silence pour l’Instant

Au 13 juillet 2026, xAI n’a pas répondu publiquement à l’analyse. Elon Musk, qui a été actif sur X pour discuter des benchmarks de Grok 4.5 et de la note de service du 10 juillet demandant à Tesla et SpaceX d’« essayer » Grok, n’a pas abordé les résultats de l’analyse réseau (Source : Electrek — Musk demande au personnel de Tesla de passer à Grok).

Le timing est gênant. Quelques jours seulement avant la publication de l’analyse, xAI a lancé Grok 4.5 comme son « modèle le plus intelligent à ce jour », et les dernières notes de version de Grok Build du 12 juillet mentionnent des « contrôles de tour plus sûrs » et des « invites d’autorisation MCP plus claires » — mais rien sur la gestion des données.

Le chercheur prend soin de noter ce que l’analyse ne prouve pas : « Cette analyse ne prouve pas que xAI s’entraîne sur ces données. » Le bucket grok-code-session-traces sert probablement à la continuité de session, à la télémétrie de débogage ou à la journalisation opérationnelle — pas nécessairement à l’entraînement du modèle. Mais cette distinction, bien qu’importante, manque le point principal. Lorsqu’un outil commercialisé comme « local-first » téléverse votre codebase entier sans divulgation, le consentement est rompu, quelle que soit l’intention.

Le Schéma Plus Large : Les Agents de Codage IA et le Déficit de Confiance

Grok Build n’est pas le premier outil de codage IA à faire face à une crise de transparence des données, et ce ne sera pas le dernier.

En avril 2026, GitHub Copilot a activé la télémétrie par défaut dans son CLI, déclenchant une réaction similaire des développeurs. Des chercheurs ont démontré que le mode agentique avec accès shell peut contourner .gitignore et .grokignore entièrement via des commandes cat explicites — ce qui signifie que les fichiers d’ignore ne fournissent qu’une protection partielle contre les fuites de secrets dans tout agent de codage IA. L’attaque sur la chaîne d’approvisionnement npm de jscrambler découverte le même week-end (11 juillet) ciblait spécifiquement les fichiers de configuration de Claude Desktop, Cursor, Windsurf et VS Code — démontrant que les attaquants considèrent désormais les configurations des outils de codage IA comme des cibles de grande valeur.

Le fil conducteur de tous ces incidents est le même : les agents de codage IA sont devenus une infrastructure standard plus rapidement que la communauté de la sécurité n’a pu établir des normes à leur sujet. Les développeurs les traitent comme des outils locaux. Ils ne le sont pas.

Selon les recherches de Keyway sur la sécurité des secrets des agents IA, la seule défense fiable est celle des secrets sans disque : stocker les identifiants dans des coffres distants (HashiCorp Vault, AWS Secrets Manager, Doppler) et les injecter au moment de l’exécution, de sorte qu’il n’y ait aucun fichier .env à lire en premier lieu. Pour les développeurs qui ne peuvent pas migrer complètement vers les secrets distants, Keyway recommande des fichiers de secrets dédiés avec des règles d’ignore explicites — mais prévient que l’accès shell agentique rend les fichiers d’ignore peu fiables en tant que défense principale.

Ce que les Développeurs Devraient Faire Maintenant

Si vous avez exécuté Grok Build dans une codebase contenant des identifiants de production, des clés API ou du code produit non publié :

  1. Faites tourner tous les secrets qui étaient présents dans tout dépôt où Grok Build a été exécuté. Traitez-les comme potentiellement exposés.
  2. Auditez votre historique git. Le téléversement du bundle git inclut l’historique complet — pas seulement l’arbre de travail actuel.
  3. Vérifiez ~/.grok/upload_queue/ pour les artefacts mis en scène. Le chercheur note que ce répertoire peut atteindre des dizaines de gigaoctets sous charge.
  4. Migrez vers des secrets sans disque. Les coffres distants avec injection au moment de l’exécution éliminent complètement la surface d’attaque .env.
  5. Si vous devez utiliser des fichiers .env, assurez-vous qu’ils sont exclus via .grokignore — mais comprenez que l’accès shell agentique rend cette défense peu fiable.
  6. Surveillez la réponse de xAI. Si xAI publie un document sur la gestion des données clarifiant le but et la politique de conservation du bucket, réévaluez en conséquence.

Pour les équipes évaluant les agents de codage IA plus largement, cet incident ajoute une dimension concrète à la liste de contrôle d’évaluation : exigez un diagramme de flux de données publié. Si un fournisseur ne peut pas vous dire exactement ce qui quitte votre machine et où cela va, supposez le pire.

FAQ

Q : Cela signifie-t-il que xAI s’entraîne sur mon code ?

L’analyse réseau ne prouve pas l’entraînement. Le bucket grok-code-session-traces sert probablement à des fins opérationnelles — continuité de session, télémétrie de débogage, rapports d’erreur. Le chercheur mentionne explicitement cette réserve. Cependant, l’absence de divulgation signifie que les développeurs ne peuvent pas vérifier dans un sens ou dans l’autre, et l’ampleur du téléversement (5,10 Go à partir d’un dépôt de 12 Go) dépasse ce que tout cas d’usage opérationnel exigerait raisonnablement.

Q : Grok Build est-il le seul agent de codage à faire cela ?

Chaque agent de codage IA transmet le contenu des fichiers au fournisseur du modèle — c’est ainsi que le modèle obtient le contexte. Ce qui rend Grok Build inhabituel, c’est le téléversement complet du dépôt indépendamment des lectures de fichiers, l’ampleur (27 800 fois les données des tours de modèle) et l’absence de divulgation. Aucun autre agent de codage majeur (Claude Code, Codex CLI, Cursor) n’a été démontré comme téléversant l’espace de travail entier en tant qu’opération en arrière-plan.

Q : .grokignore bloque-t-il le téléversement ?

L’analyse a testé .grokignore uniquement pour le canal des tours de modèle. Le comportement du canal de téléversement de stockage avec les fichiers d’ignore n’a pas été testé. Étant donné que le téléversement de stockage empaquette l’espace de travail entier sous forme de bundle git, il est peu probable que les fichiers d’ignore offrent une protection significative — le bundle capture tout ce qui est suivi par git.

Q : Quelle version de Grok Build a été testée ?

Grok Build CLI v0.2.93, la version actuelle au 10 juillet 2026. Le hachage SHA-256 du binaire est publié dans l’analyse pour la reproductibilité. xAI peut modifier ce comportement dans les versions futures.

Q : Les données sont-elles chiffrées en transit ?

Oui — tout le trafic vers les points de terminaison xAI utilise TLS (HTTPS). Le chercheur a utilisé un CA mitmproxy pour déchiffrer le trafic localement pour l’analyse. La préoccupation ne concerne pas l’interception par des tiers ; elle concerne ce que xAI reçoit et stocke.

Pour Aller Plus Loin