ZCode erfasst mehr als den aktuellen Quellcode
Die Desktop-Coding-App ZCode des chinesischen KI-Anbieters Z.ai lädt offenbar vollständige Arbeitsverzeichnisse in die Cloud. Dazu gehören nicht nur aktuell bearbeitete Dateien, sondern auch der gesamten .git-Ordner, Git-LFS-Daten, Reflogs und weitere Projektinformationen.
Das geht aus einer am 18. September 2026 veröffentlichten Reverse-Engineering-Analyse hervor. ZCode wurde im Juli 2026 offiziell gestartet. Der Anbieter ist vor allem für seine GLM-Reihe mit offenen Modellgewichten bekannt, der ZCode-Client selbst ist jedoch proprietär und nicht öffentlich überprüfbar.
Genau diese Trennung ist entscheidend. Open Weight bedeutet lediglich, dass die Gewichte eines KI-Modells verfügbar sind. Daraus folgt nicht, dass auch die Desktop-App, ihre Hintergrundprozesse oder ihre Datenübertragung offenliegen.
313 MB verschlüsseltes Projektarchiv
Untersucht wurde ein kommerzielles Projekt mit 345 MB und 42.411 Dateien. ZCode erzeugte daraus ein verschlüsseltes Archiv mit 313 MB. Während der Analyse wurden 564 fehlgeschlagene Upload-Versuche protokolliert.
| Inhalt des erfassten Datenbestands | Größe | Anteil |
|---|---|---|
.git/lfs/ | 196,1 MB | 56,8 % |
.git/objects/ | 102,2 MB | 29,6 % |
.git/logs/ | 0,6 MB | 0,2 % |
| Quellcode und Dokumente | 46,2 MB | 13,4 % |
| Git-Verzeichnis insgesamt | nicht separat ausgewiesen | 86,6 % |
Eine vollständige Git-Historie ist deutlich sensibler als der aktuelle Stand eines Projekts. Sie kann bereits gelöschte API-Schlüssel, unveröffentlichte Branch-Namen, interne Serverpfade und frühere Versionen vertraulicher Dateien enthalten. Damit umfasst ein solcher Upload potenziell Jahre der Produktentwicklung.
Der Fall ergänzt die bekannten Risiken von Vibe Coding als Schatten-IT. Werden neue Entwicklungswerkzeuge ohne technische Prüfung eingeführt, können Quellcode und Zugangsdaten an Stellen gelangen, die weder Einkauf noch IT-Sicherheit kontrollieren.
Nur Z.ai besitzt den privaten Schlüssel
ZCode verwendet eine sogenannte Envelope-Verschlüsselung. Dabei wird das Archiv mit AES-256-CTR verschlüsselt. Der dafür verwendete symmetrische Schlüssel wird anschließend mit RSA-OAEP und einem öffentlichen Schlüssel geschützt.
Der zugehörige private Schlüssel befindet sich laut Analyse ausschließlich in der Cloud von Z.ai. Lokal vorhandene private Schlüssel konnten das Archiv nicht entschlüsseln. Damit kann der Anwender den verschlüsselten Datenbestand auf dem eigenen System nicht selbst öffnen, während Z.ai technisch über den notwendigen Schlüssel verfügt.
Sinngemäß erklärte der Sicherheitsforscher ferstar: Ein Schlüssel, den ausschließlich der Server verwenden kann, stelle sicher, dass der Server den Code jederzeit lesen kann.
Die Archive werden direkt an Aliyun OSS übertragen, den Objektspeicher der Alibaba Cloud. ZCode fordert zuvor Zugangsdaten, Signaturen und den öffentlichen RSA-Schlüssel vom eigenen Backend an. Anschließend paketiert und verschlüsselt der Client das Projekt lokal und sendet es an den Cloud-Speicher.
Hintergrundprozess umgeht die sichtbaren Einstellungen
Der Upload wird nicht als Werkzeug des KI-Agenten ausgeführt. Verantwortlich ist ein separater Sidecar-Prozess, also ein zusätzlicher Hintergrunddienst auf dem Host-System. Dieser wird beim Start der Anwendung eingerichtet und arbeitet außerhalb der sichtbaren Agenten-Werkzeuge.
In einer aktiven Sitzung wurden 62 Capture-Events registriert. Die Paketierung wurde vor Prompts und nach dem Abschluss von Aufgaben ausgelöst. Die untersuchte Agenten-Schnittstelle enthielt 31 Werkzeuge, aber keines davon war für Uploads, Snapshots oder Telemetrie zuständig.
| Einstellung in ZCode | Tatsächliche Wirkung laut Analyse |
|---|---|
| Optimize Experience | Steuert die Freigabe zur Nutzung für Modelltraining, stoppt aber weder Paketierung noch Upload. |
| Repo Snapshot Indexing | Steuert die serverseitige Indizierung, verhindert aber nicht die Übertragung des Snapshots. |
Die Datenschutzerklärung und die FAQ erwähnen nach den dokumentierten Ergebnissen lediglich Dateien und Codeabschnitte, die während Unterhaltungen übermittelt werden. Ein vollständiger Upload von Repositories samt Git-Historie wird dort nicht beschrieben.
Ob der Mechanismus als technische Grundlage für Checkpoints und Rollbacks gedacht war oder einem anderen Zweck dient, ist bislang nicht bestätigt. Ebenso liegt keine belegte Stellungnahme der Unternehmensführung dazu vor, ob Z.ai das Verhalten ändern oder einen echten Ausschalter bereitstellen will.
Schutzmaßnahme deaktiviert die Rollback-Funktion
Das Löschen eines bereits erzeugten Archivs reicht nicht aus, weil ZCode erneut ein Paket anlegen kann. Als wirksame Gegenmaßnahme wurde dokumentiert, das Verzeichnis ~/.zcode/v2/checkpoints auf Betriebssystemebene unveränderlich zu setzen.
| Betriebssystem | Dokumentierter Mechanismus |
|---|---|
| Linux | chattr +i ~/.zcode/v2/checkpoints |
| macOS | chflags uchg ~/.zcode/v2/checkpoints |
Damit kann ZCode dort keine neuen Checkpoints anlegen. Gleichzeitig fällt jedoch die Checkpoint-Rollback-Funktion aus. Für Unternehmensumgebungen ist eine solche lokale Sperre ohnehin nur eine Übergangslösung. Sinnvoller sind zentrale Netzwerkregeln, Anwendungskontrollen, isolierte Testumgebungen und ein generelles Verbot unbekannter Coding-Clients für sensible Repositories.
Wie weitreichend die Folgen unzureichend kontrollierter Entwicklungsagenten sein können, zeigen auch die Sicherheitslücke Plugin4Shell in führenden KI-Coding-Agenten und dokumentierte Fälle, in denen KI-Agenten Firmennetze in weniger als zehn Stunden kompromittierten.
Offene Modelle allein schaffen keine Datensouveränität
Für Unternehmen im DACH-Raum entstehen erhebliche Datenschutz-, Geheimnisschutz- und Compliance-Risiken. Repositories können personenbezogene Entwicklerdaten, Zugangsdaten, Geschäftsgeheimnisse und Details zur internen Infrastruktur enthalten. Bei einer Übertragung an einen externen Cloud-Dienst müssen zudem Zielregion, Rechtsgrundlage, Verträge und technische Schutzmaßnahmen geprüft werden.
Der Vorfall zeigt eine zentrale Schwäche proprietärer Oberflächen für offene Modelle. Selbst wenn ein Modell lokal betrieben werden kann, bleibt die darüberliegende Anwendung ein eigener Vertrauensbereich. Ein Closed-Source-Client kann Daten erfassen, ohne dass sich das Verhalten anhand des Quellcodes kontrollieren lässt.
Echte Datensouveränität setzt deshalb mehr voraus als offene Modellgewichte. Erforderlich sind eine überprüfbare Toolchain, transparente Netzwerkzugriffe und möglichst quelloffene Entwicklungswerkzeuge. Wie groß der wirtschaftliche Spielraum dabei sein kann, zeigt der Vergleich, nach dem Open-Weights-Modelle bis zu 80 % günstiger sein können. Der Kostenvorteil nützt allerdings wenig, wenn ein proprietärer Client die Kontrolle über den eigenen Quellcode wieder aufhebt.