Un chercheur a passé au crible la CLI officielle de SpaceXAI, et le résultat est inquiétant. D’après une analyse réseau publiée sur GitHub, l’outil grok (Grok Build) en version 0.2.93 ne se contente pas d’envoyer à SpaceXAI les fichiers qu’il consulte pour vous assister. Non, non, c’est bien pire : il upload l’intégralité du dépôt, historique Git compris, vers un bucket Google Cloud, y compris lorsque vous lui demandez explicitement de ne rien lire. C’est du all inclusive, puisqu’il embarque aussi les fichiers et les secrets.

Pour rappel, SpaceXAI (anciennement xAI) est la société d’intelligence artificielle fondée par Elon Musk en 2023, et Grok en est la famille de modèles, déclinée ici en Grok Build, un assistant de code en ligne de commande.

Un dépôt entier, pas seulement les fichiers lus

À l’origine de l’affaire, un chercheur se présentant sous le pseudonyme cereblab. Sa méthode est reproductible : router la CLI Grok Build (compte grand public, pas une clé d’API) à travers un proxy (il a utilisé sur macOS), puis observer chaque requête sortante.

Le chercheur distingue deux canaux. Le premier, , correspond au tour de modèle et transporte les fichiers que l’agent ouvre réellement pour traiter votre demande. Le second, , envoie tout autre chose : une capture du dépôt complet. Dans les deux canaux, le contenu des fichiers lus, y compris un fichier , est transmis tel quel, sans aucun effort sur la confidentialité. Autrement dit, les clés d’API et autres mots de passe présents dans ce fichier réapparaissent mot pour mot dans le trafic.

Ce qui pose problème, c’est le second canal de communication. Sur un dépôt de test de 12 Go composé de fichiers aléatoires, ce canal a transféré 5,10 Go de données, quand le premier canal du modèle ne transportait que 192 Ko. Le modèle n’a pas ingéré ces fichiers, et pourtant, plus de 5 Go de données ont quitté la machine.

Et même quand vous lui dites de ne pas ouvrir le moindre fichier, Grok expédie le dépôt entier sous forme de . En clonant ce paquet capturé, le chercheur a récupéré un fichier que l’agent avait pour instruction de ne pas ouvrir, ainsi que l’historique Git complet. Cette expérience a été reproduite à plusieurs reprises par le chercheur, y compris avec des dépôts indépendants.

D’après lui, ces données sont exfiltrées vers un bucket Google Cloud Storage : une destination d’ailleurs spécifiée en clair dans le fichier . Sur la machine locale, le répertoire de préparation peut gonfler jusqu’à plusieurs dizaines de Go et saturer le disque. Décidément, l’espace de stockage des machines est mis à mal en ce moment…

SpaceXAI a coupé le robinet, sans communiquer

Environ un jour après que l’analyse du chercheur a commencé à circuler, le chercheur a relancé le même client et n’aurait plus constaté le moindre upload. Bizarre, non ? En réalité, le serveur renvoyait un nouveau champ , accompagné de , et aucun envoi de dépôt n’aurait été observé sur 6 essais consécutifs. Il s’agirait d’un changement côté serveur, opéré en douce par les équipes de SpaceXAI.

De son côté, SpaceXAI n’a rien publié à ce propos : pas la moindre note, pas la moindre explication. Le journal des modifications présente la version comme la plus récente au 12 juillet 2026, sans un mot sur ce comportement d’upload.

Il reste de nombreuses questions sans réponses : quand ont commencé ces transferts ? Combien de dépôts sont-ils concernés ? Quels sont les dépôts stockés sur les serveurs de Grok ? Dans les faits, toute personne qui aurait pointé cet outil vers un dépôt privé ou propriétaire aurait, de fait, transmis à SpaceXAI une copie de son code, de son historique et de ses secrets.

Pour le moment, nous ne savons pas non plus ce que SpaceXAI fait de ces données. Rien n’indique que les modèles sont entraînés sur les données collectées. Ce type de dérive n’est pas isolé. Les problèmes de sécurité avec les outils d’IA sont nombreux. Dernièrement, je vous ai d’ailleurs parlé de la faille SearchLeak qui transformait Copilot en outil de vol de données.

Vous pouvez retrouver l’analyse du chercheur sur GitHub.