Grok Build envoyait des dépôts vers le cloud sans le consentement des développeurs
Le 10 juillet 2026, le chercheur en sécurité connu sous le pseudonyme Cereblab a documenté un comportement problématique de Grok Build, l'assistant en ligne de commande dédié au code développé par xAI, l'entreprise d'Elon Musk. En installant un proxy réseau pour surveiller les échanges de sa machine, il a constaté que sur un dossier de travail de 12 Go, 5,1 Go de données non manipulées durant la session en cours avaient été envoyées vers un bucket hébergé sur Google Cloud, sans consentement préalable. Parmi les fichiers transférés figurait un fichier .env contenant des variables sensibles, notamment des clés d'accès à des interfaces de programmation, envoyé sans caviardage automatique des secrets. Le chercheur a identifié deux canaux distincts : un canal « modèle » limité à 192 ko de données pour les traitements, et un canal « stockage » ayant chargé les 5,1 Go restants. Même en demandant explicitement à l'outil de ne lire aucun fichier, l'envoi d'un lot complet vers Google Cloud a persisté. En reproduisant l'expérience avec Claude Code d'Anthropic, Codex d'OpenAI et Gemini de Google, Cereblab n'a constaté aucun transfert de données comparable.
Cette découverte soulève une inquiétude majeure pour les développeurs qui utilisent des assistants IA en ligne de commande sur du code sensible ou propriétaire : la confiance placée dans ces outils repose sur l'hypothèse que les fichiers ne quittent la machine locale que pour les traitements strictement nécessaires. Un fichier .env exposé sans filtrage peut suffire à compromettre des clés API, des accès à des bases de données ou des identifiants cloud, avec des conséquences potentiellement coûteuses pour les entreprises concernées. Le fait que le comportement ait persisté même après une instruction explicite de ne rien lire renforce le doute sur le niveau de contrôle qu'un utilisateur peut réellement exercer sur ces agents. Plusieurs développeurs ont confirmé sur les réseaux sociaux avoir observé le même phénomène, notamment via la commande cat ~/.grok/logs/unified.jsonl | grep repo_state.upload, qui permet de vérifier si un dépôt a été téléchargé à son insu.
Face à la controverse, xAI a réagi le 14 juillet en désactivant côté serveur le chargement automatique des dépôts, via un paramètre disablecodebaseupload réglé sur true, et en ajoutant une commande /privacy testée par Cereblab, qui s'est révélée être un simple réglage de conservation des données plutôt qu'un véritable blocage de l'envoi. La veille, sur X, l'entreprise avait affirmé qu'aucune donnée n'était conservée pour les clients ayant opté pour un fonctionnement sans rétention (ZDR), et que l'activation du nouveau paramètre supprimait les données déjà synchronisées. Elon Musk a minimisé la portée de l'incident tout en promettant, par précaution, la suppression de toutes les données précédemment envoyées. L'examen de la dernière version de Grok Build montre toutefois que la fonction d'envoi reste intégrée au client : xAI n'a pas supprimé cette capacité, mais s'est contenté d'en modifier la politique d'activation côté serveur, laissant ouverte la possibilité d'une réactivation future sans que les utilisateurs en soient nécessairement informés.
Les developpeurs francais et europeens utilisant Grok Build s'exposent a une fuite de leurs cles API et secrets stockes dans des fichiers .env, sans qu'aucune entreprise francaise ne soit directement citee dans l'incident.
Dans nos dossiers
Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.




