Es gibt Skandale, bei denen man kurz die Augenbraue hebt – und es gibt Skandale, bei denen einem der Kaffee im Hals stecken bleibt. Der aktuelle Fall rund um Grok Build, xAIs Kommandozeilen-Tool für agentisches Coding, gehört eindeutig in die zweite Kategorie. Die Sicherheitsforscher bei Cereblab haben sich die Mühe gemacht, den Netzwerkverkehr von Grok Build im Detail zu analysieren – mit einem simplen, sehr unschuldigen Test: Die CLI wurde angewiesen, ausschließlich mit „OK“ zu antworten, außerdem wurde es ihr explizit verboten, irgendwelche Dateien zu öffnen. Tja, und das Ergebnis dieses Tests hat das Zeug, das Vertrauen in sämtliche Coding Tools von LLM-Herstellern nachhaltig und komplett zu zerstören.
Obwohl es Grok Build ausdrücklich untersagt war nicht nur im Prompt, sondern auch (wie später zusätzlich analysiert von anderen Forschern) in den Privacy-Einstellungen, hat es trotzdem das gesamte Repository hochgeladen. Nicht nur die Dateien, die zur Beantwortung des Prompts nötig gewesen wären – nein, das gesamte Repo, verpackt als Git-Bundle, inklusive kompletter Commit-Historie. Also auch Secrets, die vor Monaten aus dem aktuellen Stand entfernt, aber im Git-Verlauf nie wirklich gelöscht wurden. Die Zahlen, die im Umlauf sind, sprechen für sich: In einem Testlauf reichten 192 KiB an Daten aus, um die eigentliche Anfrage zu bearbeiten. Hochgeladen wurden stattdessen (bis zum Abbruch) 5,1 GiB aus einem 11,2-GiB-Repository – auf einen Google-Cloud-Storage-Bucket von xAI, ungefragt, unredigiert. Andere Nutzer berichteten danach von ähnlichen Fällen, bei denen sogar SSH-Keys und komplette Passwort-Manager-Datenbanken aus dem Home-Verzeichnis mit hochgezogen wurden – wenn nämlich ein Unglücksrabe den Agenten in seinem Home-Verzeichnis gestartet hat.
Nachdem der Report viral ging, hat xAI reagiert – aber nicht besonders elegant. Man verwies zunächst auf den /privacy-Befehl, der angeblich die Kontrolle über die Datenspeicherung zurückgeben sollte. Cereblab hat das live nachgeprüft und festgestellt: Der Befehl hat mit dem eigentlichen Problem fast nichts zu tun. Was den Upload tatsächlich gestoppt hat, war ein serverseitig gesetztes, stilles Flag namens disable_codebase_upload: true – etwas, das ganz ohne Zutun des Nutzers greift oder eben nicht greift, je nachdem, was xAI gerade beschließt.
Elon Musk selbst hat sich via X zu Wort gemeldet und versprochen, sämtliche zuvor hochgeladenen Nutzerdaten restlos zu löschen („Zero anything whatsoever will remain“). Im gleichen Atemzug bat er die Nutzer aber, weiterhin Daten zu teilen, weil das ja „beim Debugging helfe“. Naja, wer’s glaubt …
Der eigentliche Casus knacksus, den Cereblab zu Recht anmerkt: Der Standard sollte „aus“ sein. Niemand sollte nach jeder Session manuell einen Opt-out-Befehl ausführen müssen, um zu verhindern, dass der eigene Code auf fremden Servern landet. Und schon gar nicht sollte es stille Schalter geben, die unkontrolliert von außen bedient werden, mit vielleicht desaströsen Konsequenzen.
Hier ist eine Liste von Links mit mehr Informationen zu dem Vorfall –
https://thehackernews.com/2026/07/grok-build-uploads-entire-git.html
https://hivesecurity.gitlab.io/blog/grok-build-repository-upload-2026/
https://www.techtimes.com/articles/320420/20260714/grok-build-shipped-entire-codebases-xai-cloud-privacy-toggle-did-nothing.htm
https://www.reddit.com/r/LocalLLaMA/comments/1ut7tis/grok_build_cli_uploads_your_whole_repo_full_git/
https://news.ycombinator.com/item?id=48877371
https://www.theregister.com/ai-and-ml/2026/07/14/musk-promises-purge-after-grok-build-caught-sending-entire-repos-to-the-cloud/5271123
Es ist aber wichtig zu betonen: Das Problem ist nicht Grok als Sprachmodell. Es geht nicht um Halluzinationen, Bias oder fragwürdige Trainingsdaten. Das Problem ist der Coding-Agent – also die Software-Schicht, die entscheidet, was mit dem Code passiert, bevor er überhaupt beim Modell landet. Und genau diese Schicht liegt bei praktisch jedem kommerziellen Anbieter im Dunkeln. Man weiß nicht, was wirklich hochgeladen wird, man weiß nicht, welche Defaults aktiv sind – man ist bei geschlossenem Code komplett auf das Wort des Herstellers angewiesen.
Das ist kein hypothetisches Risiko – wir haben es hier live gesehen. Und es reiht sich in eine wachsende Liste ähnlicher Vorfälle ein. Nicht überraschend, wenn man bedenkt, dass doch alle LLM-Hersteller zwingend und unbedingt auf ständig neues Trainingsmaterial angewiesen sind, um Wettbewerbsvorteile zu erringen … Tja, und wer eben closed Repositories „einschlürfen“ würde, könnte sein LLM mit Daten trainieren, die niemand anders hat. Zumindest die Versuchung ist also groß.
Die logische Schlussfolgerung aus solchen Vorfällen ist simpel: Wer volle Kontrolle und Transparenz über seinen Code-Workflow will, sollte auf offene, überprüfbare Coding-Agenten setzen. Drei Empfehlungen, die sich in der Praxis bewährt haben:
goose von Block ist mittlerweile eines der ausgereiftesten Projekte in diesem Bereich. Verfügbar als Desktop-App (macOS, Linux, Windows), CLI und API, unterstützt es über 70 Extensions via Model Context Protocol, ist mit über 30 LLM-Anbietern kompatibel und wird nicht mehr von einer einzelnen Firma kontrolliert, sondern von der Agentic AI Foundation unter der Apache-2.0-Lizenz gepflegt – ein entscheidender Vertrauensfaktor.
Pi Coding Agent verfolgt einen ähnlichen Ansatz mit Fokus auf einen schlanken, entwicklerfreundlichen Workflow direkt im Terminal.
opencode hat sich als CLI mit über 172.000 GitHub-Stars (MIT-Lizenz) zum Platzhirsch unter den offenen Coding-Agenten mit Terminal-Fokus entwickelt und unterstützt mittlerweile 75+ Modell-Provider. Es tritt auch selbst als Bundle-Provider auf, man bekommt dort also alles aus einer Hand.
Und gerade zu opencode habe ich noch einen Geheimtipp für Sie. Wenn Sie mit deren CLI nicht gut zurechtkommen, wie zum Beispiel ich, dann gibt es eine relativ neue Ergänzung im opencode-Ökosystem: OpenChamber. Es gibt davon Desktop-Varianten für Windows, MacOS, Linux, sogar eine Browser-Integration – aber vor allem eine ganz hervorragende Extension für VS Code bzw. dessen Open-Source-Variante VSCodium. Und die Extension ist meine Wahl, denn ich persönlich habe es sowieso lieber, wenn ich parallel im Code mitverfolgen kann, was die KI gerade tut, und das geht mit der OpenChamber-Extension und VSCodium ganz leicht.
Das Praktische an OpenChamber ist: Wenn Sie bereits eine konfigurierte opencode-Installation haben, übernimmt OpenChamber alle Daten davon, und Sie müssen nur noch OpenChamber selbst für seine umfangreichen und praxisrelevanten Einstellungen konfigurieren. opencode bietet maximale Freiheitsgrade bei der Einrichtung von KI-Providern, ob es selbst gehostete, Open Source, oder kommerzielle Anbieter sind und ist für das Verwalten unterschiedlicher KI-Provider eine exzellente Grundlage. Aber als Tool für die tägliche Arbeit gefällt mir persönlich OpenChamber weit besser als die entsprechenden Lösungen (CLI + Extension) von opencode.