Contexte et découverte

Le 18 septembre 2026, le développeur ferstar a publié une analyse de ZCode, l’application de codage assisté par IA de Z.ai. En examinant le client app.asar, il a constaté que, dès que l’utilisateur est connecté, l’application crée une archive chiffrée contenant l’intégralité du répertoire .git, le cache LFS, les reflogs et les configurations globales. L’archive de 313 Mo provient d’un espace de travail commercial de 345 Mo contenant 42 411 fichiers. Pendant le test, 564 tentatives d’envoi ont échoué, mais le processus d’upload s’est poursuivi.

Mécanisme d’emballage et de chiffrement

Le client contacte zcode.z.ai pour obtenir des informations d’identification OSS : signature de formulaire, clé d’objet, plafond de taille et une clé publique RSA‑OAEP propre à chaque round. Le workspace est ensuite empaqueté en tar.gz, chiffré avec AES‑256‑CTR, puis la clé symétrique est enveloppée avec la clé publique RSA. Le paquet chiffré est envoyé directement à Aliyun OSS (Alibaba Cloud Object Storage) via un POST de formulaire. OSS notifie le backend de Z.ai pour enregistrer le snapshot. Le processus complet est illustré ci‑dessous :

1. GET credentials from zcode.z.ai → OSS signature, RSA‑OAEP public key
2. tar.gz workspace (incl. .git, LFS, logs)
3. AES‑256‑CTR encrypt payload
4. Wrap symmetric key with RSA‑OAEP
5. POST encrypted archive to Aliyun OSS
6. OSS callback to Z.ai backend

Le manifeste de l’archive, stocké en clair, montre la répartition suivante :

.git/lfs/      196.1 MB (56.8 %)
.git/objects/  102.2 MB (29.6 %)
.git/logs/        0.6 MB (0.2 %)
source code      46.2 MB (13.4 %)

Le répertoire .git représente 86,6 % du volume total, incluant l’historique complet, les clés API supprimées, les branches non poussées et les configurations internes. La clé privée correspondante réside uniquement dans le cloud de Z.ai ; aucune clé locale ne permet de déchiffrer le fichier, même en tentant d’utiliser toutes les clés privées présentes sur la machine.

Implications pour la confidentialité et limites de contrôle

Les paramètres UI de ZCode, comme « Optimize Experience » ou « Repo Snapshot Indexing », ne désactivent pas la capture. Le premier ne fait que limiter l’utilisation des données à l’entraînement du modèle, tandis que le second désactive uniquement l’indexation serveur. Le sidecar de capture est lancé au démarrage, conditionné uniquement par la présence d’un JWT valide. Les journaux de session montrent 62 événements de capture lors d’une session active, déclenchés avant chaque prompt et à la fin de chaque tâche. Aucun outil de l’agent ne référence l’upload, ce qui empêche l’utilisateur de le bloquer via les permissions habituelles.

Cette architecture crée un canal d’exfiltration invisible, où le serveur peut accéder à l’ensemble de l’historique de code à tout moment. La politique de confidentialité de Z.ai ne mentionne pas ce comportement, ce qui constitue une violation de la transparence attendue pour les outils de développement. Les développeurs qui utilisent des modèles GLM en local restent exposés tant qu’ils emploient ZCode, même si les poids du modèle sont open‑source. La recommandation technique consiste à désactiver complètement ZCode ou à recourir à des agents open‑source dont le code d’intégration est auditable.