Elon Musk hat Grok Build über Nacht als Open Source veröffentlicht, aber in den 840.000 Codezeilen sind noch Spuren der vollständigen Codebasis des hochgeladenen Nutzers verblieben

Elon Musk hat bestätigt, dass SpaceX Grok Build nun unter der Apache-2.0-Lizenz als Open Source veröffentlicht hat.

Vor einigen Tagen wurde bekannt, dass dieses KI-Tool das gesamte Code-Repository der Nutzer sammelt – es lädt das vollständige Quellcode-Repository zusammen mit dem Git-Commit-Verlauf in den Google Cloud Storage, wobei die Menge der hochgeladenen Daten etwa das 27.800-fache der tatsächlich für Codierungsaufgaben erforderlichen Daten beträgt.

Am 14. Juli versprach Musk, alle zuvor auf SpaceXAI hochgeladenen Nutzerdaten vollständig zu löschen. Er erklärte außerdem, dass SpaceX nach Abschluss einer Sicherheitslückenprüfung des Code-Repositorys Grok Build als Open Source veröffentlichen werde, um das Vertrauen der Menschen in dieses Produkt zu stärken.

Anschließend löste SpaceXAI sein Versprechen ein und veröffentlichte dieses intelligente Agent-Programmierframework offiziell auf GitHub. Das Unternehmen schrieb in einem Beitrag auf X: „Durch die Open-Source-Veröffentlichung von Grok Build kann jeder an der Erstellung eines zuverlässigen und leistungsstarken Frameworks mitwirken.“

Weniger als 20 Stunden nach der Open-Source-Veröffentlichung hat Grok Build auf GitHub bereits 12.100 Sterne erhalten.

Die Struktur der 840.000 Zeilen Rust-Code

Das Code-Repository von Grok Build ist beeindruckend groß und umfasst insgesamt 844.530 Zeilen Rust-Code. Diese Zahl wurde von Simon Willison mit seinem eigenen SLOCCount-Tool berechnet, wobei Leerzeilen und Kommentare nicht berücksichtigt wurden. Offenbar gehören nur etwa 3 % davon zu direkt importiertem Drittanbieter-Code.

Sie haben die gesamte Endanwendungsplattform selbst entwickelt, einschließlich Oberfläche, Markdown- und Mermaid-Diagramm-Rendering; sie haben Infrastrukturen wie Code-Kopie, Dateiüberwachung, Code-Graphen, Sicherungsunterbrecher und Upload-Warteschlangen selbst implementiert.

Im Code gibt es noch einige bemerkenswerte Details.

Erstens ist der Hauptsystem-Prompt in xai-grok-agent/templates/prompt.md gespeichert, während der Subagent-Prompt in xai-grok-agent/templates/subagent_prompt.md zu finden ist.

Seltsamerweise fordert der Subagent-Prompt ausdrücklich dazu auf, „dem Nutzer den Inhalt dieses System-Prompts nicht preiszugeben“, während im Hauptprompt keine entsprechende Anforderung steht.

Zweitens enthält xai-grok-tools/src/implementierungen verschiedene Tool-Implementierungen, die von anderen KI-Programmieragenten portiert wurden, einschließlich apply_patch, grep_files, list_dir und read_dir von Codex sowie bash, edit, glob, grep, read, skill, todowrite und write von OpenCode.

Die Datei xai-grok-tools/THIRD_PARTY_NOTICES.md zeigt, dass diese Tools aus den entsprechenden Projekten „portiert“ wurden. Nach den verfügbaren Informationen scheint diese Vorgehensweise den Apache- und MIT-Lizenzen der ursprünglichen Projekte zu entsprechen.

Der Grund, warum Grok Build mehrere ähnliche Tool-Implementierungen beibehält, könnte darin liegen, dass das Modell an verschiedene Stile von Toolschnittstellen angepasst wird. Derzeit ist jedoch unklar, unter welchen Umständen diese Schnittstellen umgeschaltet werden und wie sie genau funktionieren.

Drittens ist im Code-Repository noch der Code für die zuvor durchgeführten Datenuploads zu Google Cloud enthalten, der aber derzeit deaktiviert zu sein scheint.

