Ein Sicherheitsforscher hat xAIs Coding-Agent Grok Build beim heimlichen Datentransfer erwischt. Das Tool lädt gesamte Code-Repositories auf xAI-Server hoch, obwohl es als lokal-first beworben wird. Selbst der Opt-out-Schalter stoppt die Übertragung nicht.
Was der Wire-Level-Teardown enthüllt
Der Forscher cereblab leitete den Netzwerkverkehr von Grok Build CLI Version 0.2.93 durch einen Proxy und schnitt jeden Datenpak ab. Das Ergebnis: Das Tool betreibt zwei parallele Datenkanäle. Der erste sendet Dateiinhalte an cli-chat-proxy.grok.com, damit das Sprachmodell Kontext bekommt. Das ist erwartet. Der zweite Kanal lädt jedoch das gesamte Arbeitsverzeichnis als git-Bundle hoch, und zwar über einen separaten POST-Aufruf an /v1/storage.
Bei einem 12 Gigabyte großen Test-Repository übertrug der Speicherkanal 5,1 Gigabyte in 73 Chunks. Alle 83 Speicheranfragen lieferten HTTP-200 zurück, ohne einen einzigen Fehler. Zudem fand der Forscher eine Canary-Testdatei im wiederhergestellten Bundle, die der Agent nie geöffnet hatte. Der Upload greift also auf alles zu, was im Workspace existiert, nicht nur auf das, was Grok tatsächlich liest.
Umgehe .env-Dateien und fehlende Transparenz
Besonders brisant: Der Model-Turn-Kanal überträgt .env-Dateien ungefiltert. Der Forscher platzierte einen Canary-Eintrag mit API_KEY=CANARY7F3A9-SECRET-should-not-leave in einer Secrets-Datei. Der komplette String erschien unredigiert im erfassten Datenverkehr. Eine 48 Kilobyte große Datei mit Datenbank-Zugangsdaten und API-Schlüsseln wanderte im Klartext.
xAI hatte Grok Build als lokal-first beworben. Die Marketingseite versprach, dass während einer Sitzung nichts aus der Codebasis an xAI-Server übertragen werde. Die Wire-Level-Beweise erzählen eine andere Geschichte. Zudem steuert der Datenschutz-Schalter nur die Einwilligung zum Modelltraining, nicht den Upload selbst. Nach dem Deaktivieren von Improve the Model zeigte die Server-Antwort weiterhin trace_upload_enabled: true.
Größenordnungen und fehlende Dokumentation
Der Zahlenvergleich verdeutlicht das Ausmaß. Der Model-Turn-Kanal übertrug 196.705 Byte über fünf Anfragen. Der Speicherkanal sandte 5,1 Gigabyte. Das bedeutet, dass Grok Build 27.800-mal mehr Daten über den Hintergrundkanal verschickt als über den sichtbaren Modellkontext. Der Zielspeicher nutzt einen Google Cloud Storage-Bucket namens grok-code-session-traces. Weder die Onboarding-Dokumentation noch die CLI-Einrichtung erwähnen diesen Bucket.
xAIs Verbraucherrichtlinien decken die Datennutzung auf hoher Ebene ab. Die Begriffe repo_state, session_state, Upload-Warteschlange und die Pipeline grok-code-session-traces kommen in den Einrichtungsmaterialien jedoch nicht vor.
Was Entwickler jetzt tun sollten
Für Teams, die Grok Build einsetzen, lautet die einfache Empfehlung: Das Tool als Cloud-Dienst behandeln, der möglicherweise mehr hochlädt als die Dateien, die der Agent liest. Wer es in Repositories mit echten Zugangsdaten genutzt hat, sollte diese Credentials sofort rotieren. Zudem rät der Forscher zu Zero-Disk-Secrets: Zugangsdaten gehören in Remote-Vaults und werden zur Laufzeit injiziert, damit keine .env-Datei existiert, die ausgelesen werden kann.
Unternehmen können die .grokignore-Datei nutzen, um sensible Verzeichnisse auszuschließen. Die offizielle Enterprise-Dokumentation erwähnt diesen Mechanismus jedoch nicht. Der Zero-Data-Retention-Modus für Enterprise-Kunden verhindert immerhin die dauerhafte Speicherung auf Inferenzebene. Ob das auch den Upload stoppt, ist unklar.
Ein Branchenproblem weit über xAI
Der Vorfall trifft auf ein grundlegendes Vertrauensproblem der KI-Coding-Agenten-Branche. Alle großen Tools lesen .env-Dateien. .gitignore bietet nur teilweisen Schutz, da Agenten mit Shell-Zugang diese Listen umgehen können. Die Besonderheit bei Grok Build liegt im Maßstab, nämlich komplette Repositories statt einzelner gelesener Dateien, und in der fehlenden Dokumentation.
Der KI-Coding-Agent-Markt kämpft hart um Entwicklervertrauen. Vertrauen ist die eine Ressource, die sich nicht wiederherstellen lässt, wenn sie einmal verloren ist. xAI hat jetzt die Chance, das Offenlegungsproblem zu beheben: eine klare Datenhandling-Dokumentation veröffentlichen, den Zweck des Storage-Buckets dokumentieren und sicherstellen, dass der Opt-out-Schalter tatsächlich das bewirkt, was er verspricht.
