Nouveautés de zn-gate 1.13.0 : zn-gate connect, zn-gate report et un correctif de la GitHub Action

zn-gate 1.13.0 ajoute zn-gate connect, qui active la vérification optionnelle dans le cloud avec une clé d'API d'analyse uniquement conservée dans le trousseau de votre système, et zn-gate disconnect, qui peut aussi révoquer cette clé. Il ajoute zn-gate report, un résumé local de ce que zn-gate a fait ces derniers jours. Il corrige aussi la version par défaut de la GitHub Action, garde le journal d'audit en une seule chaîne quand plusieurs programmes y écrivent et permet de désactiver la couleur avec NO_COLOR. zn-gate ne demande toujours aucun compte et n'envoie rien par défaut. Mettez à jour avec npm install -g zn-gate@1.13.0 et pip install -U zn-gate.

Comment activer la vérification optionnelle dans le cloud ?

Exécutez ceci dans votre propre terminal :

npx -y zn-gate connect

La vérification dans le cloud est optionnelle. zn-gate fonctionne entièrement sur votre ordinateur sans elle. Une fois activée, le texte des appels à analyze_prompt (et à zn-gate analyze), avec les secrets détectés masqués au préalable, est aussi vérifié par le classifieur Galvanize 2 de usezn.com. Les hooks, la protection des fichiers et des secrets et toutes les autres commandes restent locaux.

Ce que fait connect :

1. Il ne s'exécute que dans un terminal où vous tapez. Si un agent d'IA le lance, il refuse.
2. Il ouvre usezn.com dans votre navigateur, où vous créez une clé d'API d'analyse uniquement.
3. Vous collez la clé à une invite masquée. Elle n'est jamais prise sur la ligne de commande.
4. Il conserve la clé dans le trousseau du système, ou dans le coffre zn s'il n'y a pas de trousseau et que le coffre est déverrouillé (zn unlock), et jamais dans un fichier.

Il n'accepte qu'une clé limitée à l'analyse de texte. Une telle clé ne peut ni lire votre consommation ni gérer des clés : une copie divulguée n'est donc guère utile, et une clé à accès complet est refusée. zn-gate status indique si une clé est connectée et d'où elle vient, sans l'afficher. Une clé dans ZN_API_KEY ou --key n'intervient que si vous définissez aussi ZN_CLOUD=1. La clé enregistrée n'est envoyée qu'à https://api.usezn.com. Le guide complet, avec ce qui est envoyé et que faire en cas de problème, se trouve dans la documentation de connect.

Comment se déconnecter et révoquer la clé ?

zn-gate disconnect

Il supprime la clé enregistrée de cet ordinateur et demande s'il faut aussi la révoquer sur usezn.com, pour qu'elle cesse de fonctionner partout. La réponse par défaut est non. Seul un oui explicite envoie quelque chose : une requête avec la clé vers https://api.usezn.com. Dans votre propre terminal, --revoke passe la question et --no-revoke ne révoque jamais. Si la requête de révocation échoue, la copie locale est tout de même supprimée et la commande vous renvoie vers la page des clés d'API de usezn.com pour révoquer la clé vous-même.

Comme connect, disconnect ne s'exécute que dans votre propre terminal. Depuis un script ou un agent d'IA, il refuse et ne change rien. Les hooks refusent aussi les commandes qui demandent au trousseau du système les entrées propres à zn : les voies directes par lesquelles un agent lirait la clé enregistrée sont fermées. Un programme exécuté sous votre identité peut encore interroger le trousseau, comme pour toute entrée. C'est pourquoi la clé est limitée à l'analyse de texte.

Que montre zn-gate report ?

npx -y zn-gate report

Il affiche un court résumé des 7 derniers jours sur cet ordinateur :

• les actions bloquées, par agent ;
• les secrets masqués, par type ;
• les nouveaux serveurs MCP que zn-gate a commencé à protéger ;
• les outils de serveurs MCP protégés qui ont changé et attendent votre approbation ;
• le jour le plus chargé.

Utilisez --since avec une période de 1d à 90d pour changer la plage, et --json pour les scripts. Le rapport ne lit que des fichiers locaux, n'écrit rien et n'envoie rien. Il se termine par une ligne sur zn Team ; --no-team-line la masque, et elle n'apparaît plus une fois l'ordinateur rattaché à une Team. Voir la documentation de report.

Y a-t-il une correction de sécurité ?

