cereblab zufolge zerlegte Grok Build den Speicher-Upload in 73 Blöcke von jeweils etwa 75 MB, die sämtlich mit HTTP 200 quittiert wurden. In den Versuchen folgte das übertragene Volumen der Gesamtgröße des jeweiligen Repositories. Als Ziel wurde der Bucket grok-code-session-traces identifiziert, der sowohl in der Binärdatei als auch in einer vorbereiteten metadata.json auftaucht; deren Dateipfade verweisen auf gs://grok-code-session-traces/.
Zu den Testdateien gehörte src/_probe/never_read_canary.txt, versehen mit einem eindeutigen Marker. Nach dem Klonen des abgefangenen Bundles ließ sich diese Datei unverändert wiederherstellen, zusammen mit der vollständigen Commit-Historie des Repositories. Laut cereblab ließ sich derselbe Befund auch mit einem zweiten, unabhängigen Repository reproduzieren. Die Aufzeichnungen belegten damit Übertragung, Annahme und Speicherung der Daten, nicht jedoch ein Training des Modells.
Der Forscher betont ausdrücklich, dass aus dem Test nicht folge, xAI habe auf dem Code trainiert, Mitarbeitende hätten den Inhalt gelesen oder gitignore-Dateien würden stets mit erfasst. Sichtbar auf der Leitung seien verfolgte Dateien samt Historie. Separat davon beschreibt cereblab einen einfacheren Pfad für Geheimnisse: Liest Grok eine Datei, wandert deren Inhalt in den Modellaufruf. So wurde eine verfolgte .env-Datei ohne Schwärzung übertragen, einschließlich der platzierten Testwerte für API_KEY und DB_PASSWORD. Derselbe Inhalt landete außerdem in einem session_state-Archiv für den Speicherkanal. Echte Zugangsdaten wurden laut Test nicht offengelegt, weil die platzierten Geheimnisse fingiert waren.
Besonders brisant ist laut dem Bericht, dass die naheliegende Einstellung nichts änderte. Selbst bei deaktivierter Option „Modell verbessern“ lud Grok das Repository weiter hoch. Die Serverantwort auf /v1/settings lieferte dabei weiterhin trace_upload_enabled: true. Diese Option steuere, ob Daten zum Training des Modells verwendet werden, nicht aber, ob Code den Rechner verlässt. Damit seien zwei verschiedene Kontrollen im Spiel gewesen, von denen nur eine für Nutzer sichtbar war.
In einem Vergleich mit anderen Werkzeugen stellte cereblab fest, dass Claude Code und Codex kein Repository-Bundle übermittelten. Gemini habe in einem Leerlauftest ebenfalls keines gesendet; ein realistischerer Testlauf sei jedoch vor Abschluss an einem Kontingent-Limit gescheitert. Grok Build sei damit der Ausreißer gewesen. Dass Cloud-Coding-Agenten geöffnete Dateien an ein entferntes Modell senden, sei erwartbar; die vollständige Erfassung des Arbeitsbereichs sei aber spezifisch bei Grok Build beobachtet worden.
Am 13. Juli stellte dieselbe Binärdatei 0.2.93 laut cereblab den Speicherverkehr ein. In sechs Wiederholungstests seien keine Uploads an /v1/storage mehr aufgetreten, während der Server nun disable_codebase_upload: true und trace_upload_enabled: false zurückgab. Der Entwickler Peter Dedene meldete denselben Rückgabewert für sein Konto. Das spricht laut Bericht für eine serverseitige Abschaltung statt für eine per Update ausgelieferte Korrektur. xAI habe bislang nicht bestätigt, ob das für alle Konten gilt oder dauerhaft ist.
Öffentlich reagierte xAI nach Angaben des Quelltexts bislang über X statt über einen Sicherheitshinweis oder Changelog-Eintrag. Der Account @SpaceXAI erklärte, bei Enterprise-Teams mit Zero Data Retention würden weder Code noch Trace-Daten gespeichert; auch die Nutzung per API-Schlüssel beachte ZDR. Für Verbraucher, die diese Funktion nicht aktiviert haben, lasse sich in der CLI mit /privacy die Speicherung deaktivieren und bereits synchronisierte Daten löschen. Elon Musk erklärte darüber hinaus, alle bislang hochgeladenen Nutzerdaten würden „vollständig und restlos gelöscht“. Für Einzelabonnenten ist laut Quelltext der Befehl /privacy die angebotene Kontrolle.
cereblab hält außerdem fest: Eine gitignore-Datei, die nie committet wurde, blieb aus dem Bundle heraus. Eine Datei, die einmal committet war, reiste über die Historie mit; späteres Löschen entfernt sie dort nicht. Eine separate Analyse von Build 0.2.99 fand den Upload-Code weiterhin in der Binärdatei, nur durch ein Server-Flag deaktiviert. Warum vollständige Repositories standardmäßig hochgeladen wurden, wie lange sie aufbewahrt wurden und wie viele Nutzer betroffen waren, habe xAI bisher nicht beantwortet.