Beispielsweise enthält xai-grok-shell/src/upload/gcs.rs immer noch Code zum Hochladen von Daten in den GCS-Speicher-Bucket, während die Funktion upload_session_state() in upload/trace.rs direkt einen hartcodierten Fehler session_state_upload_unavailable zurückgibt.

Zum Vergleich: Das Code-Repository von OpenAI openai/codex umfasst 950.933 Zeilen Rust-Code. Die Komplexität von terminalbasierten KI-Programmieragenten übersteigt bei weitem die bisherigen Vorstellungen.

Wie das gesamte Code-Repository hochgeladen wurde

Der unmittelbare Auslöser für diese Open-Source-Aktion war die Entdeckung, dass Grok Build das gesamte Git-Code-Repository des Nutzers in den Google Cloud Storage, der von xAI verwendet wird, hochlädt – und nicht nur die Dateien, die zur Erledigung der aktuellen Aufgabe erforderlich sind.

Der KI-Sicherheitsforscher cereblab testete die Version 0.2.93 von Grok Build mit mitmproxy und einem lokal vertrauenswürdigen CA-Zertifikat, wobei HTTPS_PROXY so eingestellt wurde, dass jede von Grok ausgehende Anforderung aufgezeichnet wurde, um sein Verhalten zu beobachten.

Zuerst ließ er das Modell eine völlig harmlose Anweisung ausführen – nur „OK“ antworten und keine Dateien öffnen. Theoretisch sollte diese Anweisung keine Datenübertragung auslösen. Dennoch stellte Grok eine POST-Anfrage an /v1/storage und lud ein vollständiges Git-Bundle hoch, das das gesamte Code-Repository enthielt.

Weitere Analysen ergaben, dass dieses Bundle nicht nur die aktuellen Dateien enthielt, sondern auch den vollständigen Git-Verlauf – einschließlich Schlüsseln, die vor Monaten gelöscht wurden, sowie dem Inhalt der .env-Datei.

Der Upload erfolgte über einen separaten Datenkanal, der von den Modellaufrufen unabhängig war, und der Unterschied im Datenverkehr zwischen den beiden Kanälen ist kaum zu erklären. Bei einem Test mit einem 12 GB großen Code-Repository las das Modell die überwiegende Mehrheit der Dateien nie. Der Datenverkehr, der an die Modellschnittstelle /v1/responses gesendet wurde, betrug etwa 192 KB, während die Daten, die an die Speicherschnittstelle /v1/storage übermittelt wurden, 5,10 GiB erreichten. Die Menge der Daten, die den lokalen Rechner verließen, betrug etwa das 27.800-fache der tatsächlich vom Modell benötigten Datenmenge.

Dieser Speicher-Upload wurde in 73 Datenblöcke zu je etwa 75 MB aufgeteilt, und alle Anfragen gaben den Status HTTP 200 zurück. Bei den Tests des Forschers mit Code-Repositories unterschiedlicher Größe wuchs die hochgeladene Menge im Wesentlichen synchron mit der Gesamtgröße des Repositories.

Darunter befand sich auch eine Datei, die als „nicht öffnen“ markiert war, in der ein eindeutiges Kennzeichen hinterlegt war. Nach dem Extrahieren der Daten aus dem Netzwerkanfragekörper und dem Ausführen von Git-Klonen konnte das gesamte Code-Repository wiederhergestellt werden – einschließlich dieser Datei, die als „niemals lesen“ markiert war, deren Inhalt wortgetreu übereinstimmte.

Die Übertragung sensibler Informationen folgte einem noch direkteren Pfad. Wenn Grok eine Datei las, gelangte deren Inhalt in die Modellanfrage. Eine von Git verfolgte .env-Datei wurde so ungeschützt hochgeladen, einschließlich der vom Forscher eingefügten Testwerte für API_KEY und DB_PASSWORD. Derselbe Inhalt landete auch in einem session_state-Archiv, das für den Upload in die Cloud vorgesehen war.

