Données envoyées à xAI par le CLI Grok Build de xAI : analyse au niveau du fil

• D’après une capture directe du trafic réseau de grok 0.2.93, Grok Build a transmis les fichiers lus sans masquage, les a enregistrés dans session_state, et des secrets .env de test ont été inclus tels quels dans les deux chemins
• Indépendamment de l’envoi au modèle des fichiers lus par l’agent, l’intégralité du dépôt, contenant tous les fichiers de trace et l’historique Git, a été téléversée sous forme de git bundle, et des fichiers explicitement désignés comme à ne pas ouvrir ont été restaurés tels quels
• Dans un dépôt de fichiers aléatoires de 12 Go, les requêtes /v1/responses totalisaient 192 Ko, mais le volume transmis à /v1/storage atteignait 5,10 Gio au moment de l’arrêt de la capture, soit environ 27 800 fois plus, et toutes les requêtes de stockage ont renvoyé HTTP 200
• La destination de téléversement était le bucket grok-code-session-traces de Google Cloud Storage ; même avec l’option « Improve the model » désactivée, trace_upload_enabled: true et upload_enabled: true restaient actifs, et le téléversement de tout le dépôt continuait
• L’expérience démontre la transmission, l’acceptation et le stockage des données, mais ne permet pas de confirmer qu’elles ont été utilisées pour l’entraînement du modèle ; les fichiers .gitignore et toutes les combinaisons de comptes et de paramètres n’ont pas été testés, si bien que les résultats se limitent à une version précise de juillet 2026

---

Cible du test et périmètre de l’analyse

• La cible était le CLI Grok Build officiel de xAI, connecté avec un compte grand public
  • Le chemin d’installation était ~/.grok/bin/grok
  • L’authentification se faisait dans le navigateur avec un compte X ou SuperGrok, sans utiliser de clé API
  • Le binaire testé était grok 0.2.93 (f00f96316d4b) pour Apple Silicon
  • Son SHA-256 était 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c
• Les chaînes du binaire ont révélé un composant d’upload Rust interne et des constantes liées au dépôt
  • crates/codegen/xai-data-collector/src/gcs.rs
  • storage_client.rs, queue.rs, file_access_tracker.rs, circuit_breaker_observer.rs
  • xai-grok-shell/src/upload/{gcs,turn,trace,manifest}.rs
  • grok-code-session-traces, storage.googleapis.com, Uploading bytes to GCS via proxy
• Toutes les captures ne concernaient que l’ordinateur et le trafic de la personne ayant réalisé les tests ; le dépôt contenait des chaînes canary uniques à la place de véritables identifiants

Méthode de reproduction et de capture du trafic

