Das Grok Build-Codierungstool von SpaceXAI geriet in die Kritik, nachdem Sicherheitsforscher entdeckten, dass sein CLI das gesamte Git-Repos...
Das Grok Build-Codierungstool von SpaceXAI geriet kürzlich in die Kritik, nachdem ein Sicherheitsforscher entdeckte, dass sein Befehlszeilentool (CLI) das gesamte Git-Repository in die Cloud hochlädt und nicht nur die für die Codierungsaufgabe erforderlichen Dateien sendet.
Berichten zufolge umfassen die hochgeladenen Daten getrackte Dateien, den vollständigen Git-Verlauf, Dateien, die der Agent angewiesen wurde nicht zu lesen, sowie vertrauliche Informationen, die zwar aus dem aktuellen Arbeitsverzeichnis entfernt, aber noch in früheren Commits vorhanden sind. Die Daten wurden an einen von xAI kontrollierten Google Cloud Storage-Bucket gesendet.
Nach der Veröffentlichung der Untersuchungsergebnisse wurde das Hochladen eingestellt. Forscher beobachteten, dass die Server von SpaceXAI begannen, Folgendes zurückzugeben:
disable_codebase_upload: true
Elon Musk erklärte zudem, dass zuvor hochgeladene Benutzerdaten vollständig gelöscht werden. Zum Zeitpunkt der Berichterstattung konnte jedoch nicht unabhängig bestätigt werden, ob alle historischen Kopien entfernt wurden.
Der Vorfall begann mit einer kontrollierten Netzwerkanalyse der Grok Build CLI.
Der Forscher unter dem Pseudonym Cereblab führte ein Reverse Engineering der offiziellen Binärdatei durch und überwachte deren Netzwerkverkehr. In einem Test, der die tatsächlichen Datenflüsse des Tools aufdecken sollte, packte Grok Build das Repository in ein Git-Bundle und lud es in einen mit xAI verbundenen Google Cloud Storage-Bucket hoch.
Dies beschränkte sich nicht nur auf die wenigen Dateien, die zur Beantwortung einer Eingabeaufforderung erforderlich waren.
Berichten zufolge enthielt das erfasste Bundle:
Der ursprüngliche AIbase-Bericht beschrieb den Umfang der Datenerfassung als weit größer als bei ähnlichen KI-Codierungstools wie Claude Code.
In einem von Axios berichteten Test lud Grok Build etwa 5,1 GB Daten hoch, während die Codierungsaufgabe selbst nur etwa 192 KB umfasste. Dieses Beispiel verdeutlicht den Unterschied zwischen dem Senden von aufgabenrelevantem Kontext und dem Übertragen des gesamten Repository-Archivs.
Das Hochladen des aktuellen Quellcodebaums ist bereits ein schwerwiegender Sicherheitsvorfall. Das Hochladen des vollständigen Git-Verlaufs kann jedoch noch größeren Schaden anrichten.
Entwickler entfernen häufig vertrauliche Informationen aus der neuesten Version eines Repositorys und gehen davon aus, dass diese verschwunden sind. Tatsächlich kann der Wert jedoch noch in älteren Commits vorhanden sein, sofern der Verlauf nicht umgeschrieben wurde.
Der Git-Verlauf kann enthalten:
Daher kann ein Repository im aktuellen Arbeitsverzeichnis zwar sauber erscheinen, doch sensibles Material bleibt dennoch im .git-Verzeichnis erhalten.
Aus diesem Grund reichen Anweisungen wie „Öffnen Sie diese Datei nicht“ nicht aus, um ausreichend Schutz zu bieten, wenn das Tool das Repository auf Git-Ebene separat verpackt. Datei-Level-Zugriffsanweisungen können steuern, was der Agent während des Modell-Dialogs liest, verhindern jedoch nicht automatisch, dass ein separater Upload-Prozess den Repository-Verlauf verpackt.
Die Analyse von Cereblab identifizierte das Ziel als einen von xAI kontrollierten Google Cloud Storage-Bucket.
Die Nutzung von Google Cloud bedeutet nicht, dass Google eigenständig über das Sammeln von Repositorys entscheidet. Der Cloud-Speicheranbieter hostet die Infrastruktur für Kunden; Berichten zufolge ist der für die Datenkontrolle oder den Betrieb verantwortliche Dienstleister in diesem Fall xAI oder SpaceXAI.
Das Kernproblem besteht darin, dass Repository-Daten den Rechner des Benutzers verlassen und in eine Cloud-Infrastruktur eines Drittanbieters gelangen.
Für Unternehmensteams kann dies Fragen aufwerfen in Bezug auf:
Selbst wenn der Cloud-Anbieter selbst über robuste Sicherheitskontrollen verfügt, können nicht offengelegte oder versehentliche Übertragungen gegen die eigenen Governance-Anforderungen des Unternehmens verstoßen.
Nach der Veröffentlichung der Untersuchung testete Cereblab die CLI erneut.
Der Server gab zurück:
disable_codebase_upload: true
Das Hochladen des gesamten Repositorys wurde nicht mehr ausgelöst.
Dies schien eine serverseitige Änderung zu sein, da Benutzer keine neue Version installieren mussten, bevor das Verhalten eingestellt wurde. Ein Remote-Konfigurations-Flag deaktivierte den Repository-Packaging-Prozess.
Diese Unterscheidung ist wichtig.
Ein serverseitiger Schalter kann das Verhalten schnell stoppen, zeigt aber auch, dass das Datenverarbeitungsverhalten des Clients von einer Remote-Konfiguration abhängen kann. Daher sollten Organisationen, die Codierungsagenten bewerten, den tatsächlichen Netzwerkverkehr überprüfen und sich nicht nur auf lokale Versionsnummern oder statische Einstellungsbildschirme verlassen.
Elon Musk reagierte öffentlich mit der Zusage, dass alle vor der Änderung hochgeladenen Benutzerdaten „vollständig und gründlich gelöscht“ werden, ohne Spuren zu hinterlassen.
SpaceXAI erklärte zudem, dass Datenschutzeinstellungen respektiert würden und dass Kunden, die einer Null-Datenaufbewahrungsregelung unterliegen, keine Tracking- oder Codedaten gespeichert würden.
Dies sind wichtige Zusagen, doch zum Zeitpunkt der Berichterstattung bleiben mehrere Fragen offen:
Die Löschung kann zukünftige Risiken mindern, aber dies löst nicht automatisch alle Sicherheitsprobleme. Wenn das Repository aktive Anmeldeinformationen enthielt, sollten Benutzer davon ausgehen, dass diese Werte die lokale Umgebung verlassen haben könnten, und sie sofort rotieren.
/privacy-Befehl keine echte Lösung istSpaceXAI verwies Benutzer zunächst auf den Grok Build CLI-Befehl:
/privacy
Die offizielle Grok Build-Dokumentation beschreibt /privacy als Befehl zur Anzeige oder Änderung des Datenschutz- und Datenaufbewahrungsstatus.
Sicherheitsforscher stellten fest, dass diese Einstellung das Aufbewahrungsverhalten steuert, nicht jedoch den Mechanismus zum Übertragen des vollständigen Repository-Pakets. Mit anderen Worten: Der Befehl kann nur die Aufbewahrungsvorgänge von SpaceXAI nach dem Empfang der Daten beeinflussen, ist aber kein serverseitiger Mechanismus, der verhindert, dass das Repository den lokalen Rechner verlässt.
Cereblabs Schlussfolgerung ist eindeutig:
/privacy ist eine sitzungsbezogene Aufbewahrungskontrolle.disable_codebase_upload.Dies ist eine der wichtigsten Lehren aus diesem Vorfall.
| Kontrollaspekt | Bedeutung |
|---|---|
| Verlassen Daten das Gerät? | Übertragungs- oder Upload-Kontrolle |
| Werden empfangene Daten gespeichert? | Aufbewahrungskontrolle |
| Wie lange werden sie gespeichert? | Aufbewahrungsfristrichtlinie |
| Werden sie für das Modelltraining verwendet? | Trainingsnutzungsrichtlinie |
| Können Benutzer Daten löschen? | Löschkontrolle |
| Können Benutzer die Löschung überprüfen? | Audit- und Sicherheitskontrolle |
Ein Dienst kann versprechen, keine Daten aufzubewahren, aber dennoch Daten zur Echtzeitverarbeitung übertragen. Dies mag unter klar dokumentierten Unternehmensvereinbarungen akzeptabel sein, ist aber nicht dasselbe wie die Lokalisierung von Daten.
Benutzer sollten „Null Datenaufbewahrung“ nicht mit „Null Datenübertragung“ gleichsetzen, es sei denn, das Produkt macht eine solche Zusage ausdrücklich.
Offizielles Datenschutzdokument von xAI
Das API-Sicherheitsdokument von xAI beschreibt die Zero Data Retention (ZDR) als eine Funktion auf Unternehmensebene.
Wenn das API-Team ZDR aktiviert hat, gibt xAI an, dass Eingabeaufforderungen, Vervollständigungen und zugehörige Metadaten in Echtzeit verarbeitet, aber nicht dauerhaft auf den Servern gespeichert werden. Das Dokument erläutert außerdem, dass API-Antworten den Header x-zero-data-retention enthalten, damit Anwendungen überprüfen können, ob ZDR wirksam ist.
Für Standard-API-Nutzungsszenarien ohne ZDR gibt xAI an, dass Anfragen und Antworten vorübergehend bis zu 30 Tage lang zu Prüfzwecken bei Missbrauch und Fehlgebrauch gespeichert werden können.
Diese API-Richtlinien sind als Referenz nützlich, aber Organisationen sollten nicht automatisch davon ausgehen, dass alle Grok-Produkte, CLI-Traces, Dateiübertragungskanäle oder Verbraucherkonten demselben Datenlebenszyklus folgen.
Bevor Sie Grok Build mit einem privaten Repository verwenden, überprüfen Sie bitte:
Der unabhängige Sicherheitsforscher Dr. Lukasz Olejnik beschreibt das Datenausmaß –
Die Datenaufbewahrungsdauer ist zu lang.
Zu den Informationen, die möglicherweise preisgegeben werden könnten, gehören:
Das Risiko beschränkt sich nicht nur auf böswillige Nutzung.
Große Code-Archive können auch auf folgende Weise preisgegeben werden:
Das Prinzip der Datenminimierung zielt darauf ab, die Angriffsfläche zu verkleinern. Das standardmäßige Hochladen des gesamten Repositorys, wenn nur wenige Dateien benötigt werden, ist mit diesem Prinzip kaum vereinbar.
Teams, die Grok Build verwendet haben, bevor die Upload-Funktion deaktiviert wurde, sollten handeln, als ob es sich um einen potenziellen Quellcode-Leckvorfall handelt.
Überprüfen Sie, wo Grok Build ausgeführt wurde.
Dokumentieren Sie:
Beschränken Sie die Überprüfung nicht nur auf Dateien, bei denen der Agent scheinbar geöffnet wurde.
Verwenden Sie ein von der Organisation genehmigten Schlüssel-Scanning-Tool, um die gesamte Historie zu überprüfen, nicht nur den aktuellen Branch-Inhalt.
Suchen Sie nach:
Selbst wenn ein Geheimnis aus dem letzten Commit entfernt wurde, muss es möglicherweise dennoch rotiert werden.
Wenn während des betroffenen Zeitraums Anmeldeinformationen irgendwo in der verfolgten Repository-Historie existierten, widerrufen oder rotieren Sie diese.
Beschreibe deine Idee einmal, und We0 AI erstellt eine Showcase-Website, Seiten und ein CMS und hilft nach dem Launch bei Kunden und Traffic.
Eine komplette Projektgeneration zur kostenlosen Registrierung
Am besten geeignet, um einen vollständigen Generierungsablauf auszuprobieren und schnell einen ersten Projektentwurf zu sehen.
Warten Sie nicht auf Beweise dafür, dass jemand auf die hochgeladene Kopie zugegriffen hat. Die Rotation von Anmeldeinformationen ist in der Regel kostengünstiger als eine nachträgliche Untersuchung eines Eindringens.
Priorisieren Sie Anmeldeinformationen mit Berechtigungen für:
Überprüfen Sie nach der Nutzung des Repositorys mit Grok Build Cloud-, Quellcodeverwaltungs-, CI/CD-, Datenbank- und interne Dienst-Logs auf ungewöhnliche Aktivitäten.
Suchen Sie nach:
Keine verdächtigen Aktivitäten beweisen nicht, dass Daten nie preisgegeben wurden, helfen aber bei der Bewertung des unmittelbaren Risikos.
Verwenden Sie die aktuelle Version von Grok Build und überprüfen Sie die aktive Konfiguration.
Die offizielle Dokumentation enthält:
grok inspect
Dieser Befehl hilft, zu bestätigen, welche Konfigurationsquellen geladen werden.
Die CLI bietet auch:
/privacy
Nutzen Sie dies, um den Aufbewahrungsstatus zu überprüfen, aber beachten Sie, dass dieser Befehl nicht als Beweis angesehen werden sollte.
Keine Daten verlassen das Gerät.
Unternehmensnutzer sollten eine schriftliche Antwort zu folgenden Punkten anfordern:
Öffentlich gemachte Löschzusagen sind hilfreich, aber regulierte Organisationen benötigen möglicherweise kontospezifische Nachweise.
Wenn das Repository Kunden-Code, personenbezogene Daten, regulierte Informationen oder durch Geheimhaltungsvereinbarungen geschützte Inhalte enthält, beziehen Sie die entsprechenden internen Teams ein.
Je nach Situation können relevante Teams umfassen:
Treffen Sie Entscheidungen über Benachrichtigungen bei Verstößen nicht allein auf der Grundlage von Nachrichtenberichten. Urteilen Sie auf der Grundlage der eigenen Offenlegungstatsachen der Organisation und des geltenden Rechts.
Dieser Vorfall unterstreicht ein breiteres Problem im Bereich der KI-Entwicklungstools.
Code-Agents benötigen oft umfangreiche Zugriffsrechte, da sie große Repositorys durchsuchen, Befehle ausführen, Dokumente lesen und Dateien ändern müssen. Diese Fähigkeit bildet eine enorme Datenschutzgrenze.
Bevor Teams die Verwendung eines Codierungsassistenten genehmigen, sollten sie fünf Aspekte bewerten.
Dokumentieren Sie jede Art von Daten, die das Tool möglicherweise sammeln könnte:
Testen Sie, was tatsächlich die Maschine verlässt.
Anbieterdokumentation ist notwendig, aber das Netzwerkverhalten ist der stärkste Beweis für die tatsächliche Übertragung.
Verwenden Sie ein isoliertes Test-Repository mit harmlosen Canary-Werten und überprüfen Sie dann:
Führen Sie das Tool nicht aus Verzeichnissen aus, die nichts mit dem Projekt zu tun haben.
Bevorzugen Sie:
Bestätigen Sie für Unternehmensbereitstellungen Folgendes:
Das Verhalten von Tools kann sich durch automatische Aktualisierungen oder Remote-Konfigurationsänderungen ändern.
Testen Sie erneut nach:
Wenn sich Produkte schnell ändern, sollten Sicherheitsfreigaben nicht dauerhaft sein.
Agentenanweisungen werden auf der Modell- oder Toolnutzungsebene ausgeführt. Separate Telemetrie- oder Synchronisationskomponenten interpretieren diese Anweisungen möglicherweise nicht.
Datenschutzkontrollen müssen in der Datenpipeline selbst vorhanden sein.
Anbieter können behaupten, nur den notwendigen Kontext zu senden, aber Unternehmensnutzer benötigen Beweise.
Nützliche Zusicherungen umfassen:
Remote-Konfigurationen können Uploads schnell stoppen, bedeuten aber auch, dass Benutzer möglicherweise nicht wissen, wann sich wichtiges Verhalten ändert.
Ein ausgereifter Umgang sollte beinhalten:
Selbst wenn SpaceXAI alle gespeicherten Kopien löscht, sollten alle in den hochgeladenen Repositorys enthaltenen Anmeldeinformationen gemäß ihrem Offenlegungsrisiko behandelt werden.
Das Löschen schützt den zukünftigen Zugriff auf die Kopie des Anbieters, ändert aber nichts an den Anmeldeinformationen selbst.
Eine Protokollebene-Analyse von Cereblab hat ergeben, dass die CLI das gesamte getrackte Git-Repository als Bundle hochlädt – einschließlich des Commit-Verlaufs und von Dateien, die mit der aktuellen Codierungsaufgabe in keinem Zusammenhang stehen. Dieser Verlauf kann Schlüssel enthalten, die bereits aus dem aktuellen Arbeitsverzeichnis entfernt wurden.
Die erfassten Netzwerkdaten zeigen, dass der Upload an einen von xAI kontrollierten Google Cloud Storage-Bucket erfolgt. Google Cloud ist der Infrastrukturanbieter; die entsprechenden Produkt- und Datenverarbeitungsentscheidungen liegen bei SpaceXAI.
Forscher beobachteten später, dass der Server die Antwort disable_codebase_upload: true zurückgab, woraufhin der vollständige Repository-Upload nicht mehr ausgelöst wurde. Diese Änderung scheint serverseitig vorgenommen worden zu sein.
/privacy den Repository-Upload verhindern?Dieser Befehl steuert die Datenschutz- und Aufbewahrungseinstellungen, ist laut Cereblab jedoch kein Mechanismus, um den vollständigen Repository-Upload zu stoppen. Anwender sollten zwischen der Verhinderung einer Übertragung und der Einschränkung der Aufbewahrung nach der Übertragung unterscheiden.
Ja. Musk erklärte öffentlich, dass alle zuvor hochgeladenen Benutzerdaten vollständig gelöscht würden. Zum Zeitpunkt der Berichterstattung gab es noch keine unabhängige Bestätigung der vollständigen Löschung.
Falls bei der Nutzung von Grok Build Schlüssel in einem getrackten Repository oder dessen Git-Verlauf vorhanden waren, ist eine Rotation eine umsichtige Schutzmaßnahme. Das Löschen der Kopie beim Anbieter garantiert nicht, dass die Zugangsdaten nie offengelegt oder abgerufen wurden.
xAI beschreibt ZDR als API-Funktion für Unternehmen, bei der Eingaben und Ausgaben verarbeitet, aber nicht dauerhaft gespeichert werden. Dies bedeutet nicht zwangsläufig, dass Daten das lokale Gerät nie verlassen. Organisationen sollten prüfen, welche Datenkanäle von Grok Build abgedeckt werden.
Die gemeldete Funktion zum vollständigen Hochladen von Repositories wurde deaktiviert. Jede Organisation muss jedoch die aktuelle Version, die Einstellungen, die Kontobedingungen, das Netzwerkverhalten und die Sensibilität der Repositories bewerten. Eine serverseitige Behebung ersetzt keine interne Sicherheitsüberprüfung.
/privacy.Es wurde festgestellt, dass Grok Build sein gesamtes getracktes Git-Repository inklusive der vollständigen Historie in einen von xAI kontrollierten Google Cloud Storage-Bucket hochlädt – selbst wenn die Aufgabe nur wenige Codezeilen erfordert.
SpaceXAI hat die Repository-Upload-Funktion über das serverseitige disable_codebase_upload-Flag deaktiviert. Elon Musk versprach die Löschung der zuvor hochgeladenen Daten. Der /privacy-Befehl betrifft zwar die Aufbewahrungseinstellungen, ist aber kein Mittel zur Verhinderung der Repository-Übertragung.
Entwickler, die die betroffene CLI verwendet haben, sollten die relevanten Repositories identifizieren, den gesamten Git-Verlauf scannen, möglicherweise offengelegte Schlüssel rotieren, Logs überprüfen und bei Bedarf eine kontospezifische Löschbestätigung anfordern.
Die Kernlektion ist einfach: Der Datenschutz von KI-Codierungstools muss auf der Datenübertragungsebene überprüft werden – nicht nur über Eingabeaufforderungen, Aufbewahrungsetiketten oder Einstellungsoberflächen gefolgert werden.
Starte mit einem Satz und erhalte in wenigen Minuten eine vollständige Website.