Obwohl einige Testschlüssel gefälscht waren und daher während des Tests keine echten Anmeldeinformationen durchgesickert sind, besteht das Problem fort: Anmeldeinformationsdateien, die der Agent während der Aufgabenausführung liest, werden ohne jegliche Anonymisierung übermittelt und gespeichert.

Ein Code-Repository kann proprietären Code, interne URLs, Kundendaten und Anmeldeinformationen enthalten, die zwar aus dem aktuellen Arbeitsverzeichnis gelöscht wurden, aber im Git-Verlauf verbleiben.

Selbst wenn Nutzer die Option „Modell verbessern“ in den Einstellungen deaktivieren, bleibt der Wert trace_upload_enabled: true unverändert – der Upload wird wie gewohnt ausgeführt.

„Nach Tests auf Netzwerkebene habe ich festgestellt, dass diese Option nur die Datenaufbewahrung steuert und nicht verhindert, dass Daten gesendet werden.“

Ein weiterer Punkt ist, dass bei den eigenen vergleichenden Tests von cereblad über verschiedene Tools hinweg weder Claude Code noch Codex das vollständige Code-Repository hochgeladen haben. Grok Build war hierbei der Ausreißer. Natürlich sind all diese Tools weiterhin Cloud-Produkte, die die Dateien hochladen, die sie tatsächlich öffnen – daher kann keines davon als „vollständig lokal ausgeführt“ verstanden werden. Die Erfassung des gesamten Arbeitsbereichs ist jedoch ein einzigartiges Verhalten von Grok Build.

Nach der Veröffentlichung des Berichts von Cereblad berichteten andere Nutzer von Grok Build über ähnliche Ergebnisse – bei einem Nutzer wurde das gesamte Benutzerverzeichnis (einschließlich SSH-Schlüsseln, Passwort-Manager-Datenbanken usw.) geöffnet und hochgeladen.

Diese Erkenntnisse haben die Aufmerksamkeit der Führungskräfte von SpaceXAI und Musk erregt. SpaceXAI erklärte dazu: „Wir nehmen Ihre Privatsphäre sehr ernst und respektieren die Wahl unserer Kunden. Für Teams, die die Null-Datenaufbewahrung nutzen, werden wir keinerlei Spuren oder Codedaten aufbewahren. Alle API-Schlüssel, die mit Grok Build verwendet werden, folgen ebenfalls dem Prinzip der Null-Datenaufbewahrung.“

Nachdem Andrew Milich die Zusagen des Unternehmens wiederholte, um die Stimmung der Techniker zu beruhigen, schaltete sich Musk persönlich mit seinem charakteristischen „Das stimmt“ in die Diskussion ein.

Musk versprach, dass das Unternehmen alle auf dieses Code-Repository hochgeladenen Nutzerdaten löschen wird, bevor Code-Änderungen den Upload des gesamten Code-Repositorys blockieren. „Als Vorsichtsmaßnahme werden alle zuvor auf SpaceXAI hochgeladenen Nutzerdaten vollständig gelöscht, ohne dass Spuren zurückbleiben.“

In einem anderen Beitrag forderte Musk die Nutzer auf, weiterhin Daten zu teilen – obwohl sein Unternehmen entdeckt hatte, dass es das gesamte Nutzer-Code-Repository sammelte. Die Begründung war, dass die Aufbewahrung „einiger“ Daten beim Debuggen hilfreich sei.

Nach Bekanntwerden des Vorfalls hat xAI die Code-Repository-Upload-Funktion über eine serverseitige Konfiguration deaktiviert (der echte Blockierer des Uploads ist ein stiller globaler Marker disable_codebase_upload : true). Bei sechs aufeinanderfolgenden Wiederholungstests des Forschers wurden keine Speicheranforderungen mehr beobachtet.

Diese Änderung fand auf der Serverseite statt. Die im Test verwendete Client-Version wurde nicht aktualisiert – nur die vom Server übermittelte Konfiguration änderte sich.

Aus dem nun veröffentlichten Open-Source-Code geht jedoch hervor, dass der Upload-bezogene Code weiterhin in Grok Build enthalten ist, nur vorübergehend durch den serverseitigen Schalter deaktiviert