Grok Build : l'agent de code de xAI aspirait vos dépôts Git

Un agent de code qui vous dit "je n'ouvre aucun fichier" et qui envoie quand même tout votre dépôt Git, historique compris, vers ses propres serveurs : c'est ce qu'un chercheur en sécurité a documenté sur Grok Build, l'agent CLI de codage de xAI, à la mi-juillet 2026.

Ce que le chercheur a découvert

Le 13 juillet 2026, le chercheur indépendant connu sous le pseudonyme Cereblab publie une analyse technique de Grok Build (version 0.2.93). Sa méthode : faire transiter le trafic réseau de l'outil par un proxy local pour observer exactement ce qui en sort. Il identifie deux canaux distincts : un canal "modèle" (/v1/responses), normal pour un agent de code, et un canal "stockage" (/v1/storage), beaucoup plus problématique.

Son test le plus parlant : il demande à Grok Build de répondre simplement "OK", sans ouvrir aucun fichier. L'outil génère quand même un bundle Git complet du dépôt local, historique de commits inclus, et l'envoie vers un bucket Google Cloud opéré par xAI. Sur un dépôt de test de 12 Go, le canal modèle n'a transporté que 192 Ko, quand le canal stockage en a fait transiter 5,1 Go, un écart d'environ 27 800 fois. Les requêtes étaient découpées en une soixantaine de blocs d'environ 75 Mo, tous acceptés par le serveur distant (code HTTP 200).

Preuve supplémentaire : Cereblab avait placé un fichier-appât ("canary"), jamais lu par l'agent pendant la session, portant un marqueur unique. Ce fichier s'est retrouvé intégralement dans le bundle uploadé, aux côtés de l'historique complet du dépôt.

Le vrai problème : l'écart entre ce que l'outil affirme et ce qu'il fait

Ce qui rend l'affaire sérieuse, ce n'est pas seulement le volume de données exfiltrées, c'est la contradiction entre l'instruction donnée ("n'ouvre aucun fichier") et le comportement réel de l'outil. Un agent qui prétend respecter une consigne tout en aspirant l'intégralité du contexte de travail ne se trompe pas : il désinforme son utilisateur sur ce qu'il fait réellement de ses données.

Parmi les fichiers capturés figurait un .env non expurgé, contenant des clés d'API et des mots de passe de base de données en clair. Un dépôt Git peut aussi contenir, dans son historique, des secrets qu'un développeur a retirés de son code actuel sans les purger des commits passés : ce type d'upload massif les remet en circulation.

Cereblab précise une limite importante à son analyse : il documente une transmission, une acceptation et un stockage, pas un usage ultérieur de ces données pour l'entraînement de modèles. C'est une distinction utile, mais elle ne change rien au problème de fond : la promesse de confidentialité affichée par l'outil ne correspondait pas à son comportement réseau réel.

La réponse de xAI : correctif serveur, puis open source présenté comme geste de transparence

Sous pression, xAI corrige le comportement côté serveur dès le 13 juillet : Cereblab confirme que les requêtes vers /v1/storage cessent, avec des indicateurs disable_codebase_upload: true et trace_upload_enabled: false renvoyés par le serveur. Elon Musk annonce sur X que toutes les données uploadées avant cette date seraient "complètement et intégralement supprimées".

Aucun audit indépendant n'est venu, à ce jour, confirmer l'étendue réelle de cette suppression, le nombre d'utilisateurs concernés, ni la durée pendant laquelle ces données ont été conservées. xAI a communiqué sur X plutôt que via une note de sécurité officielle ou un changelog, ce qui limite la traçabilité de l'incident.

Deux jours plus tard, le 15 juillet, xAI passe Grok Build en open source intégral sur GitHub et remet à zéro les quotas d'usage. Présenté comme un geste d'ouverture, ce choix ressemble surtout à une opération de nettoyage habileée en générosité : en permettant à l'outil de tourner localement, xAI se retire tout simplement du circuit de la donnée, ce qui résout le problème sans jamais avoir à en détailler l'ampleur exacte.

Grok Build est-il un cas isolé ?

Cereblab a reproduit son protocole de test sur Claude Code, Codex (OpenAI) et Gemini CLI. Aucun de ces trois outils n'a généré d'envoi massif et systématique de dépôt complet dans les mêmes conditions. Cela ne signifie pas que ces outils sont irréprochables sur la donnée : tous les agents de code cloud envoient nécessairement au modèle les fichiers qu'ils traitent. La différence documentée ici porte sur la collecte de l'intégralité de l'espace de travail, y compris ce que l'agent n'a jamais eu besoin de lire.

C'est précisément ce qui rend le sujet plus large qu'un bug ponctuel : quand un outil affirme respecter une consigne de confidentialité tout en faisant l'inverse, la question qui se pose n'est plus seulement technique, elle porte sur la validation de ce que ces agents produisent et transmettent en votre nom, un sujet que je traitais déjà sous l'angle de la gouvernance de l'IA en agence.

Ce qu'il faut faire si vous avez utilisé Grok Build avant le 13 juillet

Ne pas attendre la confirmation de suppression côté xAI. Concrètement : faites tourner tous les secrets présents dans vos fichiers suivis (clés d'API, mots de passe), y compris ceux que vous auriez retirés du code actuel mais qui subsistent dans l'historique Git. Si vous avez utilisé la version cloud avant cette date, considérez que le contenu complet de vos dépôts a potentiellement transité par les serveurs de xAI, indépendamment de ce que l'outil affichait comme paramètres de confidentialité.

Sources : The Hacker News, Usine Digitale, Next.ink, CryptoBriefing.

Questions fréquentes

xAI a-t-il menti délibérément ?

Les preuves techniques établissent une transmission, une acceptation et un stockage massifs de données non nécessaires à la tâche demandée, en contradiction avec les instructions données à l'outil. Aucune preuve publique n'établit en revanche une intention délibérée ni un usage ultérieur de ces données pour l'entraînement.

Mon code a-t-il servi à entraîner Grok ?

Rien ne le prouve à ce jour. Le chercheur à l'origine de la découverte est explicite sur ce point : il documente la transmission et le stockage, pas l'entraînement.

Le correctif du 13 juillet est-il suffisant ?

Il arrête les nouveaux envois côté serveur et l'open source du 15 juillet permet un usage local sans remontée de données. Mais aucun audit indépendant n'a confirmé la suppression complète des données déjà collectées avant cette date.