Oui. Certains formats de jeton de fournisseurs n’étaient pas masqués par l’API de la bibliothèque, les contrôles des outils MCP, le texte envoyé à l’analyse dans le cloud et l’aperçu local des preuves. Ils sont désormais masqués comme dans le paquet Python. Les hooks d’agent n’étaient pas concernés. Mettez à jour vers zn-gate 1.13.0.

Quoi d'autre de nouveau ?

• Une clé d'API zn (zn_ suivi de 48 caractères) est reconnue par le scrubber et masquée comme les autres clés de fournisseurs.
• Claude Code : un nouveau hook UserPromptExpansion contrôle ce qu'une skill ou une commande saisie devient une fois développée. Il bloque le développement, avec la raison et la prochaine étape, lorsque le modèle verrait une valeur secrète, une clé privée ou les lignes d'un fichier .env. Relancez zn-gate hooks install claude-code pour l'ajouter ; le plugin l'inclut déjà.
• zn-gate check signale désormais lorsque les hooks Claude Code installés par un zn-gate plus ancien n'ont pas ce contrôle, et suggère la même commande.
• zn-gate init n'installe plus le plugin Claude Code lorsque Node.js est antérieur à la 20.12, dont le plugin a besoin. Il configure à la place les hooks de zn pour Claude Code et l'indique en une ligne.
• Les hooks contrôlent le code que les shells et les wrappers exécutent à partir d'une chaîne (sh -c, bash -lc, eval, pwsh -Command, cmd /c et d'autres) comme une commande à part entière : chaque règle s'applique donc à l'intérieur.
• zn audit masque la valeur qui suit une option d'identifiants dans davantage de formes de tableaux d'arguments, dans ses rapports texte, JSON et SARIF.
• Davantage de tests automatisés pour les serveurs MCP, zn run, le coffre, zn team, reach, audit et le paquet Python. Aucun changement de comportement.

Qu'est-ce qui change dans la GitHub Action ?

L'entrée version prend désormais par défaut la version de la release de l'Action elle-même (1.13.0 dans cette version). La version 1.12.0 de l'Action utilisait par défaut la 1.10.0 : un workflow avec usezn/zn@v1.12.0 et sans version installait donc zn-gate 1.10.0. Si vous utilisez l'Action, indiquez version dans votre workflow pour choisir exactement ce qui s'exécute. Le guide GitHub Actions présente les entrées et un exemple d'audit minimal, et cette version met aussi à jour le texte de la fiche du Marketplace sans changer le comportement.

Que se passe-t-il si le journal d'audit est endommagé ?

Le journal d'audit (~/.zn/evidence.jsonl) est désormais contrôlé avant que quoi que ce soit n'y soit ajouté. Un journal contenant des octets illisibles ou une dernière ligne tronquée est signalé comme corrompu, avec le numéro de ligne, par evidence --verify (code de sortie non nul), evidence et evidence --export, au lieu de provoquer une erreur Python. Un journal endommagé n'est jamais utilisé pour démarrer une nouvelle chaîne. L'événement n'est pas écrit, un avertissement s'affiche et votre commande ou votre agent continue comme d'habitude.

Pour récupérer, écartez le fichier endommagé : l'événement suivant démarre une nouvelle chaîne.

mv ~/.zn/evidence.jsonl ~/.zn/evidence.damaged.jsonl

Sous Windows, dans cmd : move %USERPROFILE%\.zn\evidence.jsonl %USERPROFILE%\.zn\evidence.damaged.jsonl ; dans PowerShell : Move-Item $env:USERPROFILE\.zn\evidence.jsonl $env:USERPROFILE\.zn\evidence.damaged.jsonl. L'ancien fichier reste disponible pour examen.

Plusieurs programmes peuvent écrire dans le journal en même temps, par exemple deux agents dans un même projet, ou les paquets Node.js et Python ensemble. Chaque écriture prend désormais un court verrou (un fichier evidence.jsonl.lock à côté du journal), si bien que les enregistrements restent dans une seule chaîne. Si le verrou reste occupé pendant 2 secondes, ou si le journal ne peut pas être écrit (pas de permission, disque plein), l'événement est ignoré avec un avertissement et la décision n'est pas modifiée. Un verrou laissé par un programme qui a planté est levé au bout de 10 secondes. Les paquets Node.js et Python peuvent aussi partager un journal contenant du texte non ASCII, comme des lettres accentuées ou du CJK, et les journaux écrits par les versions précédentes restent vérifiables.

Qu'est-ce qui est encore corrigé ?

