ZCode-Git-Snapshot-Vorfall: Was KI-Coding-Agenten sehen, hochladen und sich merken können

Der Vorfall mit dem ZCode-Repository-Upload ist größer als nur ein einzelnes Coding-Tool. Er wirft eine Sicherheitsfrage auf, die Entwickler zunehmend beantworten müssen, bevor sie einem KI-Agenten Zugriff auf ein Projekt gewähren: Bedeutet „Repository-Zugriff“ die aktuelle Datei, den Arbeitsbaum oder Jahre der Git-Historie?

Diese Unterscheidung ist wichtig, weil .git Informationen enthalten kann, die in der aktuellen Codebasis nicht mehr sichtbar sind, darunter gelöschte Geheimnisse, alte Quellversionen, Reflogs, LFS-Assets und der lokale Verlauf von Branches. ZCode erklärt, das betroffene Upload-Verhalten sei behoben worden, doch der Vorfall hinterlässt eine bleibende Lehre: KI-Coding-Agenten benötigen klare Datenbegrenzungen, nicht nur die Berechtigung, auf das „Repository zuzugreifen“.

Was geschah tatsächlich mit ZCode?

Am 18. September 2026 veröffentlichte der Entwickler ferstar eine Reverse-Engineering-Untersuchung zu ZCode 3.12.3, nachdem ihm ungewöhnlich große Dateien im lokalen Datenverzeichnis der Anwendung aufgefallen waren.

Laut der ursprünglichen Untersuchung erstellte der Client verschlüsselte Workspace-Snapshots, die sowohl Quelldateien als auch .git, Git-LFS-Objekte, Reflogs und Repository-Metadaten enthalten konnten. Der Client enthielt außerdem eine Pipeline zum Abrufen von Upload-Anmeldedaten und zum Senden verschlüsselter Archive an Alibaba Cloud OSS.

ZCode bestätigte anschließend Uploads von Repository-Daten im Zusammenhang mit der Codebase-Indizierung und Repo Wiki, entschuldigte sich, erklärte, das Verhalten sei behoben worden, und kündigte Pläne für eine Prüfung durch die Open-Source-Community und Dritte an. Zeitgenössische Berichte gaben die wichtigsten Punkte der Reaktion von ZCode wieder.

Dies ist die erste wichtige Informationslücke, die geschlossen werden muss: Der Vorfall war real, aber einige virale Zusammenfassungen übertrieben, was tatsächlich übertragen wurde.

Wurde das 313-MB-Private-Repository tatsächlich hochgeladen?

Nein.

Der Snapshot des kommerziellen Projekts enthielt ungefähr 42.000 Dateien und erzeugte ein verschlüsseltes Archiv von etwa 313 MB. Laut dem Update des Forschers vom 19. September befand es sich weiterhin lokal Ausstehend Status nach 564 fehlgeschlagenen Versuchen, weil das Upload-Limit überschritten wurde. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Ein separates, kleineres öffentliches Repository erreichte den Dienst tatsächlich erfolgreich. Es enthielt 538 Dateien und erzeugte eine deutlich kleinere verschlüsselte Nutzlast.

Die korrekte Schlussfolgerung lautet daher nicht: „Jedes ZCode-Repository wurde hochgeladen.“ Vielmehr enthielt der alte Client einen funktionsfähigen Mechanismus zum Hochladen von Repositories, dessen tatsächlicher Erfolg vom Snapshot abhing.

Warum das Verzeichnis `.git` der wichtigste Teil dieses Vorfalls ist

Im großen Snapshot des Forschers bestand der Großteil der Nutzdaten nicht aus aktuellem Quellcode.

Das bedeutet, dass ungefähr 86,6 % des Snapshots aus .git stammten. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Dadurch ändert sich die Sicherheitsbewertung grundlegend.

Ein KI-Agent, der den aktuellen Quellbaum liest, sieht möglicherweise, was der Entwickler heute bewusst beibehält. Der Zugriff auf die Git-Historie kann offenlegen, was der Entwickler bereits entfernt zu haben glaubte.

Mögliche historische Offenlegungen umfassen:

