Ein Entwickler hat mit einem Netzwerk-Mitschnitt geprüft, was die Grok Build CLI von xAI im Hintergrund überträgt. Herausgekommen ist mehr als erwartet: das komplette Repository samt Git-Historie und eine Klartext-Datei mit Passwörtern, unabhängig davon, welche Dateien der Agent überhaupt liest. Für Firmen mit schützenswertem Quellcode ist das ein handfestes Compliance-Problem.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Die Grok Build CLI sollte in einem Test nur eine einzige Datei öffnen, hochgeladen hat sie am Ende das ganze Projekt. Eine technische Analyse unter dem GitHub-Handle cereblab hat dafür eine präparierte .env mit dem Passwort-Köder „CANARY7F3A9″ ins Repository gelegt und den Datenverkehr über einen Proxy mitgeschnitten[1]. Der Köder ist im Klartext auf xAIs Servern wieder aufgetaucht.
Das Wichtigste in Kürze
- Die Grok Build CLI lädt bei jeder Sitzung das ganze Repository als Git-Bundle hoch, samt Commit-Historie und Dateien, die der Agent nie öffnet.
- In einem 12-GB-Test sind rund 5,1 GiB an xAI gegangen, etwa das 27.800-Fache des sichtbaren Chat-Verkehrs.
- Eine
.env-Datei mit Klartext-Passwörtern wurde ungefiltert übertragen. - Der Schalter „Improve the model“ stoppt den Upload nicht: Der Server meldet weiter
upload_enabled: true.
Was lädt die Grok Build CLI wirklich hoch?
Die Grok Build CLI überträgt zwei Datenströme: die vom Agenten gelesenen Dateien im Chat-Verlauf und, davon getrennt, das komplette Repository als Git-Bundle an einen Cloud-Speicher. Der zweite Kanal läuft unabhängig davon, was das Modell tatsächlich anfasst.
Den Unterschied macht dieser zweite Kanal. Der sichtbare Chat-Verkehr hat im Test knapp 197 Kilobyte umfasst, parallel dazu hat die CLI das gesamte Projekt als Git-Bundle in einen Google-Cloud-Speicher geschoben, aufgeteilt in 73 Blöcke zu je rund 75 Megabyte. Selbst eine Datei mit dem ausdrücklichen Marker „nicht öffnen“ ist vollständig auf dem Server gelandet.
Weil das Bundle die komplette Git-Historie enthält, lässt sich das Repository aus dem Upload per git clone wiederherstellen. Damit reisen auch längst gelöschte Zugangsdaten mit, die in früheren Commits stecken. Genau dieses Muster kennt man von anderen Werkzeugen: OpenAI Codex konnte sensible Dateien lange nicht zuverlässig ausschließen, und GitHubs KI-Agent ließ sich zur Preisgabe privater Repositories verleiten.
Warum schützt der Opt-out-Schalter nicht?
Der Schalter „Improve the model“ ist ab Werk aktiv und stoppt den Repository-Upload auch im ausgeschalteten Zustand nicht. Die Server-Antwort meldet weiterhin upload_enabled: true und trace_upload_enabled: true, der Datenabfluss läuft also unverändert weiter.
Ein aktiver Schalter suggeriert eine Kontrolle, die der Nutzer nicht hat. Ob xAI die Daten zum Training verwendet, ist damit noch nicht gesagt; hochgeladen und gespeichert werden die Daten unabhängig davon. Für vertraulichen Code zählt aber schon der Transfer, nicht erst die spätere Nutzung.
Der Fall reiht sich in einen Branchentrend ein. Als GitHub im April 2026 in seiner CLI die Telemetrie per Voreinstellung aktiviert hat[2], sind zwar nur Nutzungs-Metadaten an die Server gegangen, nicht der Quellcode. Die Richtung stimmt trotzdem: Datensammlung als Standard, Widerspruch als Kleingedrucktes. Sichtbar wird der Abfluss erst mit einem eigenen Mitschnitt des Datenverkehrs, wie ihn das Analyse-Tool Mcpsnoop für KI-Traffic vormacht.
Ein Schalter, der ausgeschaltet nichts ausschaltet, ist keine Datenschutzeinstellung, sondern Kosmetik. Solange ein Coding-Werkzeug den gesamten Quellcode ungefragt in die Cloud eines Anbieters spiegelt, gehört es in Unternehmen mit Betriebsgeheimnissen nicht auf den Entwickler-Rechner.
— Markus Seyfferth, Chefredakteur Dr. Web
Ein Proxy-Mitschnitt zeigt, wie viel mehr als der Chat-Verkehr das Werkzeug überträgt.
Kanal A: Chat mit dem Modell
Nur die Dateien, die der Agent im Verlauf tatsächlich liest.
Kanal B: Speicher-Upload
Das komplette Repository als Git-Bundle, mit voller Commit-Historie.
Was bedeutet das für Unternehmen im DACH-Raum?
Für Firmen im DACH-Raum berührt der ungefragte Upload zwei Rechtsgebiete: den Schutz von Geschäftsgeheimnissen und die DSGVO. Quellcode, der Zugangsschlüssel oder personenbezogene Testdaten enthält, verlässt ohne Rechtsgrundlage die eigene Infrastruktur.
Das Geschäftsgeheimnisgesetz schützt Betriebsgeheimnisse nur, solange „angemessene Geheimhaltungsmaßnahmen“ bestehen. Wandert der Quellcode ungefragt in die Cloud eines Dritten, kann genau dieser Schutz verloren gehen. Steckt in Commits oder Testdaten außerdem Personenbezug, greift die DSGVO, und ein Transfer zu einem US-Anbieter braucht Rechtsgrundlage und Auftragsverarbeitungsvertrag. Die Haftung für beides bleibt bei der Geschäftsführung, nicht beim Entwickler, der das Tool installiert hat.
Vier Schritte senken das Risiko schnell:
- Zugangsdaten und
.env-Dateien grundsätzlich aus dem Repository heraushalten und in einen Secrets-Manager auslagern. - Den ausgehenden Datenverkehr neuer KI-CLIs einmal über einen Proxy prüfen, bevor ein Werkzeug freigegeben wird.
- Vor dem Rollout klären, ob ein Auftragsverarbeitungsvertrag mit dem Anbieter vorliegt.
- Coding-Agenten für vertrauliche Projekte auf lokal laufende Modelle beschränken.
Bis xAI den Repository-Upload transparent macht und den Opt-out wirksam schaltet, bleibt die Grok Build CLI für vertraulichen Code ein Risiko. Ein kurzer Proxy-Mitschnitt vor dem Rollout zeigt in Minuten, welche Werkzeuge das ganze Projekt abziehen und welche nur lesen, was sie brauchen. Ein sauberes Threat Model für KMU ordnet solche Werkzeuge schon vor dem ersten Einsatz richtig ein.
Quellen
[1] cereblab: „What xAI’s Grok Build CLI Actually Sends to xAI“ (Wire-Level-Analyse) ↩
[2] GitHub: „GitHub CLI opt-out usage telemetry“ ↩
Mehr Newshunger?
- OpenAI Codex kann sensible Dateien noch immer nicht ausschließen
- GitLost: Wie sich GitHubs KI-Agent zur Preisgabe privater Repositories verleiten lässt
- SymJack: Wie ein Symlink Claude Code und Copilot austrickst
- Fünf neue Prompt-Injection-Angriffe: Wie sich KI-Agenten heimlich umprogrammieren lassen
- Unsichtbare Befehle im Quelltext: Wie manipulierte Webseiten KI-Agenten zur Zahlung bringen
- So macht Mcpsnoop KI-Traffic sichtbar