• Le hook ne refuse plus une commande qui écrit un fichier à partir d'un here-document (cat > file <<'EOF') lorsque le corps contient un * ou un autre caractère générique, et il contrôle un corps de 100 Ko en quelques millisecondes au lieu de dizaines de millisecondes. Le corps d'un here-document n'est lu comme une donnée que dans une commande de données simple telle que cat ou tee. Les corps qu'exécute un shell, un interpréteur ou xargs restent refusés, de même que toute lecture de .env ou d'un fichier d'identifiants sur la ligne de commande.
• La sortie en ligne de commande des paquets Node.js et Python ne contient aucun code de couleur lorsque NO_COLOR a une valeur non vide, lorsque TERM=dumb ou lorsque la sortie n'est pas un terminal. Avec NO_COLOR ou TERM=dumb, elle omet aussi les symboles et les lignes de cadre. Les mots d'état, comme ALLOWED et BLOCKED, gardent leur sens, et les codes de sortie ainsi que les sorties JSON, SARIF et des hooks d'agent ne changent pas.
• Les hooks refusent un fichier .env atteint par une racine Windows, un partage réseau ou un chemin à longueur étendue (type %CD%\.env, more \\server\share\.env, gc \\?\C:\path\.env), car zn ne peut pas lire un tel chemin pour vérifier si le fichier contient des valeurs.
• La règle qui protège la clé de zn ne confond plus un module nommé cloud-keys avec le module cloud-key propre à zn, et reconnaît aussi les noms de module écrits avec des séquences d'échappement ou coupés par des guillemets.
• Le scrubber ne signale plus comme secret un exemple masqué (une clé Anthropic ou une valeur bearer composée presque entièrement d'un même caractère répété).
• zn-gate reach --remember n'affiche la date de l'exécution précédente que s'il s'agit d'une date simple : un fichier de mémoire modifié ne peut donc plus introduire d'autre texte dans le rapport.

Questions fréquentes

Quelles sont les nouveautés de zn-gate 1.13.0 ?

zn-gate connect et zn-gate disconnect, pour activer et désactiver la vérification optionnelle dans le cloud avec une clé d'API d'analyse uniquement, conservée dans le trousseau du système ou dans le coffre. zn-gate report, un résumé local des derniers jours. Le scrubber reconnaît les clés d'API zn, les hooks contrôlent ce qu'une skill saisie devient une fois développée, un journal d'audit endommagé est signalé au lieu de provoquer un plantage, et la version par défaut de la GitHub Action est corrigée. Le journal d'audit garde une seule chaîne quand plusieurs programmes y écrivent, et la sortie en ligne de commande peut être en texte brut avec NO_COLOR.

Comment mettre à jour vers zn-gate 1.13.0 ?

Exécutez npm install -g zn-gate@1.13.0 pour le paquet Node et pip install -U zn-gate pour le paquet Python. Si Claude Code utilise les hooks de zn plutôt que le plugin, exécutez npx -y zn-gate@1.13.0 hooks install claude-code pour ajouter le nouveau hook ; npx -y zn-gate@1.13.0 check vous signale s'il manque. Si vous utilisez le plugin Claude Code, mettez-le à jour depuis le répertoire des plugins dès que la 1.13.0 y figure.

Faut-il un compte pour utiliser zn-gate 1.13.0 ?

Non. zn-gate ne demande toujours aucun compte et n'envoie rien par défaut. zn-gate connect est optionnel : c'est seulement après l'avoir exécuté que le texte des appels à analyze_prompt (avec les secrets détectés masqués au préalable) est aussi vérifié par le classifieur Galvanize 2 de usezn.com.

zn-gate report envoie-t-il mes données quelque part ?

Non. Il ne lit que des fichiers locaux, n'écrit rien et n'envoie rien. Partager des statistiques d'usage avec zn est un choix distinct, désactivé tant que vous ne l'activez pas.

Quelle version la GitHub Action installe-t-elle si j'omets version ?

Depuis la 1.13.0, chaque version de l'Action utilise par défaut sa propre version de zn-gate. La version 1.12.0 de l'Action utilisait par défaut la 1.10.0 : un workflow avec usezn/zn@v1.12.0 et sans version installait donc zn-gate 1.10.0. Indiquez version dans votre workflow pour choisir exactement ce qui s'exécute.

---

La liste complète des changements figure dans les notes de la version 1.13.0. zn-gate est sous licence MIT, s'exécute en local et ne demande aucun compte : commencez par npx -y zn-gate report, ou consultez Installation pour chaque agent.