zn-gate 1.4.1 et ce qui quitte votre machine

Par défaut, rien ne quitte votre machine. Si vous activez la vérification cloud, seul le prompt est envoyé, après suppression préalable des secrets ; la sortie des outils n'est jamais envoyée. Pour les utilisateurs de zn-gate 1.4.0 qui avaient défini ZN_API_KEY, cette promesse n'était pas tenue. Cet article explique ce que faisait le paquet, ce que stockait notre API, ce que nous avons changé dans la 1.4.1 et ce que vous devez faire. En bref : mettez à jour et, si vous avez utilisé la 1.4.0 avec une clé d'API, renouvelez tout identifiant qui aurait pu apparaître dans la sortie d'un outil.

Ce que faisait la 1.4.0

zn-gate contrôle trois types de texte : les prompts, les arguments des appels d'outils et les résultats des outils (le contenu des fichiers lus par votre agent, la sortie des commandes qu'il exécute). Les trois étaient d'abord évalués par les règles locales. Dans la 1.4.0 et les versions antérieures, si les règles locales ne bloquaient pas le texte et que ZN_API_KEY était définie, le paquet Node envoyait ce texte à api.usezn.com pour un second avis du classifieur Galvanize-60M. Il le faisait sans caviarder les secrets, et pour les résultats et les arguments des outils, pas seulement pour les prompts.

Le README indiquait que le paquet était local d'abord et que la caviardage des secrets était appliquée. La fonction de caviardage existait dans le code, mais aucun chemin d'exécution ne l'appelait. Nous l'avons découvert lors d'une revue interne du paquet publié, le 2026-10-11.

Qui est concerné :

Les utilisateurs du paquet npm (le serveur MCP, zn-gate shield, zn-gate analyze, zn-gate test ou la bibliothèque) avec ZN_API_KEY définie et ZN_LOCAL_ONLY non défini à true.
Les utilisateurs du paquet Python avec ZN_API_KEY définie : seuls analyze() et zn-gate analyze envoyaient du texte, sans caviardage. guard, check_tool_call, check_tool_result, sanitize_tool_result et les intégrations aux frameworks ont toujours été locaux.
Les utilisateurs qui n'ont jamais défini ZN_API_KEY, ou qui ont défini ZN_LOCAL_ONLY=true, ne sont pas concernés. Rien ne quittait la machine.

Ce que stockait notre API

Le texte circulait en TLS et était évalué par le classifieur. Deux routes stockaient en plus les 1 000 premiers caractères de chaque entrée dans notre table de preuves, sans expiration : la route historique /prod/analyze et la route MCP analyze. La route actuelle /v30/analyze, que zn-gate utilise par défaut, ne stockait pas les entrées pour les offres payantes ; elle ne conservait une copie caviardée et tronquée que pour l'offre gratuite Contributor, qui y souscrit. Les journaux d'accès n'enregistrent que la route et le statut, jamais le contenu.

Le 2026-10-11, nous avons modifié l'API pour ne stocker qu'un hachage SHA-256 et la longueur de l'entrée, et nous avons supprimé le texte stocké dans la table de preuves pour chaque enregistrement qui en contenait : 1 281 enregistrements, datés entre le 22 août et le 12 septembre 2026.

Ce que change la 1.4.1

Les résultats des outils, les arguments des appels d'outils et les descriptions des outils ne sont évalués qu'en local, quelle que soit la configuration : serveur MCP, proxy shield et bibliothèque.
Le cloud est optionnel. L'analyse des prompts n'interroge le cloud que si vous définissez à la fois ZN_CLOUD=1 et ZN_API_KEY. ZN_API_KEY seule n'active rien. ZN_LOCAL_ONLY=true continue de tout remplacer.
Le caviardage s'exécute sur le chemin de code réel. check_tool_result renvoie toujours le contenu passé par le moteur de caviardage des secrets ; check_tool_call renvoie les arguments assainis ; shield transmet la sortie des outils avec les secrets caviardés. Quand le cloud est activé, le texte des prompts passe par le caviardeur avant envoi.
zn-gate status affiche ce que votre configuration envoie, et l'autotest n'utilise jamais le réseau.
Les nouveaux tests simulent le réseau et comptent les requêtes : la sortie d'un outil contenant de faux secrets revient caviardée et ne fait aucune requête, même avec ZN_API_KEY et ZN_CLOUD=1 définies. Face au code de la 1.4.0, sept de ces huit tests échouent.

Le README contient désormais un tableau « What leaves your machine » (ce qui quitte votre machine) dans les trois paquets, et le même tableau figure sur ce site.

Ce que vous devez faire

Mettez à jour : npx -y zn-gate@latest (ou npm install -g zn-gate@1.4.1) et pip install -U zn-gate.
Si vous avez utilisé la 1.4.0 ou une version antérieure avec ZN_API_KEY définie, considérez que tout identifiant apparu dans la sortie ou les arguments d'un outil pendant cette période a pu être transmis, et faites-le tourner.
Exécutez npx -y zn-gate status pour voir ce que votre configuration envoie désormais.

L'avis est publié sur GitHub sous l'identifiant GHSA-r4h2-qcf2-8227, avec la liste complète des chemins de code concernés dans le changelog de la 1.4.1.

Pourquoi nous publions ce détail

Personne ne nous l'a signalé ; nous l'avons trouvé nous-mêmes. Nous aurions pu publier la 1.4.1 avec une seule ligne dans le changelog. Nous publions les détails parce que toute l'idée de zn-gate est que vous puissiez faire confiance à ce qu'il fait de vos données, et que cette confiance doit tenir les jours où nous nous trompons. Si vous avez des questions, ou si vous estimez que quelque chose ici n'est pas encore assez précis, écrivez à security@usezn.com.

— John Silver

Mis à jour le 14 octobre 2026 : la formulation sur le traitement des données a été reformulée pour décrire ce que font aujourd'hui le paquet et l'API.