Voilà une publicité dont SpaceXAI se serait sans doute bien passé. Un chercheur en sécurité, connu sous le pseudonyme Cereblab, a documenté le 10 juillet dernier la façon dont l’assistant en ligne de commande (CLI) dédié au code Grok Build envoyait le contenu des dépôts sur lesquels travaille l’utilisateur vers des serveurs distants.

Un assistant IA un peu trop curieux

Pour ce faire, il indique avoir simplement installé un proxy en sortie de sa machine, pour monitorer les échanges réseau. Sur un dossier de travail de 12 Go, il affirme avoir constaté que 5,1 Go de données, pourtant non manipulées lors de la session en cours, ont transité vers un bucket hébergé sur Google Cloud et avaient été « acceptés » par ce dernier.

Dans le lot figurait notamment un fichier .env, envoyé sans rédaction 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 interfaces de programmation (API) mises en œuvre dans le projet.

Son analyse illustre deux canaux d’échange en parallèle : un canal « modèle » dédié aux traitements, par lequel seuls 192 ko de données ont transité, et un canal « stockage », qui a donc chargé 5,1 Go d’informations. Pour aller plus loin, le chercheur a reproduit la manipulation, mais avec un prompt indiquant explicitement à Grok Build de ne lire aucun fichier. Là encore, il constate qu’un lot complet est expédié vers Google Cloud.

Le chercheur explique ensuite avoir reproduit l’expérience avec Claude Code, Codex d’OpenAI et Gemini, sans constater de transfert de données inapproprié. Il se garde en revanche de spéculer sur la finalité de cet envoi de données. « Rien de tout cela ne prouve que xAI [entraine ses modèles] sur les données. Ce qui est prouvé, c’est la transmission, l’acceptation et le stockage », écrit-il.

Plusieurs témoignages partagés sur les réseaux sociaux abondent dans le sens de ses découvertes. « Une simple commande vous permettra de voir si un fichier a été téléchargé : cat ~/.grok/logs/unified.jsonl | grep repo_state.upload », précise à ce sujet un développeur.

SpaceXAI a réagi en modifiant le comportement litigieux, comme le souligne Cereblab dans une mise à jour datée du 14 juillet :

« Depuis la publication : xAI a désactivé le chargement côté serveur (disable_codebase_upload : true) ; a ajouté une option de désactivation de la confidentialité (/privacy) — que j’ai testée et qui s’est avérée être un paramètre de conservation des données, et non un blocage de l’envoi. »

SpaceXAI admet à demi-mots un problème

L’entreprise n’a pas publié de note de version dédiée, mais elle s’est exprimée le 13 juillet sur X, en affirmant qu’aucune donnée n’était conservée pour les entreprises qui avaient fait le choix d’un fonctionnement sans rétention de données (ZDR). Pour les autres, elle indique que le nouveau paramètre /privacy permet de supprimer cette rétention de données directement depuis l’interface en ligne de commande, et que l’activation de cette dernière supprimait les données précédemment synchronisées.

Elon Musk a quant à lui minimisé la portée de l’incident, tout en assurant qu’en guise de mesure de précaution, toutes les données précédemment uploadées par SpaceXAI seraient supprimées. L’examen de la dernière version en date de Grok Build laisse toutefois supposer que la fonction d’envoi reste intégrée au client, ce qui signifie que SpaceXAI n’a pas bloqué en dur cette possibilité, mais simplement modifié à son niveau la politique associée. Un nouveau changement de configuration reste donc possible.

En attendant de voir si SpaceXAI clarifie la situation et propose des garde-fous plus solides, les utilisateurs de Grok Build ont sans doute intérêt à vérifier le statut de leurs propres dépôts et à en modifier les secrets.

• Économie

  Dans la foulée de son IPO, SpaceX rachète Cursor et ses modèles dédiés aux développeurs

  Économie

  Mardi 16 juin 2026 à 17h06 16/06/2026 17h06

  13