Eine unabhängige Analyse hat gemessen, was xAIs Coding-Werkzeug Grok Build tatsächlich verschickt: nicht nur die Dateien, die das Modell liest, sondern das komplette Git-Repository samt Historie. Der Datenschutzschalter in den Einstellungen hat das nicht verhindert. Für Entwicklerteams im deutschsprachigen Raum ist das keine Telemetrie-Frage, sondern eine Frage von Auftragsverarbeitung und Geschäftsgeheimnis.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Grok Build brauchte für eine einzige Modellantwort rund 192 Kilobyte Kontext. Den Rechner verlassen haben in derselben Sitzung 5,10 Gibibyte. Diese Lücke hat der unabhängige Prüfer Cereblab auf Protokollebene dokumentiert, und sie wirft eine Frage auf, die weit über xAI hinausreicht.
Das Wichtigste in Kürze
- Grok Build in der Version 0.2.93 hat getrackte Repositories als vollständiges Git-Bundle in den Google-Cloud-Speicher „grok-code-session-traces“ geladen, samt Commit-Historie.
- Bei einem 12-Gigabyte-Testprojekt flossen 5,10 GiB über den Speicherkanal, während der Modellkanal nur 192 Kilobyte benötigte.
- Der sichtbare Schalter „Improve the model“ steuerte allein das Training, nicht den Transport. Der Server meldete weiterhin
trace_upload_enabled: true. - Seit dem 13. Juli 2026 unterbindet ein serverseitiges Flag die Uploads. Ein Sicherheitsadvisory hat xAI dazu nicht veröffentlicht.
Was hat Grok Build tatsächlich verschickt?
Grok Build hat das komplette getrackte Repository als Git-Bundle an xAI übertragen, nicht nur die Dateien, die das Modell für die Aufgabe gelesen hat. Die Commit-Historie ging mit, ebenso der Inhalt einer getrackten .env-Datei mit Zugangsdaten.
Messung statt Vermutung: Cereblab hat den Datenverkehr der Version 0.2.93 auf der Leitung mitgeschnitten[1]. Bei einem 12-Gigabyte-Projekt hat die Analyse 82 Uploads in 73 Blöcken von je rund 75 Megabyte gezählt, zusammen 5.476.083.317 Byte. Über den Modellkanal gingen im selben Lauf 196.705 Byte.
Der Köder: Cereblab hat eine Datei namens never_read_canary.txt mit einer eindeutigen Markierung in das Projekt gelegt und den Agenten angewiesen, keine Datei zu öffnen. Aus dem abgefangenen Bundle ließ sich die Datei anschließend per git clone wiederherstellen, Markierung inklusive.
Zugangsdaten im Klartext: Eine getrackte .env-Datei ist ungeschützt mitgereist. Die hinterlegten Testwerte für API_KEY und DB_PASSWORD sind unredigiert im Modellaufruf aufgetaucht und zusätzlich im hochgeladenen session_state-Archiv.
Warum hat der Datenschutzschalter nicht gegriffen?
Der sichtbare Schalter „Improve the model“ hat allein die Verwendung der Daten fürs Training geregelt, nicht deren Übertragung. Beide Kanäle waren getrennt, und nur einer war in der Oberfläche erreichbar.
Entkoppelte Einwilligung: Genau hier liegt der Mechanismus, der den Fall über xAI hinaus interessant macht. Das Abwählen des Trainings hat am Transport nichts geändert, der Server hat weiterhin trace_upload_enabled: true zurückgemeldet. Die Zustimmung hat sich auf die Nutzung der Daten bezogen, nicht auf ihren Abfluss.
Das echte Veto: Wirksam war allein ein Riegel in Feldern, die in keiner Oberfläche auftauchen. Dazu gehören disable_codebase_upload in der Datei ~/.grok/config.toml, der Telemetrie-Schalter trace_upload und die Umgebungsvariable GROK_TELEMETRY_TRACE_UPLOAD, die beide übersteuert.
Die Reaktion: Am 13. Juli 2026 hat xAI den Upload serverseitig gestoppt. Dieselbe Binärdatei hat in sechs Wiederholungen nichts mehr verschickt, der Server meldet seither disable_codebase_upload: true. Elon Musk hat auf der Plattform X angekündigt, bereits hochgeladene Nutzerdaten vollständig zu löschen, und xAI hat auf die Zero-Data-Retention-Option für Unternehmensteams verwiesen. Cereblab widerspricht der Darstellung, der Befehl /privacy sei die Lösung gewesen. Dieser Befehl schalte lediglich die Aufbewahrung je Sitzung ab.
Was der sichtbare Schalter tat
- ◆ „Improve the model“ steuerte allein, ob die Daten ins Training fließen
- ◆ Abgeschaltet meldete der Server dennoch trace_upload_enabled: true
- ◆ Der Befehl /privacy regelte nur die Aufbewahrung je Sitzung
Was den Upload wirklich stoppte
- ◆ disable_codebase_upload = true in ~/.grok/config.toml
- ◆ Der Telemetrie-Schalter trace_upload = false
- ◆ GROK_TELEMETRY_TRACE_UPLOAD=false, das alles andere übersteuert
- ◆ Seit 13.07.2026 zusätzlich ein serverseitiges Flag bei xAI
Der Beweis lag im Köder
Eine Datei namens never_read_canary.txt, die der Agent ausdrücklich nicht öffnen sollte, ließ sich aus dem hochgeladenen Bundle vollständig wiederherstellen. Eine getrackte .env-Datei reiste mit Zugangsdaten im Klartext mit.
Ein Opt-out, das nur das Training abschaltet und nicht den Transport, ist kein Datenschutz, sondern eine Beschriftung. Entscheidend ist, was die Leitung verlässt, nicht was das Modell davon lernt.
— Markus Seyfferth, Chefredakteur Dr. Web
Was bedeutet das für deutsche Entwicklerteams?
Verlässt Quellcode unbemerkt das Haus, greifen zwei Regelwerke: die DSGVO, sobald personenbezogene Daten im Repository stecken, und das Geschäftsgeheimnisgesetz, das den Schutz an angemessene Geheimhaltungsmaßnahmen knüpft.
Eine Gattung, kein Einzelfall: Der Vorfall reiht sich in ein Muster ein, das die KI-Werkzeugkette derzeit prägt. Vergangene Woche hat der Datenabfluss bei Synopsys gezeigt, wie ein Zulieferer zum Leck für Bosch-Entwicklungsdaten wird. OpenAI verschlüsselt inzwischen die Prompts seiner Sub-Agenten, und Projekte wie Clawk sperren den Coding-Agenten in eine Wegwerf-VM, statt ihm den Arbeitsrechner zu überlassen.
Kontrolle nur auf dem Papier: Auch der Streit um den KI-Trainingsschalter bei Samsung Health folgt demselben Schema: Das Bedienelement verspricht Kontrolle, die Infrastruktur dahinter hält sie nicht. Dass KI-Werkzeuge in Entwicklungsteams längst produktiv laufen, belegen Microsofts Realdaten zu Claude Code und Copilot CLI. Umso schwerer wiegt, was sie im Hintergrund abtransportieren.
Der rechtliche Hebel: Das Geschäftsgeheimnisgesetz schützt Quellcode nur, solange ein Unternehmen angemessene Geheimhaltungsmaßnahmen nachweisen kann. Ein Werkzeug, das die Codebasis ungefragt in einen fremden Cloud-Speicher schiebt, untergräbt genau diesen Nachweis. Stecken zusätzlich personenbezogene Daten im Repository, etwa in Testdatensätzen oder Kommentaren, wird der Vorfall zur meldepflichtigen Datenpanne nach Artikel 33 DSGVO.
Vier Schritte für die Praxis: Diese Punkte sollten Teams jetzt abarbeiten:
- Alle Zugangsdaten rotieren, die in getrackten Dateien wie .env lagen, unabhängig davon, ob der Agent sie je geöffnet hat.
- Den Upload hart abschalten, mit
disable_codebase_upload = truein~/.grok/config.tomlundGROK_TELEMETRY_TRACE_UPLOAD=falsein der Build-Umgebung. - Prüfen, ob für den KI-Anbieter ein Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO vorliegt und wie der Datentransfer in die USA abgesichert ist.
- Den ausgehenden Datenverkehr der Entwicklerrechner protokollieren. Ohne eigene Messung lässt sich nicht feststellen, was ein Werkzeug wirklich verschickt.
Der serverseitige Riegel bei xAI ist eine Zusage, kein Vertrag. Solange weder ein Advisory noch ein Löschnachweis vorliegt, gehört Grok Build auf Firmenrechnern in die Sandbox oder in die Zero-Data-Retention-Variante, und die harten Konfigurations-Flags gehören ins Basis-Image der Entwicklungsumgebung, nicht in die Hände einzelner Entwickler. Denselben Test sollte jedes Team auch bei den übrigen Coding-Agenten in seiner Werkzeugkette fahren.
Quelle
[1] Cereblab: „What xAI Grok Build CLI actually sends to xAI. A wire-level analysis (grok 0.2.93)“ ↩
Mehr Newshunger?
- Erpresser drohen mit Bosch-Daten: Wie ein Formularfehler bei Synopsys zum Lieferketten-Leck wird
- Codex verschlüsselt jetzt die Prompts seiner Sub-Agenten
- Clawk gibt dem KI-Coding-Agenten eine eigene Wegwerf-VM statt Ihres Rechners
- Samsung Health droht mit Löschung der Daten, wenn Nutzer das KI-Training ablehnen
- SAP-Patchday im Juli: Eine 9,9-Lücke trifft den Kern jedes ABAP-Systems
- Cloudflare Precursor: Bots verraten sich jetzt an der Mausbewegung
