L'outil de codage Grok Build de SpaceXAI fait l'objet d'un examen minutieux après qu'un chercheur en sécurité a découvert que son CLI téléch...
L'outil de codage Grok Build de SpaceXAI a récemment fait l'objet d'un examen minutieux après qu'un chercheur en sécurité a découvert que son outil en ligne de commande (CLI) téléchargeait l'intégralité du dépôt Git sur le stockage cloud, et non seulement les fichiers nécessaires à la tâche de codage.
Selon les rapports, les données téléchargées comprenaient les fichiers suivis, l'historique Git complet, les fichiers que l'agent avait pour instruction de ne pas lire, ainsi que des informations confidentielles supprimées de l'arbre de travail actuel mais toujours présentes dans les commits antérieurs. Les données étaient envoyées vers un bucket de stockage Google Cloud contrôlé par xAI.
Suite à la publication des résultats de l'enquête, le téléchargement a cessé. Le chercheur a observé que les serveurs de SpaceXAI ont commencé à renvoyer le contenu suivant :
disable_codebase_upload: true
Elon Musk a également déclaré que les données utilisateur précédemment téléchargées seraient complètement supprimées. Cependant, au moment où l'incident a été rapporté, il n'était pas possible de confirmer indépendamment et publiquement que toutes les copies historiques avaient été retirées.
L'incident a commencé par une analyse réseau contrôlée du CLI de Grok Build.
Le chercheur, connu sous le pseudonyme de Cereblab, a procédé à la rétro-ingénierie du binaire officiel et a surveillé son trafic réseau. Lors d'un test visant à révéler le flux de données réel de l'outil, Grok Build a empaqueté le dépôt dans un bundle Git et l'a téléchargé vers le bucket de stockage Google Cloud associé à xAI.
Cela ne se limitait pas aux quelques fichiers nécessaires pour répondre à l'invite.
Selon les rapports, le bundle capturé contenait :
Le rapport original d'AIbase décrit une portée de conservation bien plus large que celle d'outils de codage IA similaires comme Claude Code.
Dans un test rapporté par Axios, Grok Build a téléchargé environ 5,1 Go de données, alors que la tâche de codage elle-même ne nécessitait qu'environ 192 Ko. Cet exemple illustre la différence entre l'envoi du contexte pertinent à la tâche et le transfert de l'intégralité de l'archive du dépôt.
Le téléchargement de l'arbre source actuel constitue déjà un incident de sécurité grave. Le téléchargement de l'historique Git complet peut causer des dommages encore plus importants.
Les développeurs suppriment souvent une information confidentielle de la dernière version d'un dépôt en pensant qu'elle a disparu. En réalité, cette valeur peut toujours subsister dans des commits plus anciens, à moins que l'historique n'ait été réécrit.
L'historique Git peut contenir :
Ainsi, un dépôt peut sembler propre dans le répertoire de travail actuel, mais des éléments sensibles subsistent toujours dans le répertoire .git.
C'est pourquoi des instructions comme "n'ouvre pas ce fichier" sont insuffisantes pour offrir une protection adéquate lorsque l'outil empaquette le dépôt au niveau Git lui-même. Les instructions de permission au niveau des fichiers peuvent contrôler ce que l'agent lit pendant la conversation avec le modèle, mais elles ne peuvent pas empêcher automatiquement un processus de téléchargement distinct d'empaqueter l'historique du dépôt.
L'analyse de Cereblab a identifié la cible comme un bucket Google Cloud Storage contrôlé par xAI.
Le fait d'utiliser Google Cloud ne signifie pas que Google décide indépendamment de collecter les dépôts. Le fournisseur de stockage cloud héberge l'infrastructure pour ses clients, et selon les rapports, le responsable du traitement des données ou l'opérateur du service dans ce cas était xAI ou SpaceXAI.
Le problème crucial est que les données du dépôt quittent la machine de l'utilisateur pour entrer dans une infrastructure cloud tierce.
Pour les équipes d'entreprise, cela peut soulever des questions relatives à :
Même si le fournisseur cloud lui-même dispose de mesures de sécurité solides, un transfert non divulgué ou inattendu peut enfreindre les propres exigences de gouvernance de l'entreprise.
Après la publication de l'enquête, Cereblab a de nouveau testé le CLI.
Le serveur a renvoyé :
disable_codebase_upload: true
Le téléchargement de l'intégralité du dépôt n'a plus été déclenché.
Cela semble être une modification côté serveur, car les utilisateurs n'ont pas eu besoin d'installer une nouvelle version avant que le comportement ne cesse. Un indicateur de configuration à distance a désactivé le processus d'empaquetage du dépôt.
Cette distinction est importante.
Un commutateur côté serveur peut arrêter rapidement le comportement, mais il indique également que le comportement de traitement des données du client peut dépendre d'une configuration à distance. Par conséquent, les organisations qui évaluent les agents de codage doivent vérifier le trafic réseau réel, et non se fier uniquement aux numéros de version locaux ou aux écrans de paramètres statiques.
Elon Musk a répondu publiquement, déclarant que toutes les données utilisateur téléchargées avant le changement seraient "complètement et intégralement supprimées", sans laisser de trace.
SpaceXAI a également indiqué qu'elle respecterait les choix de confidentialité et que les clients soumis à des accords de conservation de données nulle ne verraient pas leurs données de suivi ou de code conservées.
Ce sont des promesses importantes, mais plusieurs questions restaient sans réponse au moment du rapport :
La suppression peut atténuer les risques futurs, mais cela ne résout pas automatiquement tous les problèmes de sécurité. Si le dépôt contenait des identifiants actifs, les utilisateurs doivent supposer que ces valeurs ont pu quitter l'environnement local et les remplacer immédiatement.
/privacy n'est pas une véritable solutionSpaceXAI a d'abord orienté les utilisateurs vers la commande CLI de Grok Build :
/privacy
La documentation officielle de Grok Build décrit /privacy comme une commande pour afficher ou modifier l'état de la confidentialité et de la conservation des données.
Le chercheur en sécurité a constaté que ce paramètre contrôle le comportement de conservation, et non le mécanisme de transfert du bundle complet du dépôt. En d'autres termes, la commande ne peut affecter que les opérations de conservation de SpaceXAI après réception des données, mais ce n'est pas un mécanisme côté serveur qui empêche le dépôt de quitter la machine locale.
La conclusion de Cereblab est très claire :
/privacy est un contrôle de conservation au niveau de la session.disable_codebase_upload.C'est l'une des leçons les plus importantes de cet incident.
| Problème de contrôle | Signification |
|---|---|
| Les données quittent-elles l'appareil ? | Contrôle du transfert ou du téléchargement |
| Les données reçues sont-elles stockées ? | Contrôle de la conservation |
| Combien de temps sont-elles stockées ? | Politique de durée de conservation |
| Sont-elles utilisées pour l'entraînement du modèle ? | Politique d'utilisation pour l'entraînement |
| L'utilisateur peut-il supprimer les données ? | Contrôle de la suppression |
| L'utilisateur peut-il vérifier la suppression ? | Contrôle d'audit et de garantie |
Un service peut promettre de ne pas conserver les données, mais peut tout de même les transférer pour un traitement en temps réel. Cela peut être acceptable dans le cadre d'un accord d'entreprise écrit clair, mais cela n'équivaut pas à maintenir les données en local.
Les utilisateurs ne doivent pas assimiler "conservation de données nulle" à "transfert de données nul", sauf si le produit fait explicitement une telle garantie.
Voici la traduction en français du document fourni :
Document de confidentialité officiel de xAI
Le document sur la sécurité de l'API de xAI décrit la conservation zéro données (ZDR) comme une fonctionnalité de niveau entreprise.
Lorsque l'équipe API active la ZDR, xAI indique que les invites, les complétions et les métadonnées associées sont traitées en temps réel mais ne sont pas stockées de manière persistante sur ses serveurs. Le document précise également que les réponses de l'API incluront un en-tête x-zero-data-retention, permettant aux applications de vérifier si la ZDR est active.
Pour les cas d'utilisation standard de l'API sans ZDR, xAI déclare que les requêtes et les réponses peuvent être stockées temporairement jusqu'à 30 jours à des fins d'audit des abus et des mauvaises utilisations.
Ces politiques d'API sont une référence utile, mais les organisations ne doivent pas présumer automatiquement que tous les produits Grok, les traces CLI, les canaux de transfert de fichiers ou les comptes consommateurs suivent le même cycle de vie des données.
Avant d'utiliser Grok Build avec des dépôts privés, veuillez vérifier :
Le chercheur en sécurité indépendant, le Dr. Łukasz Olejnik, a décrit l'ampleur des données —
La conservation des données est trop longue.
Les informations susceptibles d'être divulguées comprennent :
Les risques ne se limitent pas à une utilisation malveillante.
Les grandes archives de code peuvent également fuiter en raison de :
Le principe de minimisation des données vise à réduire la surface d'attaque. Télécharger l'intégralité d'un dépôt par défaut, alors que seuls quelques fichiers sont nécessaires, est difficilement conciliable avec ce principe.
Les équipes qui ont utilisé Grok Build avant la désactivation de la fonction de téléchargement doivent agir comme face à tout incident potentiel de fuite de code source.
Vérifiez où Grok Build a été exécuté.
Enregistrez :
Ne limitez pas votre vérification aux fichiers que l'agent semble avoir ouverts.
Utilisez un outil de recherche de clés approuvé par l'organisation pour vérifier l'intégralité de l'historique, pas seulement le contenu de la branche actuelle.
Recherchez :
Même si un secret a été supprimé du dernier commit, il peut encore nécessiter une rotation.
Decrivez votre idee une fois, et We0 AI peut generer un site vitrine, des pages et un CMS, puis vous aider a attirer clients et trafic apres le lancement.
Une génération de projet complète pour une inscription gratuite
Idéal pour essayer un flux de génération complet et voir rapidement une première ébauche de projet.
Si, pendant la période concernée, un identifiant existait à un endroit quelconque dans l'historique du dépôt surveillé, révoquez-le ou remplacez-le.
N'attendez pas la preuve que quelqu'un a accédé à la copie téléchargée. Le remplacement des identifiants coûte souvent moins cher qu'une enquête post-intrusion.
Priorisez le remplacement des identifiants qui fournissent :
Après l'utilisation du dépôt avec Grok Build, vérifiez les journaux du cloud, de la gestion de code source, du CI/CD, des bases de données et des services internes pour toute activité anormale.
Recherchez :
L'absence d'activité suspecte ne prouve pas que les données n'ont jamais été divulguées, mais aide à évaluer le risque immédiat.
Utilisez la version actuelle de Grok Build et vérifiez la configuration active.
La documentation officielle propose :
grok inspect
Cette commande aide à confirmer quelles sources de configuration sont chargées.
La CLI propose également :
/privacy
Utilisez-la pour vérifier l'état de la conservation, mais notez qu'elle ne doit pas être considérée comme une preuve.
Aucune donnée ne quitte l'appareil.
Les utilisateurs professionnels doivent demander une réponse écrite couvrant :
Les promesses publiques de suppression sont utiles, mais les organisations réglementées peuvent avoir besoin de preuves spécifiques à leur compte.
Si les dépôts contiennent du code client, des données personnelles, des informations réglementées ou du contenu couvert par des accords de confidentialité, impliquez les équipes internes concernées.
Selon le contexte, les équipes concernées peuvent inclure :
Ne prenez pas de décisions concernant la notification de violation uniquement sur la base d'articles de presse. Basez-vous sur les faits d'exposition propres à votre organisation et sur la législation applicable.
Cet incident met en lumière un problème plus large dans le domaine des outils de développement IA.
Les agents de codage nécessitent souvent des accès étendus, car ils doivent parcourir de grands dépôts, exécuter des commandes, lire de la documentation et modifier des fichiers. Cette capacité crée une vaste frontière de confidentialité.
Avant d'approuver l'utilisation d'un assistant de codage, les équipes doivent évaluer cinq aspects.
Documentez chaque type de données que l'outil pourrait collecter :
Testez ce qui quitte réellement la machine.
La documentation du fournisseur est nécessaire, mais le comportement réseau est la preuve la plus solide du transfert réel.
Utilisez un dépôt de test isolé contenant des valeurs canaries inoffensives, puis vérifiez :
N'exécutez pas l'outil depuis des répertoires de projets non liés.
Privilégiez :
Pour les déploiements en entreprise, confirmez :
Le comportement d'un outil peut changer en raison de mises à jour automatiques ou de modifications de configuration à distance.
Re-testez après :
Lorsque les produits évoluent rapidement, l'approbation de sécurité ne doit pas être permanente.
Les instructions des agents s'exécutent au niveau du modèle ou de l'utilisation de l'outil. Les composants séparés de télémétrie ou de synchronisation peuvent ne pas interpréter ces instructions.
Les contrôles de confidentialité doivent exister dans le pipeline de données lui-même.
Les fournisseurs peuvent prétendre n'envoyer que le contexte nécessaire, mais les utilisateurs professionnels ont besoin de preuves.
Les garanties utiles incluent :
La configuration à distance peut arrêter rapidement les téléchargements, mais signifie également que les utilisateurs peuvent ne pas savoir quand un comportement important change.
Une réponse mature devrait inclure :
Même si SpaceXAI supprime toutes les copies stockées, tout identifiant contenu dans les dépôts téléchargés doit être traité en fonction de son risque d'exposition.
La suppression protège l'accès futur à la copie du fournisseur, mais ne modifie pas l'identifiant lui-même.
L'analyse au niveau protocole de Cereblab révèle que le CLI télécharge l'intégralité du dépôt Git suivi sous forme d'un bundle, y compris l'historique des commits et les fichiers sans rapport avec la tâche de codage en cours. Cet historique peut contenir des clés déjà supprimées du répertoire de travail actuel.
Le trafic capturé montre qu'il est téléchargé vers un bucket Google Cloud Storage contrôlé par xAI. Google Cloud est le fournisseur d'infrastructure ; les décisions relatives aux produits et au traitement des données incombent à SpaceXAI.
Les chercheurs ont ensuite observé que le serveur renvoyait disable_codebase_upload: true, après quoi le téléchargement complet du dépôt n'a plus été déclenché. Ce changement semble provenir du côté serveur.
/privacy empêche-t-elle le téléchargement du dépôt ?Cette commande contrôle les paramètres de confidentialité et de conservation, mais Cereblab indique qu'elle ne constitue pas un mécanisme pour empêcher le téléchargement complet du dépôt. Les utilisateurs doivent distinguer la prévention du transfert de la limitation de la conservation après transfert.
Oui. Musk a déclaré publiquement que toutes les données utilisateur précédemment téléchargées seraient intégralement supprimées. Au moment du reportage, aucune vérification indépendante de cette suppression complète n'avait été rendue publique.
Si des clés étaient présentes dans le dépôt suivi ou dans son historique Git lors de l'utilisation de Grok Build, le renouvellement est une mesure prudente. La suppression de la copie stockée par le fournisseur ne garantit pas que les identifiants n'ont jamais été exposés ou consultés.
xAI décrit le ZDR comme une fonctionnalité API d'entreprise qui traite les entrées et sorties sans les conserver. Cela ne signifie pas nécessairement que les données ne quittent jamais l'appareil local ; les organisations doivent vérifier quels canaux de données de Grok Build sont couverts.
La fonctionnalité de téléchargement complet du dépôt signalée a été désactivée, mais chaque organisation doit évaluer la version actuelle, les paramètres, les conditions du compte, le comportement réseau et la sensibilité du dépôt. Un correctif côté serveur ne remplace pas un examen de sécurité interne.
/privacy.Il a été découvert que Grok Build télécharge l'intégralité de son dépôt Git suivi ainsi que son historique complet vers un bucket Google Cloud Storage contrôlé par xAI, même lorsque la tâche ne nécessite qu'une petite quantité de code.
SpaceXAI a désactivé la fonctionnalité de téléchargement du dépôt via le flag serveur disable_codebase_upload, et Elon Musk a promis que les données précédemment téléchargées seraient supprimées. La commande /privacy, bien qu'elle concerne les paramètres de conservation, n'est pas un moyen de contrôle pour empêcher le transfert du dépôt.
Les développeurs ayant utilisé le CLI concerné doivent identifier les dépôts pertinents, scanner l'intégralité de l'historique Git, renouveler les identifiants potentiellement exposés, examiner les journaux et, si nécessaire, demander des informations de suppression propres au compte.
La leçon fondamentale est simple : la confidentialité des outils de codage IA doit être vérifiée au niveau du transfert de données, et non déduite uniquement à partir des invites, des étiquettes de conservation ou des interfaces de paramètres.
Partez d’une phrase et obtenez un site complet en quelques minutes.