• Sur macOS Apple Silicon, la CA de mitmproxy a été ajoutée comme certificat de confiance dans le trousseau de connexion, puis HTTPS_PROXY et SSL_CERT_FILE ont été configurés pour capturer les requêtes HTTPS de Grok
• Dans cette configuration, Grok n’a pas bloqué la capture par certificate pinning
• Un add-on mitmdump a enregistré, pour chaque requête, la méthode, l’hôte, le chemin, le statut de réponse et la taille en octets de la requête, et a sauvegardé le corps des requêtes envoyées vers les hôtes xAI
• ~/.grok/upload_queue/* a été copié pendant l’exécution, puis décompressé avec gzip et tar afin d’examiner aussi les artefacts de staging en attente de transmission
• Chaque fichier contenait un marqueur unique permettant d’en identifier l’origine, et les fichiers secrets utilisaient les fausses valeurs suivantes
  • API_KEY=CANARY7F3A9-SECRET-should-not-leave
  • DB_PASSWORD=CANARY7F3A9-DBPASS

Canal A : envoi au modèle des fichiers lus et du .env

• Le contenu des fichiers lus par Grok a été sérialisé dans le corps du tour de modèle de POST cli-chat-proxy.grok.com/v1/responses
  • La requête capturée de 48 070 octets contenait "model":"grok-4.5" et un tableau de messages
  • Les canarys API_KEY et DB_PASSWORD du .env ont été trouvés tels quels, sauts de ligne compris
  • Six marqueurs, comprenant du code source, de la logique, le README, un fichier JavaScript imbriqué et les deux secrets, ont pu être récupérés dans le corps de la requête
• Le même contenu a aussi été placé dans l’archive session_state et téléversé via POST /v1/storage, cette requête de stockage ayant été acceptée avec HTTP 200
  • Après décompression et inspection de l’archive, les deux secrets et les autres marqueurs de fichiers ont tous été retrouvés
  • Les secrets ne se limitaient donc pas à un traitement temporaire par le modèle : ils étaient également enregistrés dans une archive de stockage
• Avec le prompt de contrôle Reply exactly OK, do not read any files, le marqueur du fichier non ouvert untouched_secret.txt n’apparaissait pas dans le corps de /v1/responses
  • Cela démontre seulement que le canal de requête au modèle est structuré autour des fichiers effectivement lus par l’agent
  • Comme un canal distinct de snapshot complet du dépôt inclut aussi des fichiers non lus, ce résultat de contrôle n’invalide pas le téléversement de l’ensemble du dépôt
• Les secrets se trouvaient dans .env ou secrets.env et étaient dans des fichiers suivis par Git
  • Il n’a pas été testé séparément si les fichiers inclus dans .gitignore étaient aussi téléversés
  • Les canarys n’ayant pas le format de véritables jetons à haute entropie, cela ne prouve pas qu’il n’existe absolument aucun dispositif de masquage pour des formes spécifiques comme sk-…
  • Le périmètre vérifié est que le contenu .env testé a été transmis sans masquage

Canal B : téléversement de l’intégralité du dépôt, y compris les fichiers non lus

• /v1/storage a téléversé un snapshot complet de l’espace de travail, indépendamment de /v1/responses, qui envoie les fichiers lus par le modèle
• L’exécution a été menée sur le dépôt réel cereblab_api après l’instruction Reply with exactly: OK. Do not read or open any files.
  • Grok a envoyé un git bundle de 152 102 octets via POST /v1/storage, et le serveur a renvoyé HTTP 200
  • Après git clone du uploaded_repo.bundle capturé, le fichier src/_probe/never_read_canary.txt, explicitement désigné comme à ne pas lire, a été restauré
  • Le marqueur CANARY-XR47P2-NEVERREAD-UNIQUE qu’il contenait était toujours présent tel quel
  • Le bundle contenait 4 commits, 47 fichiers et l’historique Git complet
• Le même résultat a été reproduit avec un deuxième dépôt indépendant, cereblab_auth
  • Un git bundle de 31 743 octets a été téléversé via POST /v1/storage, avec une réponse HTTP 200
  • Dans le dépôt restauré, le marqueur CANARY-AUTH-4T8K2-NEVERREAD d’un fichier non lu a été confirmé tel quel
• Dans une exécution distincte de cereblab_api portant sur 298 fichiers, le manifest mis en staging énumérait aussi des fichiers non lus
  • src/_probe/never_read_canary.txt était enregistré avec du code source réel comme src/apns.ts et src/index.ts
  • Dans metadata.json, le fileId de chaque fichier avait la forme gs://grok-code-session-traces/repo_changes_dedup/v2/supplemental/sha256_…
  • Cette exécution a été bloquée par un quota avant l’achèvement du transfert des blobs de contenu, mais les expériences séparées avec git bundle et avec le dépôt de 12 Go ont confirmé l’upload effectif
• Le binaire contenait aussi des chaînes comme after_codebase.tar.gz, repo_state.upload, collecting workspace files et spawning background coordinator, cohérentes avec un mécanisme de collecte de l’espace de travail

Transfert de plusieurs Gio constaté avec un dépôt de 12 Go

• Le comportement d’upload a été observé en augmentant la taille du dépôt avec des fichiers aléatoires presque incompressibles
  • À 64 Mo, un unique POST /v1/storage d’environ 48 Mo a renvoyé HTTP 200, mais le log n’a pas été conservé
  • Vers 600 Mo, des dizaines de chunks d’environ 7,5 Mo ont tous renvoyé HTTP 200, mais le log n’a pas été conservé
  • Vers 3 Go, après l’initialisation multipart, des PUT par tranches de 50 Mo vers storage.googleapis.com ont été observés, mais les logs de PUT directs n’ont pas été conservés
  • Vers 12 Go, des chunks d’environ 75 Mo ont continué à être envoyés à /v1/storage, et la capture a été arrêtée à 5,10 Gio
• Le fichier conservé wire_12gb.log contient au total 83 réponses HTTP 200 pour /v1/storage*
  • 82 POST /v1/storage d’upload de contenu
  • Parmi eux, 73 chunks d’environ 75 Mo
  • La somme de ces 73 chunks est de 5,476,083,317B, soit 5,10 Gio ou 5,48 Go
  • 9 petits POST et 1 vérification de doublons /v1/storage/batch_exists sont également inclus
  • Le volume total des requêtes /v1/storage* était de 5,476,228,005B, sans aucune requête de stockage échouée
• La capture ayant été arrêtée pendant que l’upload continuait, elle ne prouve pas l’achèvement du téléversement des 12 Go complets
  • Le dernier enregistrement était encore un HTTP 200 pour un chunk d’environ 75 Mo
  • Le périmètre démontré est qu’au moins 5,10 Gio ont été transmis sans échec et que le volume continuait d’augmenter au moment de l’arrêt
• Il existait un très grand écart de volume entre les deux canaux dans la même session
  • /v1/responses totalisait 196,705B sur 5 requêtes, soit environ 192 Ko, la plus grande requête faisant 60 394 octets
  • /v1/storage atteignait 5,10 Gio
  • L’écart d’environ 27 800 fois montre qu’une grande quantité de données du dépôt, non incluse dans les requêtes au modèle, a transité par un canal de stockage distinct
• Les erreurs de quota du modèle et l’upload de stockage se sont produits indépendamment
  • /v1/responses a renvoyé une fois HTTP 402 et trois fois 429
  • Une requête de bookkeeping de session a renvoyé un 404 sans rapport
  • Même après le premier 429, 76 réponses HTTP 200 de /v1/storage ont suivi
  • Les 82 requêtes de stockage ont toutes réussi et, dans le périmètre du test, aucune erreur de limite de capacité de stockage ne s’est produite
• Ce résultat ne dépend pas du fait que la file locale upload_queue se vide
  • La file pouvant être vidée aussi bien après un upload réussi qu’après un abandon, elle n’a pas été utilisée comme preuve
  • Les preuves reposent sur les corps de requêtes effectivement sortis sur le réseau avec une réponse HTTP 200, et sur les fichiers récupérés dans le git bundle téléversé

Emplacement de stockage et télémétrie

• La destination de stockage a été identifiée comme le bucket grok-code-session-traces de Google Cloud Storage, et non AWS S3
  • Le binaire contenait grok-code-session-traces, storage.googleapis.com et Uploading bytes to GCS via proxy
  • Les destinations de fichiers dans le metadata.json conservé étaient enregistrées sous la forme gs://grok-code-session-traces/…
  • Lors de l’expérience d’environ 3 Go, des PUT multipart directs vers cet hôte GCS ont aussi été observés, mais les logs n’ont pas été conservés
  • Même si le binaire contient aws-sdk-s3, la destination confirmée par les tests était GCS
• Des requêtes de télémétrie tierces et internes ont également été observées
  • api.mixpanel.com/track et /engage de Mixpanel
  • grok.com/_data/v1/events
  • Toutes ces requêtes ont renvoyé HTTP 200
• Les scripts d’installation du CLI et les documents quickstart examinés ne mentionnaient pas les uploads repo_state, session_state, ~/.grok/upload_queue ou grok-code-session-traces
  • Tous les documents et aides de xAI n’ayant pas été examinés, il n’est pas possible d’affirmer que ce n’est documenté nulle part
  • Le périmètre vérifiable est que cela n’apparaissait pas dans les documents de configuration du CLI lui-même
• ~/.grok/upload_queue peut mettre en staging un snapshot d’environ 3 Go en un seul tour et, sous forte charge, grossir jusqu’à plusieurs dizaines de Go, au point de saturer le disque
  • Il s’agit d’un problème de fiabilité distinct de l’enjeu de confidentialité des uploads

Paramètre « Improve the model » et périmètre des politiques

• Le fait qu’un agent de cloud coding envoie au serveur le contexte de code nécessaire à sa tâche est, en soi, un comportement nécessaire
• Le comportement constaté dans le test se décompose en trois points
  • Des fichiers secrets comme .env sont transmis sans masquage
  • Ce contenu est stocké dans le bucket GCS indiqué
  • Le téléversement de l’intégralité du dépôt est activé par défaut sans être visible dans les documents de configuration du CLI examinés
• La politique grand public de xAI couvre largement l’utilisation des données pour l’amélioration du modèle et l’opt-out ; Private Chat est automatiquement en opt-out, et l’opt-out n’est pas rétroactif
  • Les documents concernés sont la xAI Privacy Policy et les Consumer ToS
  • Ces politiques générales d’entraînement ne reviennent pas à documenter le pipeline spécifique repo_state et d’upload GCS

• Désactiver « Improve the model » n’arrête pas l’upload

  • Même avec ce paramètre désactivé, l’intégralité du dépôt a été téléversée vers /v1/storage sous forme de git bundle, avec une réponse HTTP 200
  • Un git clone a permis de récupérer les fichiers non lus et l’historique Git
  • Dans /v1/settings reçu par le CLI, "trace_upload_enabled": true, "upload_enabled": true et "session_registry_enabled": true restaient actifs
  • Une limite de 1 Gio par fichier était également renvoyée via "max_upload_file_bytes": 1073741824
  • D’après les résultats des tests, l’opt-out contrôle l’éventuel entraînement, mais ne bloque pas le fait que le dépôt quitte l’ordinateur pour être téléversé et stocké

Points non démontrés et limites des preuves

• Une capture réseau seule ne peut pas prouver que xAI utilise les données pour entraîner le modèle
  • Le périmètre confirmé est la transmission, l’acceptation HTTP 200, les archives de stockage et la destination GCS
• Les logs de PUT directs vers storage.googleapis.com/grok-code-session-traces observés lors de l’exécution de 3 Go ont été écrasés et n’ont pas été conservés
  • Les preuves d’upload multi-Gio reposent sur les logs /v1/storage conservés de l’exécution à 12 Go, ainsi que sur le binaire et les métadonnées mentionnant le bucket
• Parmi les tests par taille, les logs à 64 Mo, 600 Mo et 3 Go n’ont pas été conservés ; seul le log à 12 Go l’a été
• L’exécution à 12 Go ayant été interrompue vers 5,10 Gio, il n’est pas possible d’affirmer que les 12 Go complets seraient téléversés jusqu’au bout
• Tous les niveaux de compte et toutes les combinaisons de configuration n’ont pas été testés
  • Sur l’offre gratuite, un upload multi-Gio a réussi
  • Avec SuperGrok, le téléversement du git bundle a réussi même avec « Improve the model » désactivé
  • Aucun paramètre permettant de désactiver l’upload n’a été trouvé pendant les tests, mais cela ne permet pas d’affirmer qu’il est absolument impossible de le désactiver dans tous les environnements
• Au départ, les résultats nettop par PID avaient conduit à conclure à tort qu’aucun gros blob n’était téléversé ; cette conclusion a été retirée
  • Un processus coordonnateur d’upload distinct et des PUT présignés directement vers des IP Google pouvaient échapper aux mesures fondées sur l’hôte API ou sur un seul PID
  • La capture filaire via proxy ultérieure remplace ce premier jugement
• Les résultats sont limités à grok 0.2.93, macOS Apple Silicon et l’environnement de juillet 2026 ; xAI peut modifier ce comportement par la suite

Principales preuves conservées

• secrets_responses_body.bin : montre que le .env original était inclus dans le corps de /v1/responses
• secrets_session_state.tar.gz : montre que les mêmes secrets étaient inclus dans l’archive destinée à /v1/storage
• wire_12gb.log : consigne 5,10 Gio d’uploads de stockage, 83 réponses HTTP 200 pour /v1/storage*, 0 échec de stockage et un écart de volume d’environ 27 800 fois entre les deux canaux
• model_limit.txt : consigne un 402 et trois 429 sur les requêtes au modèle
• crate_strings.txt : conserve les chaînes xai-data-collector, grok-code-session-traces et storage.googleapis.com
• uploaded_repo.bundle : première preuve, issue d’un dépôt téléversé sous forme de git bundle, permettant de récupérer des fichiers non lus et l’historique Git complet
• uploaded_repo_auth.bundle : preuve reproduisant le même résultat avec un second dépôt indépendant
• staged_base_tree_manifest.json : montre que des fichiers non lus figuraient dans le manifest du snapshot du dépôt
• staged_metadata.json : montre que la destination des fichiers était gs://grok-code-session-traces/…
• gcs_puts.txt est un placeholder vide, faute d’avoir conservé les PUT directs vers GCS, et ne peut pas servir de preuve pour ces PUT

[GN⁺]

Commentaires sur Hacker News

• Je sépare toujours les outils de codage et les fournisseurs de LLM, et je limite les permissions des outils de codage avec un sandbox bubblewrap
  L’outil ne peut lire que le répertoire du projet en cours, .git est en lecture seule, et les répertoires sensibles sont montés comme des répertoires vides
  J’isole aussi l’espace de noms réseau pour n’autoriser l’accès à Internet qu’au travers d’un proxy HTTP sur socket Unix, en n’autorisant que les hôtes de fournisseurs LLM précis tout en bloquant ceux de l’outil lui-même
  Par exemple, j’autorise Crush à accéder à *.openrouter.ai, mais je bloque *.charm.land, utilisé pour la mise à jour automatique de la liste des LLM. Grâce à ça, il est bien plus facile de lui confier toutes les tâches en mode yolo

  • Avec bubblewrap, il vaut mieux récupérer un rootfs comme debian:unstable depuis Docker Hub et le configurer dans un dossier séparé comme un environnement de distribution complet
    Il suffit ensuite d’y installer l’agent IA, puis d’écrire un script qui lance bwrap en définissant le rootfs de la distribution en lecture seule et un /home/user personnalisé en lecture-écriture. Les fichiers importants hors des répertoires spécifiés restent invisibles, et on peut aussi exécuter plusieurs agents sans qu’ils se voient entre eux
    Pour renforcer encore l’isolation, on peut appeler runsc ... do ... de gVisor à l’intérieur, ou utiliser un moniteur de machine virtuelle comme muvm. bwrap sert à configurer l’environnement, puis on verrouille avec un outil de sandbox distinct, ce qui inspire confiance
    Si la configuration est correcte, bwrap seul suffit déjà à bloquer la plupart des attaquants, et une élévation de privilèges exigerait très probablement un zero-day du noyau Linux
  • Je serais curieux de savoir quelle approche est utilisée pour mettre cela en place
  • Je me demande si ce durcissement de sécurité supplémentaire ne sert qu’à rassurer, ou s’il a déjà réellement intercepté des comportements risqués
    Si le modèle se comporte de manière assez stupide pour devoir être bloqué par des contraintes, je pense qu’il ne vaut pas la peine d’être utilisé. Je renforce moi aussi mon propre environnement, donc ce n’est pas une critique de la pratique en elle-même

• Les runners natifs d’agents de codage propriétaires comme claude-code, Codex ou grok-build posent un risque pour la vie privée, car on ne sait pas quelles fonctionnalités non publiques seront ajoutées dans une prochaine mise à jour
  Utiliser des modèles via l’API dans opencode est bien plus sûr, mais cela implique un compromis, car il est difficile d’atteindre des performances aussi bonnes qu’avec un runner natif

  • Si l’usage est suffisant, de simples appels d’outils côté serveur peuvent reconstituer l’intégralité d’une base de code, et ce processus est presque impossible à détecter complètement
    La méthode de Grok est simplement plus flagrante, mais opencode ne crée pas non plus de véritable frontière de sécurité ; c’est un peu comme le mème qui consiste à utiliser des Cheetos comme cadenas
  • Codex est open source
  • Les mises à jour automatiques sont elles aussi un gros problème
    Ne pas corriger immédiatement quelque chose comme une vulnérabilité d’exécution de code à distance de Windows XP SP1 est risqué, bien sûr, mais au cours des dernières décennies, j’ai vu davantage de dégâts causés par les mises à jour automatiques que par l’absence de mises à jour
  • J’utilise mon propre agent, mais je ne peux pas prendre le risque que le compte de mon entreprise soit bloqué à cause de ça

• Le fait que l’agent téléverse l’intégralité du dépôt, y compris le contenu de tous les fichiers suivis et l’historique Git, indépendamment des fichiers qu’il a lus, est extrêmement choquant
  Je me doutais plus ou moins qu’Elon pouvait faire ce genre de chose pour rattraper son retard, mais c’est très inquiétant. Le prix est compétitif et les performances de grok-4.5 sont tout à fait suffisantes, mais c’est précisément pour cette raison que je ne l’ai pas choisi

  • C’est clairement une fuite de données et cela devrait être illégal
  • Je me demande si OpenAI a aussi accès à tous les dépôts GitHub en raison de son partenariat avec Microsoft
  • Au final, c’est une course vers le bas
  • Je n’ai pas réussi à trouver d’informations sur les données partagées, au point d’hésiter même à essayer la version d’essai gratuite
  • Je fais toujours tourner ce genre de CLI dans un sandbox qui limite les répertoires accessibles
    Le CLI peut embarquer par erreur des clés SSH ou d’autres informations sensibles, et les programmeurs commettent réellement ce genre d’erreur très souvent. Je n’ai pas envie de confier ma sécurité au fait que « téléverser tous les fichiers accessibles » soit intentionnel ou accidentel

• Le premier point, à savoir que « le modèle a lu un fichier contenant des secrets dans le dépôt », relève pratiquement d’un comportement voulu
  Un LLM ne peut pas déterminer avant lecture si un fichier contient des secrets. Le vrai problème de fond, c’est de donner à un LLM un accès à des fichiers contenant des secrets en clair, puis de s’étonner qu’il les lise
  En revanche, le téléversement automatique du dépôt entier est absurde. Si le dépôt fait plusieurs Go, cela peut prendre très longtemps sur certaines connexions, et sans autre objectif consistant à collecter toutes les données, cela semble généralement dénué de sens

• J’ai toujours supposé que l’espace de travail actuel où l’agent s’exécute était au minimum entièrement à sa disposition, donc cela ressemble à un comportement attendu
  La plupart des agents lisent le code et même les secrets qu’il contient dès le premier prompt. Si le fait d’exploiter cela côté serveur réduit les allers-retours de prompt et les appels d’outils, est-ce que ce n’est pas au contraire bénéfique pour l’utilisateur ?

  • Quand il lit des fichiers et renvoie une réponse, il utilise l’API de messagerie habituelle
    Mais ici, on a découvert un endpoint distinct qui exfiltre tout le dossier de projet vers un bucket de stockage GCP. Toute personne ayant déjà conçu des systèmes distribués à grande échelle verra qu’il s’agit d’une architecture pensée pour aspirer des données d’entraînement
  • Si je comprends bien, Cursor effectue une sorte de travail d’indexation en local
    Sans téléverser tous les fichiers, il peut retrouver uniquement les parties pertinentes via la recherche et les envoyer pour que le modèle les utilise

• J’aurais préféré que le résumé soit rédigé par une personne, mais le fond reste inquiétant

  • Quelques blocs de code montrant ce qui est téléversé et 2 ou 3 paragraphes auraient suffi
    Les rapports rédigés par IA sont trop pénibles à lire ; j’ai survolé ça une dizaine de secondes avant de perdre tout intérêt
  • À défaut, quelqu’un aurait au moins pu retravailler le style avec le LLM en quelques passes supplémentaires

• Je me demande si ce qui a été volé finira dans le projet Macrohard censé « automatiser tous les métiers » ou dans la « everything app »
  On dirait l’idée qu’il n’est même pas nécessaire de tout construire soi-même puisqu’il suffit de voler

  • Le plus fort, c’est que des utilisateurs paient pour bénéficier d’un tel privilège
    Si on dirige une entreprise comme celle-ci sans aucune morale, on cherchera à voler autant que possible avant que l’ampleur de l’escroquerie n’apparaisse et que la régulation ne l’arrête. Je ne dis pas que c’est effectivement le cas ici, mais les incitations économiques sont parfaitement alignées dans cette direction

• Il faut partir du principe qu’un agent IA peut lire les fichiers du répertoire où l’exécutable a été lancé
  Dans la plupart des cas, il lit dès le premier prompt le code ainsi que les secrets qu’il contient, et comme .env est destiné à l’environnement local, il ne devrait pas contenir de vrais secrets. Comme on ne peut pas faire confiance aux instructions données à un agent IA, il faut l’isoler des vrais secrets
  Si l’on accepte ce postulat, il peut même être préférable de placer le code sur le serveur plutôt que de le renvoyer en contexte à chaque fois

  • Vu le mode de fonctionnement des LLM, le code finit de toute façon par être retransmis via le contexte
    La seule raison de faire un upload séparé semble être que Musk cherche à récupérer des données d’entraînement propres sur la structure des projets, les bibliothèques populaires et les workflows CI pour le prochain modèle
  • Même après un upload unique, le code entre toujours dans le processus d’inférence, et l’économie réalisée se limite à un peu de trafic HTTP
  • Le fond de l’histoire n’est pas énorme. Il est possible que Grok soit environ 10 % plus agressif que d’autres fournisseurs dans la construction du contexte, ou simplement que cette méthode ait permis de sortir le produit plus vite
    Tous les fournisseurs ont la capacité et l’intérêt de faire la même chose si cela peut améliorer les résultats
    La vraie différence, c’est que des fichiers secrets comme .env sont envoyés sans être filtrés, qu’ils ne sont pas seulement traités de façon temporaire mais stockés dans un bucket GCS nommé, et que le mode d’upload a été activé par défaut dans la documentation de configuration du CLI sans que cela soit signalé
    Il ne faut pas laisser un .env non chiffré dans un chemin accessible. Il vaudrait mieux que Grok identifie les secrets et les ignore, mais les utilisateurs ne devraient pas dépendre de ce comportement

• Le fait que l’intégralité du dépôt soit téléversée de la même manière, que le paramètre « Improve the model » soit activé ou non, est extrêmement grave
  La plupart des entreprises d’IA feraient probablement quelque chose de similaire dans leur propre exécutable si l’on consent à la collecte de données, mais téléverser quand c’est explicitement désactivé relève de la malveillance

• Téléverser l’ensemble du codebase permet au modèle d’examiner le code pendant qu’il « réfléchit » sans demander de véritables appels d’outils au client
  On voit mal quel serait l’inconvénient à redemander cela au client, donc ce n’est pas une très bonne justification, mais c’est la meilleure qu’on puisse imaginer

  • Le but réel semble plutôt être de voler des secrets commerciaux, l’architecture des applications et les connaissances métier internes, ou de répliquer du code, des applications, des outils et des procédures
    Un code auparavant privé devient désormais leur code
  • Cela peut aussi servir à piloter à distance depuis un téléphone, via un conteneur quelque part, même si l’ordinateur est hors ligne, puis à revenir plus tard au développement local et synchroniser les modifications depuis un bucket GCP
    C’est assez utile, mais pas au point de confier tout un dépôt à Elon. Le fait que cela ait été rendu incontournable et qu’aucune transparence n’ait été fournie renforce encore l’idée qu’il ne faut pas leur confier ces données