Du öffnest Dein Terminal, tippst grok build. Was passiert im Hintergrund? Der Sicherheitsforscher @cereblab hat den Netzwerkverkehr der offiziellen Grok Build CLI (Version 0.2.93) mit einem Man-in-the-Middle-Proxy untersucht. Die Analyse zeigt, was tatsächlich an die xAI-Server übertragen wird – mehr als viele Entwickler vermuten.
Stell Dir vor, Du bittest einen Kurier, einen Brief abzuholen. Er nimmt den Brief, fotografiert aber auch Deine ganze Wohnung. Grok Build verhält sich ähnlich: Es sendet nicht nur die Dateien, die der Agent liest, sondern lädt das gesamte Repository hoch – unabhängig davon, ob Du diese Dateien jemals ansprichst.
Die Untersuchung identifiziert drei Befunde. Die Analyse ist offen einsehbar und kann selbst nachvollzogen werden. Der Forscher hat einen kanariengeschützten Test-Ordner verwendet, in dem jede Datei einen eindeutigen Marker trägt – so lässt sich jeder Datenleck zweifelsfrei zurückverfolgen.
1. Dateiinhalte (inklusive Secrets) werden unzensiert übertragen
Wenn Grok eine Datei liest, etwa weil Du nach einem API-Key fragst, werden die Inhalte im Klartext an die xAI-Server gesendet. Das geschieht über zwei Kanäle: den regulären Modell-Turn (POST /v1/responses) und einen separaten Upload in den Speicher (POST /v1/storage). In einem Test erhielt der Forscher eine .env-Datei mit einem fiktiven Datenbank-Passwort (CANARY7F3A9-DBPASS) und einem API-Key. Beide Marker tauchten unverändert im abgefangenen Body des /v1/responses-Requests auf – Größe 48 KB. Zusätzlich landete die gleiche .env in einem session_state-Archiv, das an den GCS-Bucket grok-code-session-traces hochgeladen und mit HTTP 200 bestätigt wurde. Der Forscher merkt an: Es handelt sich nicht um echte Zugangsdaten, aber der Mechanismus ist derselbe. Ein Kontrollversuch mit einer Datei, die der Agent explizit nicht öffnen sollte, zeigte, dass deren Marker nicht im Modell-Turn auftauchte – das Leck ist auf die gelesenen Dateien beschränkt. Allerdings wird eine .env wie jede andere Datei behandelt, eine automatische Redaktion von Secrets gibt es nicht.
2. Das gesamte Repository wird hochgeladen – auch wenn es nie gelesen wird
Ein weiterer Befund: Der Forscher testete mit einem 12 GB großen Repository, das nur aus Zufallsdateien bestand und das er mit dem Prompt „Antworte OK, lies keine Dateien“ ansprach. Der Modell-Kanal (/v1/responses) beförderte 192 KB – Chat-Texte und Metadaten. Der Speicherkanal (/v1/storage) dagegen bewegte 5,1 GiB (73 Chunks à ~75 MB, alle mit HTTP 200 bestätigt). Das Verhältnis: 27.800:1. Die Erklärung: Hier wird nicht das Gelesene, sondern das gesamte Arbeitsverzeichnis als Snapshot hochgeladen. Der Forscher stoppte das Experiment während des laufenden Uploads – der Upload war noch nicht abgeschlossen. In kleineren Tests (64 MB, 600 MB, 3 GB) bestätigte sich das Muster: Die Upload-Größe skaliert mit der Repository-Größe, kein Speicher-Limit in Sicht. Einzige Fehler waren 402/429 (Kontingentüberschreitung beim Modell) – der Speicherkanal blieb fehlerfrei.
3. Ziel ist ein Google Cloud Storage Bucket – nicht AWS
Die gesammelten Daten landen in einem Google Cloud Storage Bucket namens grok-code-session-traces. Der Forscher extrahierte diesen Namen direkt aus der Binary (strings auf die Rust-Binary) und fand ihn in einem abgefangenen metadata.json wieder: grok-code-session-traces/…. Dieser Mechanismus wird in der CLI-Dokumentation nicht erwähnt. Er ist standardmäßig aktiv – selbst wenn Du in den Einstellungen „Improve the model“ deaktivierst, bleibt trace_upload_enabled: true (geprüft über /v1/settings). Der Forscher hat nicht bewiesen, dass xAI die Daten für Training verwendet – das ist eine Frage der Policy, nicht der Infrastruktur. Die Übertragung und Speicherung ist nachgewiesen.
Was bedeutet das für Dich?
Die Analyse ist reproduzierbar und transparent. Wer Grok Build nutzt, sollte sich bewusst sein, dass sein gesamter Code – inklusive möglicher Secrets – an xAI gesendet und auf Google Cloud gespeichert wird. Seit der Veröffentlichung dokumentierte der Forscher, dass xAI den Upload des Code-Base (disable_codebase_upload: true) serverseitig deaktiviert hat und ein Privacy-Opt-In (/privacy opt-out) eingeführt hat – dieses stellte sich als reine Datenaufbewahrungseinstellung heraus, die nicht verhindert, was gesendet wird. Elon Musk versprach, alle bis dahin hochgeladenen Daten zu löschen – ob das geschehen ist, ist unklar.
Verwende Grok Build nicht in Repositorys mit vertraulichen Informationen. Lege explizite .grokignore-Dateien an. Überlege, ob Du diesen Dienst brauchst. Es geht um informierte Entscheidungen. Der Forscher @cereblab hat die Beweise auf GitHub veröffentlicht (github.com/cereblab/grok-build-exfil-repro) – jeder kann die Tests auf einer eigenen Maschine mit einem Wegwerf-Repository nachvollziehen.
Quelle: gist.github.com
