Ein KI-Coding-Tool hat komplette Code-Repositories heimlich in die Cloud hochgeladen, einschließlich gelöschter Passwörter und SSH-Schlüssel. Jetzt geht der Quellcode unter Apache 2.0 online, doch die Fragen bleiben.
Was ist passiert?
Der Sicherheitsforscher Cereblab hatte am 13. Juli 2026 öffentlich dokumentiert, dass Grok Build, das Terminal-basierte Coding-Tool von SpaceXAI, weit mehr Daten an Server von xAI übertrug als nötig oder angekündigt. Konkret: Selbst wenn Nutzer das CLI anwiesen, keine Dateien zu öffnen, lud das Tool komplette Git-Repositories samt Historie in einen Google Cloud Storage-Bucket hoch. Auch Dateien, die aus der Historie gelöscht worden waren, wurden übertragen. Andere Nutzer berichteten, dass ihr gesamtes Nutzerverzeichnis mit SSH-Keys und Passwortmanager-Datenbanken ausgelesen und hochgeladen wurde.
Das Ausmaß überstieg vergleichbare Tools wie Claude Code, Gemini CLI oder Codex deutlich. Diese öffnen üblicherweise nur die Dateien, die für die Beantwortung eines Prompts relevant sind, statt ganze Repositories als Git-Bundle zu verpacken und hochzuladen.
Musks Reaktion und der Open-Source-Schachzug
Elon Musk versprach auf X, dass sämtliche zuvor hochgeladenen Nutzerdaten vollständig und restlos gelöscht würden. SpaceXAI-Techniker Andrew Milich und Jason Ginsberg betonten, dass Zero Data Retention von Anfang an respektiert worden sei. Allerdings wies Cereblab darauf hin, dass der /privacy-Befehl nur ein Sitzungs-Toggle sei und nicht der Schalter, der das Problem tatsächlich behoben habe.
Zudem rief Musk Nutzer dazu auf, ihre Daten weiterhin zu teilen, weil dies für die Fehlersuche hilfreich sei. Ein bemerkenswerter Aufruf, angesichts der Tatsache, dass sein Unternehmen gerade beim heimlichen Datensammeln erwischt worden war.
Am 15. Juli veröffentlichte SpaceXAI den Quellcode von Grok Build unter der Apache 2.0-Lizenz auf GitHub. Entwickler können den Agent-Loop, die TUI und die Tool-Schicht nun einsehen, lokal kompilieren und mit eigenen Inferenz-Endpunkten betreiben. Allerdings bestand das öffentliche Repository bei der Veröffentlichung nur aus einem einzigen Commit, wodurch die Entwicklungsgeschichte des Upload-Pfads nicht nachvollziehbar ist.
Was bedeutet das für Entwickler?
Die Open-Source-Freigabe ist ein Schritt in Richtung Transparenz, löst aber nicht die grundlegende Frage: Welche Daten wurden wie lange gespeichert, und wer hatte Zugang dazu? SpaceXAI hat bisher kein Sicherheits-Advisory veröffentlicht, das Auskunft über Art und Umfang der hochgeladenen Daten, die Anzahl betroffener Nutzer oder die Dauer der Speicherung gibt.
Für Entwickler, die Grok Build während der Beta-Phase genutzt haben, lautet die dringende Empfehlung: Alle Credentials rotieren, die möglicherweise in hochgeladenem Code enthalten waren. Dazu gehören SSH-Schlüssel, API-Keys, Passwortmanager-Inhalte und Infrastruktur-Zugangsdaten.
Einordnung
Der Vorfall zeigt ein strukturelles Problem von KI-Coding-Agenten. Anders als klassische IDE-Erweiterungen arbeiten diese Tools mit dem gesamten Code-Kontext, und die Grenze zwischen notwendiger Kontextübertragung und übermäßiger Datensammlung ist oft unscharf. Die Tatsache, dass SpaceXAI das Upload-Verhalten serverseitig per Konfigurations-Flag abschalten konnte, zeigt, dass die Steuerung von vornherein möglich gewesen wäre.
Dass die Abschaltung zudem serverseitig erfolgte, bedeutet im Umkehrschluss: Ein solcher Schalter kann jederzeit auch wieder aktiviert werden. Wer KI-Coding-Tools einsetzt, sollte deshalb nicht nur auf Zero Data Retention achten, sondern auch den ausgehenden Netzwerkverkehr kontrollieren.
Mit der Öffnung von Grok Build unter Apache 2.0 reagiert SpaceXAI auf den Druck. Der Schritt erlaubt Entwicklern, den Code zu prüfen und lokal zu betreiben. Ob das Vertrauen jedoch durch eine Quellcode-Freigabe allein wiederhergestellt werden kann, die nur einen Commit umfasst und keine Transparenz über die vorherige Datensammlung bietet, bleibt fraglich.