• gelöschte Quelldateien
• alte API-Schlüssel oder Token
• frühere interne Endpunkte
• aufgegebene Funktionen
• historische Konfiguration
• Aktivität lokaler Branches
• nur im Reflog vorhandene Zustände
• große historische LFS-Assets

Die Git-Reflog-Dokumentation erklärt, dass Reflogs frühere Werte lokaler Referenzen aufzeichnen. Diese Aufzeichnungen können lokal vorhanden sein, selbst wenn die entsprechende Historie nie in ein Remote-Repository übertragen wurde.

Daraus ergibt sich eine nützliche Sicherheitsregel:

„Mein Projekt lesen“ und „meine Git-Historie lesen“ sollten separate Berechtigungen sein.

Warum gelöschte Geheimnisse weiterhin existieren können, nachdem Sie sie aus dem Code entfernt haben

Das Löschen von Zugangsdaten aus der neuesten Datei entfernt sie nicht zwangsläufig aus Git.

Ein Entwickler kann versehentlich einen API-Schlüssel committen, ihn im nächsten Commit entfernen und eine vollständig bereinigte aktuelle Datei sehen. Das frühere Blob kann über die Repository-Historie weiterhin erreichbar sein.

Die Anleitung von GitHub zum Entfernen vertraulicher Daten empfiehlt ausdrücklich, offengelegte Zugangsdaten zu widerrufen oder zu rotieren, bevor die Historie umgeschrieben wird.

Diese Reihenfolge ist wichtig:

1. Machen Sie die Zugangsdaten ungültig.
2. Entfernen Sie die vertrauliche Historie, sofern angemessen.
3. Verhindern Sie, dass das Geheimnis erneut committed wird.

Für KI-Coding-Agenten bedeutet dies, dass eine verlaufsbewusste Funktion auf Daten zugreifen kann, die eine normale Editoransicht nicht mehr offenlegt.

Das erklärt auch, warum ein Agent mit schreibgeschütztem Zugriff nicht automatisch ein geringes Risiko darstellt. Auch ein schreibgeschützter Zugriff kann wertvolle Informationen offenlegen, wenn sein Dateisystembereich zu weit gefasst ist oder abgerufene Inhalte an ein Remote-Modell gesendet werden.

Modellkontext, Telemetrie, Training und Repository-Uploads sind nicht dasselbe

Eine weitere wichtige Erkenntnis ist, dass ein einzelner „Datenschutz“-Schalter nicht jede Art von Datenfluss darstellen kann, die ein KI-Coding-Tool möglicherweise aufweist.

Die betroffene ZCode-Version ist wichtig, weil der Forscher berichtete, dass das Deaktivieren der Option zur Optimierung/zum Training die separate Snapshot-Pipeline nicht deaktivierte. Dem Bericht zufolge verhinderte der Schalter für die Indexierung von Repository-Snapshots in dieser Version ebenfalls keine Versuche, Pakete zu erstellen und hochzuladen. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Daraus ergibt sich eine Regel, die weit über ZCode hinaus gilt:

„Meine Daten nicht zum Trainieren verwenden“ bedeutet nicht „Meine Daten nicht übertragen“.

Ein Cloud-Modell benötigt weiterhin Kontext für die Inferenz. Telemetriedaten können über einen anderen Endpunkt übertragen werden. Durch die Synchronisierung kann eine weitere Kopie gespeichert werden. Die Indexierung des Repositorys kann einen eigenen Datenpfad haben.

Dieselbe Unterscheidung zeigt sich auch, wenn ein lokaler KI-Agent Cloud-Tools verwendet: Der Datenschutz hängt genau davon ab, welche Daten die Grenze überschreiten, und nicht einfach davon, wo der Hauptprozess des Agenten ausgeführt wird.

Verschlüsselung beantwortet nicht die wichtigste Datenschutzfrage

Der betroffene ZCode-Snapshot wurde vor dem Upload verschlüsselt.

