Canary dans le dépôt: Grok Construire des repos complets et secrets exposés dans le nuage

Un chercheur qui signe Cereblab a constaté que l'outil xAI Gook Build téléchargeait des dépôts Git complets - y compris l'historique entier des engagements - vers un paquet de stockage Google Cloud géré par xAI, et pas seulement les fichiers que la tâche d'encodage nécessaire. Dans un test avec la version 0.2.93 une capture de l'un de ces ups a été créée: bien que le trafic vers le modèle (la requête a / v1 / réponses) ne contenait que des centaines de kilooctets, le canal de stockage (/ v1 / stockage) a envoyé plusieurs gigaoctets, reflétant directement la taille du dépôt sur le disque et reproduisant l'historique des commits dans un paquet qui pourrait être cloné.

Les détails techniques sont pertinents parce qu'ils définissent l'exposition : dans l'expérience avec un dépôt de 12 Go, la communication avec le modèle était d'environ 192 KB alors que la montée au stockage déplacé ~ 5.10 GiB en blocs d'environ 75 Mo qui ont retourné HTTP 200. En particulier, les métadonnées indiquées comme destination un seau appelé grok-code-session@-@ traces et la capture a permis d'extraire un fichier intentionnellement planté par l'enquêteur - un «canaire» que l'agent ne devrait pas ouvrir - avec toute l'histoire Git. Par ailleurs, lorsque Grok a ouvert un fichier .env, son contenu n'a pas été édité dans l'interaction avec le modèle et a également été archivé dans la session.

Il est important de souligner ce que ces captures prouvent et ce qu'elles ne prouvent pas: transmission, acceptation et stockage des essais ne pas prouver que xAI a formé des modèles avec ce matériel ou que des employés humains l'ont lu. Cependant, le fait que des références ou des secrets lus par l'agent puissent sortir sans écrire est en soi un risque opérationnel sérieux pour les développeurs et les organisations.

L'incident a également révélé une confusion des contrôles: l'option dite "Améliorer le modèle"(ou des options similaires) contrôle si vos données peuvent être utilisées pour la formation, mais pas nécessairement si vos fichiers quittent l'équipement pour le stockage contrôlé par le fournisseur. Dans les observations cereblab, l'ajustement "amélioration du modèle" a été désactivé, mais le serveur a continué à revenir trace _ télécharger _ activé & #160;: vrai, ce qui expliquerait que l'expédition et l'entreposage ont eu lieu malgré l'exclusion de la formation.

Après la publication, xAI a modifié les décalages du serveur et des preuves répétées ont montré que les hauts s'arrêtaient et le serveur est retourné désactiver _ codebase _ télécharger : true et trace _ télécharger _ activé & #160;: faux. Cette désactivation est venue du côté serveur, pas comme un patch dans la version du client, donc techniquement xAI pourrait réactiver la hausse sans les utilisateurs de mettre à jour leurs binaires. La société a répondu publiquement sur son canal X / SpaceXAI avec des explications sur l'équipement d'entreprise avec des politiques de « conservation zéro des données » et des commandes de confidentialité dans le CLI, mais ne donne toujours pas de détails clairs sur la durée de conservation des données ou le nombre d'utilisateurs affectés le comportement.

Compte tenu de ce type d'exposition, la recommandation pratique immédiate est claire: des actes comme vos secrets sont sortis.. Il tourne n'importe quel titre que l'agent peut avoir lu ou trouvé dans l'historique des engagements - même si la clé a été supprimé de l'arbre de travail, s'il a jamais été dans un commit faisait partie du paquet et peut avoir été élevé. Il ne suffit pas de supprimer localement : vous devez invalider les identifiants, émettre de nouvelles clés avec une portée restreinte et examiner les journaux externes.

De plus, examiner et nettoyer l'historique Git pour éliminer les secrets persistants et les empêcher d'être exposés à des clones ou des sauvegardes. Des outils comme Repo-Cleaner de BFG ou les procédures officielles de GitHub pour supprimer les données sensibles aident à réécrire l'historique et purger les secrets de dépôt, mais nécessitent des soins car la réécriture de l'historique affectera les collaborateurs et les fourchettes; la documentation officielle de GitHub sur le sujet est un bon point de départ: https: / / docs.github.com / fr / authentification / gardant-votre-compte-et-données-sécurité / enlevant-sensible-données-de-un-dépôt. Pour le nettoyage de masse des grands dépôts il y a BFG: https: / / rtyley.github. io / bfg-repo-nettoyage /.

Ne faites pas confiance aux promesses : J'ai entendu les données qui sortent. Si vous utilisez des agents de codage en nuage, surveillez le trafic sortant et examinez les demandes qui créent des paquets ou des sessions de fichiers; dans les environnements contrôlés, considérez des mandataires pour inspecter ou bloquer les hausses indésirables. Vérifiez la politique de conservation du fournisseur et, le cas échéant, activez zéro mode de conservation des données ou accords commerciaux qui garantissent la garde et l'effacement. Consultez la documentation du fournisseur de stockage si vous devez comprendre la conservation et l'élimination dans Google Cloud Storage: https: / / cloud / google.com / stockage / docs.

Enfin, la mentalité change : aujourd'hui, les assistants de programmation cloud ne sont pas « locaux » même lorsqu'ils affichent des interfaces dans votre terminal. Supposons que tout outil qui ouvre vos fichiers peut envoyer des données et exige la transparence sur ce qui est envoyé exactement, comment il est stocké, pendant combien de temps et quels contrôles d'accès sont appliqués. Si le fournisseur peut désactiver le téléchargement à partir du serveur, cette capacité doit être documentée et vérifiée; dans l'intervalle, la responsabilité de minimiser l'exposition incombe au développeur: éviter les références de dépôt, utiliser des secrets éphémères et limiter les droits des clés existantes.