L'agent de codage Grok Build de SpaceXAI transfère illégalement l'intégralité des répertoires de code des utilisateurs vers un stockage cloud externe. Grok Build aspirait des fichiers sensibles et des secrets pourtant supprimés, dépassant largement les pratiques de collecte de ses concurrents. En réponse à la polémique, le PDG Elon Musk a promis la suppression totale des données collectées par erreur, tandis que l'entreprise a déployé une modification technique pour stopper ces transferts automatiques. Cet incident met en lumières les risques majeurs pour la propriété intellectuelle et la sécurité informatique liés à l'usage de ces outils d'IA.Les pratiques controversées de SpaceXAI ont été révélées par un chercheur en sécurité, connu sous le pseudonyme Cereblab. Il a réalisé une analyse au niveau des paquets réseau et a découvert que l'outil CLI de Grok Build empaquetait l’intégralité des dépôts de code des développeurs et les transférait vers un compartiment Google Cloud Storage, pour un volume environ 27 800 fois supérieur aux données réellement nécessaires à la tâche de codage.
Contrairement à Claude Code ou Gemini, qui n'analysent que des fichiers individuels, Grok Build empaquetait et téléchargeait des historiques Git complets. Les données étaient collectées même lorsque les développeurs demandaient explicitement à l'outil de ne pas ouvrir certains fichiers de leur répertoire. Interrogé sur le sujet, le chercheur indépendant en sécurité Dr Lukasz Olejnik a confirmé que ce niveau de rétention de données était « excessive ».
Cette analyse, publiée le 12 juillet 2026, a suscité un tollé et a incité Elon Musk à promettre la suppression de toutes les données utilisateur précédemment téléchargées par Grok Build. Aucun avis de sécurité officiel n’a été publié. Le code de téléchargement reste présent dans le binaire actuel.
Les informations révélées par l'analyse réalisée par Cereblab
Cereblab a acheminé la version 0.2.93 de Grok Build CLI via le proxy d’interception open source mitmproxy sur macOS et a publié l’intégralité des captures réseau sous forme de Gist public sur GitHub. Cette méthode ne nécessite ni jailbreak ni accès privilégié. Dans le cas de Grok Build CLI, les experts expliquent que tout développeur peut reproduire l’audit en acheminant l’outil via le même proxy et en examinant ce qui transite réellement sur le réseau.
Cette facilité de vérification explique en partie la rapidité avec laquelle ces découvertes se sont répandues. La principale découverte a été un décalage entre les canaux, difficile à expliquer par une télémétrie fortuite. Sur un dépôt de test de 12 Go, le canal « model-turn » en temps réel de Grok Build (POST/v1/responses, qui reçoit les fichiers que l’agent de codage lit effectivement pour répondre aux questions de codage) a transféré environ 192 Ko.
Un canal parallèle, acheminant vers POST/v1/storage, a transféré 5,10 Go répartis en 73 blocs d’environ 75 Mo chacun, pour lesquels chacun a renvoyé un statut HTTP 200. Ce transfert vers le stockage s’est effectué indépendamment des fichiers que l’agent a ouverts ou qu’il a reçu pour instruction de lire.
Les données exfiltrées comprenaient notamment un fichier .env, envoyé sans caviardage ou chiffrement automatique des secrets. Son contenu se révèle pourtant sensible puisqu’il est dédié aux variables d’environnement telles que les clés d’accès aux API mises en œuvre dans le projet. Le chercheur affirme avoir reproduit l’expérience avec d'autres outils comme Claude Code, Codex et Gemini, sans constater ce type de transfert de données inapproprié.
La destination était un compartiment Google Cloud Storage nommé « grok-code-session-traces ». En somme, lorsque Grok Build lit ou traite un fichier, le contenu de ce dernier est transmis sans être expurgé vers cet espace de stockage distant utilisé par SpaceXAI. Ni le compartiment ni le comportement de téléchargement n’apparaissaient dans la documentation de configuration ou les guides de démarrage rapide de Grok Build au moment de l’analyse.
Les risques en matière de cybersécurité et l'ampleur des fuites
Cereblab a testé ce comportement à l'aide d'une commande anodine. Il a demandé à l'outil CLI de se contenter de répondre « OK » et lui a expressément ordonné de ne pas ouvrir de fichiers. Grok Build a néanmoins téléchargé l'intégralité du dépôt, ainsi que l'historique Git complet contenant des informations confidentielles qui avaient été supprimées plusieurs mois auparavant, un résultat que le chercheur a pu reproduire à l'aide d'un autre dépôt.
D'autres utilisateurs de Grok Build ont signalé des résultats similaires après la publication du rapport de Cereblab. Dans un cas, l'intégralité du répertoire utilisateur d'un développeur, contenant des clés SSH, des bases de données de gestionnaires de mots de passe et bien plus encore, a mise en ligne.
Les développeurs ayant utilisé Grok Build sur des bases de code contenant de véritables clés API, mots de passe de bases de données ou tokens cloud doivent considérer ces identifiants comme potentiellement compromis et les renouveler immédiatement, quels que soient les paramètres de confidentialité en vigueur à ce moment-là. « Cela pourrait être équivalent à une vulnérabilité de sécurité majeure avec un score de gravité de 10 », a écrit un critique.
Le chercheur indépendant Lukasz Olejnik a souligné que « ce comportement mettait gravement en péril des éléments critiques tels que le code source propriétaire, les vulnérabilités de sécurité, les données personnelles, les identifiants et les détails de l'infrastructure des utilisateurs ». « C'est pourquoi je refuse d'utiliser des modèles IA basés sur le cloud. Je préfère être à la traîne sur le plan technologique que d'accepter cette chose », a écrit un critique.
Elon Musk et SpaceXAI ont annoncé des mesures correctives
Selon le rapport de Cereblab, la conservation des données par SpaceXAI allait bien au-delà de celle d’autres outils CLI, comme Claude Code d'Anthropic, Gemini de Google et Codex d'OpenAI, qui ouvrent des fichiers individuels plutôt que des dépôts entiers avant de les téléverser avec leur historique Git. Ces découvertes ont suscité suffisamment d'attention pour que les dirigeants de SpaceXAI s'expriment publiquement à ce sujet et corrigent le problème.
L'entreprise a rapidement déployé un correctif. Un communiqué publié via la plateforme X (ex-Twitter) indique que Grok Build respecte les clients ayant activé la politique de « non-conservation des données » (zero data retention - ZDR) et que, pour ceux qui ne l’avaient pas activée, tels que les clients non professionnels, l’exécution d’une simple commande permettait de supprimer toutes les données précédemment collectées sur un utilisateur donné.
« Si la fonction ZDR est désactivée, la commande /privacy est disponible dans l'interface en ligne de commande (CLI) pour désactiver la conservation des données, ce qui entraîne également la suppression des données précédemment synchronisées. Exécutez la commande /privacy pour consulter ou modifier vos paramètres à tout moment », a déclaré SpaceXAI. Malgré la réponse de SpaceXAI, certains développeurs affirment...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