Der Bericht zur technischen Analyse beschreibt eine AES-256-CTR-Verschlüsselung für das Archiv sowie eine RSA-OAEP-SHA256-Wrapping-Verschlüsselung für den symmetrischen Schlüssel. Der öffentliche RSA-Schlüssel wurde vom Dienst bereitgestellt, während der zugehörige private Schlüssel nicht lokal gespeichert wurde. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Das schützt Daten anders als eine vom Benutzer kontrollierte Ende-zu-Ende-Verschlüsselung.

Daher ist die Aussage „Das Repository wurde verschlüsselt“ unvollständig.

Die wichtigere Frage lautet:

Wer kann es entschlüsseln?

Dasselbe Prinzip gilt für privates RAG, Cloud-Backups, KI-Speicher und jedes System, das behauptet, Daten seien geschützt, weil sie verschlüsselt sind.

Wie viel Repository-Zugriff benötigt ein Coding-Agent tatsächlich?

Coding-Agenten benötigen berechtigterweise mehr Kontext als herkömmliche Autovervollständigung. Ein repositoryweiter Refactor kann viele Dateien erfordern. Ein Debugging-Agent benötigt möglicherweise Tests, Abhängigkeitsmetadaten, den Git-Status und die Build-Ausgabe.

Aber „der Agent benötigt möglicherweise einen breiten Kontext“ bedeutet nicht, dass „jede Funktion jedes Byte im Repository erhalten sollte“.

Dies ist eine datenbezogene Variante desselben Prinzips, das in einer Vertrauensgrenze bei der Tool-Ausführung verwendet wird: Die Fähigkeit des Modells, etwas anzufordern, sollte nicht automatisch die Berechtigung erteilen, auf alles in der Nähe zuzugreifen oder es zu exportieren.

Bei Coding-Agenten benötigen wir zwei unabhängige Grenzen:

• Aktionsgrenze: Was darf der Agent ändern oder ausführen?
• Datengrenze: Was darf der Agent lesen oder senden?

Ein Agent ohne Schreibberechtigung kann weiterhin ein erhebliches Datenschutzrisiko darstellen, wenn seine Lese- und Netzwerkberechtigungen uneingeschränkt sind.

Was hat ZCode nach dem Vorfall geändert?

Der Vorfall sollte nicht so beschrieben werden, als sei bekannt, dass dasselbe Verhalten in aktuellen ZCode-Versionen weiterhin existiert.

Bei einer anschließenden Untersuchung von ZCode 3.14.0 berichtete der Forscher, dass der frühere Upload-Begleitprozess entfernt worden war und der alte Anmeldedaten-Endpunkt 404 zurückgab. Der untersuchte Pfad behielt die Funktionalität lokaler Checkpoints bei, ohne den früheren Mechanismus zum Hochladen auf einen entfernten Server. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Die aktuelle Repo-Wiki-Dokumentation beschreibt ebenfalls eine deutlich engere Datengrenze.

Dort heißt es, dass der Wiki-Kontext Folgendes ausschließt:

• .git
• Abhängigkeitsverzeichnisse
• Build-Ausgabe
• Caches
• lokaler Laufzeitstatus
• unterstützt .gitignore Ausschlüsse
• mutmaßlich vertrauliche Konfigurationsdateien
• Ziele symbolischer Links

Die Ausgabe des Repo-Wikis wird als lokale Anwendungsdaten dokumentiert und nicht als in das Repository zurückgeschriebener Inhalt.

Dies unterscheidet sich wesentlich vom in Version 3.12.3 gemeldeten Snapshot-Verhalten.

Reicht Open Source aus, um einen Coding-Agenten privat zu machen?

Nein.

Open Source kann einen Client leichter überprüfbar machen, aber eine Open-Source-Anwendung kann Quellcode dennoch an Cloud-Modelle senden, Telemetriedaten hochladen, den Status synchronisieren oder auf vom Anbieter kontrollierten Speicher zurückgreifen.

Die nützlichere Checkliste lautet:

Deshalb wird eine private KI-Architektur eher durch ihren Datenfluss definiert als dadurch, ob ihre Softwarelizenz zufällig Open Source ist.

Wie sollten Entwickler einen neuen KI-Coding-Agenten prüfen?

