Der KI-Programmierassistent Grok Build von SpaceXAI überträgt nach einer technischen Analyse ganze Code-Repositories samt Git-Historie an Server des Unternehmens – unabhängig davon, welche Dateien der Agent tatsächlich bearbeitet. Bei einem zwölf Gigabyte großen Testprojekt registrierte der Sicherheitsforscher cereblab einen Datenabfluss von gut fünf Gigabyte. Betroffen sind auch unverschlüsselte Zugangsdaten aus Konfigurationsdateien.
Zwei Übertragungswege senden unterschiedliche Datenmengen
Cereblab analysierte Version 0.2.93 der Kommandozeilenanwendung mit dem Werkzeug mitmproxy und zeichnete den Netzwerkverkehr für Testprojekte zwischen 64 Megabyte und zwölf Gigabyte auf. Dabei identifizierte der Forscher zwei getrennte Übertragungswege. Über die eigentliche Modell-Schnittstelle gingen nur jene Dateien, die der Agent während der Bearbeitung tatsächlich öffnete – bei einer Testsitzung insgesamt 192 Kilobyte.
Parallel dazu lief ein zweiter, deutlich größerer Datenstrom über eine separate Speicher-Schnittstelle. Die Software verschickte dabei das komplette Repository als Git-Bundle, aufgeteilt in Pakete von etwa 75 Megabyte. Beim zwölf Gigabyte großen Testrepository kamen so über 73 Einzelpakete gut fünf Gigabyte zusammen – nach Angaben von cereblab rund 27.800-mal mehr als über den Modellkanal, eine Zahl, die unabhängig nicht verifiziert ist.
Zielort war laut der Analyse ein Google-Cloud-Storage-Bucket mit dem Namen grok-code-session-traces, den der Forscher aus Programmzeichenketten und Anfrage-Metadaten rekonstruierte. Ein präpariertes Testdokument, das der Agent im Versuch nie öffnete, ließ sich nach dem Klonen eines abgefangenen Bundles unverändert wiederherstellen. Das gilt als Beleg dafür, dass die Übertragung unabhängig vom tatsächlichen Nutzungsverhalten erfolgt.
Deaktivierte Lernfunktion verhindert Uploads nicht
Nutzer können in den Grok-Einstellungen die Option “Improve the model” (Modell verbessern) abschalten, die dem Marketing zufolge die Nutzung eigener Daten zum Training einschränkt. Cereblab testete diese Einstellung gezielt und stellte fest, dass die Uploads über die Speicher-Schnittstelle unverändert weiterliefen. Der Server bestätigte in seinen Antworten weiterhin den Status “trace_upload_enabled: true”. Diese Diskrepanz zwischen Einstellung und tatsächlichem Verhalten sei laut cereblab reproduzierbar aufgetreten.
Betroffen sind laut der Analyse auch Konfigurationsdateien mit Zugangsdaten. In einem Testszenario übertrug die Anwendung eine präparierte Testdatei mit Datenbank-Zugangsdaten im Klartext über den Modellkanal, sobald der Agent sie öffnete. Cereblab unterscheidet dabei zwischen zwei Problemen: Kritisch sei nicht, dass der Agent solche Dateien liest, sondern dass ihr Inhalt anschließend ungeschützt weitergegeben werde.
Diese Erkenntnis wirft laut mehreren Kommentatoren aus der Sicherheitscommunity ein grundsätzliches Problem auf: Eine Deaktivierungsoption, die den tatsächlichen Datenfluss nicht beeinflusst, könnte Nutzer in falscher Sicherheit wiegen. Die Angaben stammen aus einer einzelnen technischen Analyse; eine Stellungnahme von SpaceXAI liegt bisher nicht vor.
Community reagiert mit Kritik an Standardeinstellungen
Die Analyse verbreitete sich binnen Stunden auf der Diskussionsplattform Hacker News, wo der Beitrag mehr als 140 Bewertungspunkte und rund 80 Kommentare sammelte. Mehrere Nutzer kritisierten die Standardeinstellung als übergriffig; ein Kommentar verglich das Verhalten mit einer Überwachungskampagne. Andere Kommentatoren wiesen darauf hin, dass Cloud-Programmierwerkzeuge grundsätzlich Code übertragen müssten, um zu funktionieren.
Ein an der Diskussion beteiligter Ingenieur von GitHub verwies zum Vergleich auf striktere Zugriffskontrollen bei Copilot, dem KI-Werkzeug des Konkurrenten Microsoft. Weitere Kommentatoren empfahlen als Gegenmaßnahme, Grok Build in einer isolierten Umgebung etwa mit dem Linux-Werkzeug Bubblewrap auszuführen, statt Zugriff auf ungeschützte Zugangsdaten in Projektverzeichnissen zuzulassen. Solche Empfehlungen ersetzen laut den Kommentatoren aber keine Lösung durch den Hersteller selbst.
Auch Fachmedien wie byteiota griffen die Ergebnisse am 12. Juli auf und bestätigten die zentralen Zahlen aus der ursprünglichen Analyse. Eine Reaktion von SpaceXAI blieb bislang aus; auch zu möglichen Änderungen an der Speicher-Schnittstelle äußerte sich das im Juli umbenannte Unternehmen nicht.
Entscheidend wird, ob SpaceXAI auf die Analyse reagiert und die Speicher-Schnittstelle technisch offenlegt oder verändert. Für Unternehmen, die Coding-Agenten in sensiblen Projekten einsetzen, wirft der Fall grundsätzliche Fragen zur Kontrolle über Quellcode und Zugangsdaten auf. Ob unabhängige Sicherheitsprüfer die Zahlen von cereblab bestätigen, dürfte sich in den kommenden Tagen zeigen.
