xAI hat Grok Build unter die Apache-2.0-Lizenz gestellt und damit den kompletten Quellcode seines Terminal-Coding-Agenten offengelegt. Der Schritt folgt unmittelbar auf einen Skandal um heimlich hochgeladene Repositories. Ob offener Code das verlorene Vertrauen zurückholt, ist die eigentliche Frage.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Grok Build ist seit dem 15. Juli 2026 quelloffen, rund 845.000 Zeilen Rust liegen seither öffentlich auf GitHub. Der Zeitpunkt wirkt nicht zufällig gewählt, denn wenige Tage zuvor hatten Sicherheitsforscher belegt, dass genau dieses Werkzeug ganze Code-Repositories an xAI-Server geschickt hat.
Das Wichtigste in Kürze
- Release: xAI hat Grok Build am 15. Juli 2026 unter Apache 2.0 veröffentlicht und zugleich die Nutzungslimits zurückgesetzt.
- Kein Mitmach-Projekt: Externe Beiträge nimmt das Repository ausdrücklich nicht an. Offen heißt hier vor allem einsehbar.
- Upload bleibt im Code: Eine Analyse der Version 0.2.99 fand die Hochlade-Funktion weiter im Programm, nur per Server-Schalter abgestellt.
- DSGVO-Frage: Für haftende Teams zählt vor allem, wer diesen Schalter kontrolliert.
Was hat xAI genau offengelegt?
Kompletter Quellcode: xAI hat den gesamten Code von Grok Build auf GitHub gestellt, lizenziert unter Apache 2.0.[1] Das Werkzeug ist ein Terminal-Agent auf Basis des Modells Grok 4.5, der Dateien bearbeitet, Shell-Befehle ausführt und im Plan-Modus ganze Umbauten vorbereitet.
Erstaunlicher Umfang: Geschrieben ist Grok Build fast vollständig in Rust. Mit rund 845.000 Zeilen ist das eine für einen Coding-Agenten ungewöhnlich große Basis, über deren Ausmaß sich Fachleute schon beim Release gewundert haben.
Offen mit Sternchen: Ein Detail relativiert das Wort sofort. Externe Beiträge nimmt das Projekt laut eigener Beschreibung nicht an. Den Code einsehen und forken lässt sich zwar frei, doch die maßgebliche Fassung bleibt fest in xAIs Hand.
Warum ist offener Code hier kein Vertrauensbeweis?
Prüfbar statt sicher: Der Wert der Offenlegung liegt nicht in der Mitarbeit, sondern in der Prüfbarkeit. Und genau die fällt unbequem aus.
Kurz vor der Veröffentlichung hat der Sicherheitsforscher cereblab die Version 0.2.93 mitgeschnitten. Das Werkzeug hat dabei ganze Git-Repositories samt Historie auf einen Cloud-Speicher von xAI geladen, rund 27.800-mal mehr Daten, als das Modell überhaupt gelesen hatte.[2] Sogar eine getrackte .env-Datei ist ungeschwärzt mitgegangen, samt Schlüsseln und Passwörtern. Dr. Web hat den Datenabfluss bereits im Detail nachgezeichnet, ebenso die Frage, was der CLI-Client wirklich sendet.
xAI hat den Upload nach der Offenlegung serverseitig abgestellt, Elon Musk hat angekündigt, alle Daten würden vollständig gelöscht. Der jetzt offene Code zeigt jedoch, dass die Hochlade-Funktion in Build 0.2.99 weiter enthalten ist, lediglich durch ein Server-Flag ausgeschaltet.[3]
Der Schalter zählt: Genau hier steckt der Mechanismus, den die Schlagzeile verdeckt. Nicht der Nutzer entscheidet über den Upload, sondern ein Flag auf xAIs Servern. Der offengelegte Code macht damit deutlich: Die Funktion lässt sich jederzeit ohne Update wieder scharf schalten.
Offener Code ist ein Fortschritt, aber er ersetzt keine Kontrolle. Solange ein Anbieter den Upload aus der Ferne wieder anschalten kann, bleibt die Datenhoheit ungelöst.
— Markus Seyfferth, Chefredakteur Dr. Web
Der Haken: Externe Beiträge nimmt das Projekt nicht an, und die Upload-Funktion steckt weiter in Build 0.2.99, nur per Server-Flag deaktiviert. Den Schalter kontrolliert xAI, nicht der Nutzer.
Was sollten deutsche Entwickler jetzt tun?
DSGVO-Haftung: Für ein Unternehmen in Deutschland ist ein Coding-Agent, der Quellcode in eine fremde Cloud spiegeln kann, kein Komfort-Thema, sondern ein Fall von Auftragsverarbeitung nach Artikel 28 DSGVO. Liegen Kundendaten oder Zugangsschlüssel im Repository, haftet der Verantwortliche, nicht das Werkzeug.
Vier Schritte senken das Risiko spürbar:
- Die jetzt offengelegten Server-Flags und Speicher-Endpunkte im Code prüfen oder prüfen lassen.
- Ausgehende Verbindungen zu xAIs Speicher-Endpunkten per Firewall blockieren, statt auf den Schalter zu vertrauen.
- Zugangsdaten aus dem Arbeitsverzeichnis heraushalten und alle Schlüssel rotieren, die frühere Versionen gesehen haben könnten.
- Für sensible Projekte einen Agenten mit eigener Wegwerf-Umgebung erwägen, der gar nicht erst auf das Produktivsystem zugreift.
Prüfen vor Vertrauen: Grok Build offenzulegen ist der richtige Schritt, doch er verlagert die Verantwortung zum Anwender. Prüfen Sie den Code oder sperren Sie die Upload-Wege, bevor das Werkzeug an echten Projekten arbeitet. Ein strukturierter Umgang mit KI-Werkzeugen, wie ihn unser LLMs-Ratgeber beschreibt, hält die Datenhoheit auch bei offenem Code in Ihrer Hand.
Quellen
[1] xAI: „grok-build“ auf GitHub (Apache-2.0-Repository) ↩
[2] cereblab: „What xAI Grok Build CLI actually sends to xAI, a wire-level analysis (grok 0.2.93)“ ↩
[3] cereblab: „grok-build-exfil-repro“ (Reproduktion, Analyse Build 0.2.99) ↩
Mehr Newshunger?
- Was xAIs Grok Build CLI wirklich an xAI sendet
- 27.800-mal mehr Daten als nötig: Grok Build lud ganze Git-Repositories zu xAI hoch
- Grok 4.5 ist da: xAIs neues Modell setzt auf Tempo und Preis statt Benchmark-Krone
- Clawk gibt dem KI-Coding-Agenten eine eigene Wegwerf-VM statt Ihres Rechners
- GPT-5.6 Sol Ultra in Codex: OpenAIs Coding-Modell steuert jetzt eigene Subagenten
- Cursor Automations: Coding-Agenten warten nicht mehr