Entwickler müssen nicht jede App durch Reverse Engineering analysieren, aber ein neuer Agent sollte nicht als erste Testumgebung Zugriff auf ein sensibles kommerzielles Repository erhalten.

1. Lesen Sie die Dokumentation zur Datenverarbeitung. Unterscheiden Sie zwischen Inferenz, Telemetrie, Training, Indizierung, Synchronisierung und Sicherung.
2. Prüfen Sie Ausschlussregeln. Achten Sie insbesondere auf .git, .env, ignorierte Dateien, Abhängigkeiten, Zugangsdaten und symbolische Links.
3. Beginnen Sie mit einem entbehrlichen Repository. Verwenden Sie zunächst keinen sensiblen Code.
4. Prüfen Sie den lokalen App-Speicher. Unerwartet große Caches oder Snapshots können den verborgenen Datenumfang offenlegen.
5. Beobachten Sie den ausgehenden Datenverkehr. Firewall-, DNS-, Proxy- oder Router-Protokolle können Remote-Dienste identifizieren.
6. Verwenden Sie harmlose Canary-Dateien. Testen Sie, ob nicht zugehörige Dateien in den Modell- oder Upload-Kontext gelangen.
7. Gewähren Sie zuerst die geringstmöglichen Berechtigungen. Erweitern Sie sie nur, wenn eine konkrete Aufgabe dies erfordert.

Auch hier hilft das Design von Agenten mit geringsten Berechtigungen, sofern „schreibgeschützt“ mit eng begrenzten Pfaden und kontrollierten ausgehenden Daten kombiniert wird statt mit unbegrenzter Sichtbarkeit des Repositorys.

Was ein Local-First-Coding-Agent anders machen sollte

Local-First bedeutet nicht, dass jede Aufgabe offline ausgeführt werden muss.

Das bedeutet, dass lokale Daten standardmäßig innerhalb der lokalen Vertrauensgrenze bleiben und eine externe Übertragung bewusst statt beiläufig erfolgt.

Dieses Prinzip geht über das Programmieren hinaus. Ein wirklich lokaler KI-Workflow muss seine kritische Datenverarbeitung durchgängig lokal halten; ein lokal installiertes Modell reicht nicht aus, wenn Embeddings, Indizierung, Authentifizierung oder Dateiverarbeitung stillschweigend von einem Remote-Dienst abhängen.

Bei Hybridsystemen besteht das bessere Vorgehen darin, private Dateien hinter einem lokalen Dienst zu halten und nur den minimal erforderlichen Kontext für freigegebene Remote-Tools bereitzustellen. Derselbe Ansatz wird verwendet, wenn ein Agent entwickelt wird, der Cloud-Dienste nutzt, ohne das gesamte lokale Dateisystem offenzulegen.

Die größere Erkenntnis: Repository-Zugriff ist eine Sicherheitsberechtigung

Die wichtigste Lehre aus ZCode lautet nicht: „Verwenden Sie niemals Cloud-Coding-Agents.“ Vielmehr ist der Zugriff auf Repositorys zu einer eigenständigen Sicherheitsberechtigung geworden.

Ein moderner Coding-Agent kann Folgendes kombinieren:

• Lesen des gesamten Projekts
• Git-Unterstützung
• Terminalausführung
• Browserzugriff
• Remote-Modelle
• Hintergrundaufgaben
• Langzeitgedächtnis
• autonome Dateibearbeitung

Das bedeutet, dass Entwickler mehr prüfen müssen als nur, welche Befehle ein Agent ausführen kann.

Sie müssen außerdem fragen:

• Welche Dateien kann er beobachten?
• Wie weit zurück in der Historie kann er sehen?
• Welche dieser Daten verlassen das Gerät?
• Welcher Dienst erhält es?
• Wie lange wird es gespeichert?
• Wer kann es entschlüsseln?

Bei KI-Coding-Agents geht es beim Datenschutz nicht mehr nur darum, ob das Modell mit Ihrem Code trainiert wird. Entscheidend ist, ob die Datengrenze des Agents zu der Aufgabe passt, die Sie ihm tatsächlich gestellt haben.