Nouveautés de zn-gate 1.14.0 : prise en charge d'Antigravity et de ZCode desktop app, hooks pour Gemini CLI et GitHub Copilot CLI, plus de contrôles pour Codex CLI, correctifs du vault et de Team et analyse des configurations MCP

Sur npm, cette version est publiée sous le numéro 1.14.1, c'est-à-dire la 1.14.0 plus des correctifs pour Windows (voir le journal des modifications de sécurité). zn-gate 1.14.0 ajoute des hooks pour Google Antigravity et ZCode desktop app, désormais des agents pris en charge, et des hooks expérimentaux pour Gemini CLI et GitHub Copilot CLI et plus de contrôles pour Codex CLI. Il trouve aussi les clés et mots de passe écrits en clair dans les configurations de serveurs MCP, renforce le vault et zn Team, comble une lacune du garde d'outils Python et ajoute des exemples pour celles et ceux qui construisent des agents avec un framework. zn-gate n'a toujours pas besoin de compte et n'envoie rien par défaut. Mettez à jour avec npm install -g zn-gate@1.14.1 et pip install -U zn-gate.

Rejouer

Quels nouveaux agents zn-gate protège-t-il ?

Quatre agents de plus reçoivent un hook avant exécution. Antigravity et ZCode desktop app rejoignent Claude Code, Codex CLI, Cursor et OpenCode parmi les agents pris en charge, ce qui en fait six. Gemini CLI et Copilot CLI sont expérimentaux et présentés à part.

npx -y zn-gate hooks install gemini
npx -y zn-gate hooks install antigravity
npx -y zn-gate hooks install zcode
npx -y zn-gate hooks install copilot

Ajoutez --project pour installer le hook uniquement pour le projet courant (pas pour ZCode, qui ignore les hooks de projet). Sans cette option, le hook va dans vos réglages utilisateur.

• Gemini CLI : le hook empêche l'agent de lire ou d'écrire des fichiers secrets par chemin et d'exécuter des commandes shell qui manipulent des secrets. Il protège aussi les fichiers de réglages de Gemini CLI contre les modifications par l'agent. Les hooks de Gemini CLI ne peuvent pas demander de confirmation : zn-gate bloque donc ce qu'il refuserait, et ce sur quoi il demanderait, en indiquant la raison et comment l'approuver. Pour tout le reste, l'approbation propre à Gemini CLI s'applique.
• Google Antigravity : le hook fait la même chose et protège ses propres fichiers de hook. Une recherche dans un dossier demande confirmation lorsque le dossier contient un .env ou un fichier de clés en clair. Les hooks d'Antigravity ne peuvent pas réécrire la sortie des outils : les lignes correspondantes et la sortie des commandes n'y sont donc pas masquées. Le guide Antigravity détaille ce que le hook ne couvre pas, notamment le fait qu'Antigravity ne documente pas ce qui se passe quand un hook échoue.
• Application de bureau ZCode : zn hooks install zcode (ou npx -y zn-gate init) ajoute des hooks exécutés avant chaque appel d'outil et avant chaque prompt. Il bloque la lecture et l'écriture de fichiers secrets, les commandes shell qui manipulent des secrets, les appels MCP qui enverraient un secret et un prompt contenant un secret, et l'agent ne peut pas modifier le fichier de configuration de ZCode. Il ne peut pas retirer les secrets de ce que renvoie un outil (zn ajoute un avertissement quand une sortie en contient un), ZCode ignore les hooks d'un projet, et le launcher de zn bloque l'appel quand son Node.js a disparu : considérez-le comme une première couche. La documentation de ZCode ne dit pas ce qui se passe lorsqu'un hook échoue ; dans nos tests avec l'application de bureau ZCode 3.16.3 sous Linux, un hook qui a échoué (un code de sortie autre que 2, un plantage ou un dépassement de délai) a laissé l'appel s'exécuter, et seuls le code de sortie 2 ou une réponse deny l'ont bloqué. Testé de bout en bout sur l'application de bureau officielle ZCode 3.16.3 sous Linux x64 (octobre 2026). Les mêmes vérifications ont réussi sous Windows x64 (Windows Server 2022, même version de l'application, octobre 2026), pour un administrateur et pour un utilisateur standard, via l'agent fourni avec l'application ; la fenêtre de l'application Windows elle-même n'a pas été pilotée. macOS n'a pas été testé. Sous Windows, zn-gate check reconnaît désormais le hook que zn hooks install zcode écrit. Une version plugin de ZCode pour Linux existe ; ses étapes d'installation seront publiées avec son dépôt de plugin. Détails : page ZCode.
• GitHub Copilot CLI : le hook empêche l'agent de lire ou d'écrire des fichiers secrets par chemin et d'exécuter des commandes shell qui manipulent des secrets, remplace les valeurs secrètes dans les résultats des outils de lecture et de shell, et protège contre les modifications par l'agent les fichiers de hook et de réglages de Copilot. Les hooks de Copilot CLI ne peuvent pas bloquer un prompt saisi, et Copilot laisse passer un appel si un hook dépasse le délai : zn, qui fixe un délai de 15 secondes sur ses hooks, bloque donc lui-même l'appel à 11 secondes.

zn-gate check signale ces hooks et avertit lorsque Gemini CLI, Copilot CLI ou ZCode a désactivé les hooks. Consultez Installation pour chaque agent.

Rejouer

Quoi de neuf pour Codex CLI ?

Après la mise à jour, relancez zn-gate hooks install codex, puis examinez dans Codex les hooks modifiés avec /hooks.

• zn-gate contrôle désormais les appels d'outils MCP avant leur exécution, comme il le faisait déjà pour Cursor.
• Il répond à la demande d'autorisation de Codex par un refus lorsque son contrôle refuserait l'appel : aucun bouton Approuver n'apparaît pour un appel que zn-gate bloque. Il ne répond jamais Autoriser.
• Il examine la réponse finale du modèle. Il vous avertit lorsque la réponse contient une valeur secrète ou un marqueur __ZN_ qu'il n'a pas vu plus tôt dans la session. L'avertissement s'affiche pour vous, pas pour le modèle. Pour que Codex demande au modèle de réécrire une telle réponse, définissez "stopReview": "block" sous hooks dans ~/.zn/config.json.
• Un réglage facultatif, hooks.replaceToolOutputOnSecret, remplace un résultat d'outil contenant un vrai secret par un court texte qui nomme le type de secret, jamais la valeur. Il est désactivé par défaut.
• zn-gate check signale Codex comme non entièrement protégé lorsqu'un hook PreToolUse ou PermissionRequest d'un autre outil est présent, car Codex exécute ces hooks en même temps et l'un d'eux peut modifier une commande après le contrôle de zn-gate. Il signale aussi un hook zn réglé pour s'exécuter en arrière-plan ou désactivé dans config.toml.
• zn-gate hooks install codex ajoute aussi les hooks SessionStart et SubagentStart. Ils ajoutent un court rappel pour le modèle et ne bloquent jamais. Le guide Codex décrit la configuration.

Que trouve scan désormais ?

zn-gate scan et zn audit cherchent les clés et mots de passe écrits en clair dans les configurations de serveurs MCP (.mcp.json, .cursor/mcp.json, .vscode/mcp.json, .codex/config.toml, claude_desktop_config.json et similaires). Ils contrôlent une valeur sous un nom tel que clé d'API, jeton ou mot de passe, un en-tête Authorization, la valeur qui suit une option d'identifiant dans args et une clé dans l'URL d'un serveur. Les références comme ${NAME} ne sont pas signalées. Le rapport indique le type, le nom qui contient la valeur, le fichier et la ligne, jamais la valeur, et explique comment la déplacer dans le coffre ou dans une variable d'environnement.

npx -y zn-gate scan --include-home

--include-home contrôle aussi vos propres configurations MCP (Claude Desktop, Claude Code, Cursor, Codex, Gemini, Antigravity, OpenCode et Amazon Q). Scan liste désormais les dossiers qu'il ne lit pas, avec la raison, au lieu de les ignorer en silence ; il affiche « No files were scanned » lorsqu'il n'y a rien à analyser, pour qu'un résultat vide ne passe plus pour un résultat propre ; il suit un lien donné comme dossier à analyser ; et il lit .vscode/mcp.json. Voir le guide de scan.

Y a-t-il des correctifs de sécurité ?

Oui.

• Hooks qui bloquent en cas d'échec : les hooks de Claude Code, Codex, Cursor et Gemini CLI ne laissent plus les appels d'outils s'exécuter sans contrôle lorsque le Node.js avec lequel ils ont été installés disparaît (un changement ou une désinstallation de nvm, une mise à jour) ou lorsque le hook plante. Ils bloquent l'appel à la place. Dans Claude Code et Codex, ils bloquent aussi lorsque le hook dépasse le délai. Relancez zn hooks install <agent> pour mettre à niveau une installation existante ; zn-gate check signale désormais un hook dont le Node.js ou le lanceur a disparu. Pour le plugin Claude Code, lancez claude plugin update zn-gate@usezn et démarrez une nouvelle session ; il faut Claude Code 2.1.295 ou une version ultérieure. Codex n'a pas de réglage pour cela : ses hooks répondent donc eux-mêmes par un refus quelques secondes avant la limite de temps de Codex.
• Garde d'outils Python : les arguments ou résultats d'outils imbriqués sur plus de huit niveaux environ passaient sans être contrôlés, si bien qu'une valeur cachée à cette profondeur échappait à toutes les règles. Ils sont désormais bloqués avec le motif « nested too deeply to check ». Cela concerne le paquet Python, version 1.13.1 et antérieures. Mettez à jour avec pip install -U zn-gate.
• Sortie de scan : zn-gate scan affiche les caractères de contrôle des noms de fichiers et de dossiers sous forme de séquences d'échappement (par exemple \x1b), si bien qu'un nom dans un dépôt ne peut pas écrire de séquences de terminal. Cela couvre les deux paquets.
• Hooks : les noms de fichiers et textes mal formés (comme des substituts Unicode isolés) sont refusés au lieu d'arrêter le hook sur certains systèmes Windows. La règle qui protège le module de clés de zn reconnaît aussi son nom lorsqu'il est construit à l'intérieur d'une commande.
• Passerelle expérimentale : les enregistrements d'audit chiffrés sont liés à leur propre identifiant et espace de noms, le journal d'audit refuse de s'ouvrir avec une mauvaise phrase secrète, le contrôle d'origine par défaut n'accepte que les origines loopback et une politique téléversée est vérifiée avant d'être enregistrée.
• Rapports d'audit : zn audit masque la valeur qui suit davantage d'options d'identifiant, comme --passphrase, --bearer et --jwt.
• Installation pour ZCode : zn hooks install zcode et uninstall sont atomiques. L'installation enregistre la valeur de hooks.enabled avant de toucher à la configuration et écrit config.json en dernier : une installation qui échoue en cours de route ne laisse plus vos propres hooks activés sans rien d'enregistré pour revenir en arrière. Le launcher a sa propre échéance, deux secondes sous le délai des hooks de ZCode : un hook qui se bloque au démarrage est donc bloqué au lieu de laisser l'appel s'exécuter.
• Hooks de projet : une installation de projet (zn hooks install <agent> --project) pour Claude Code, Codex CLI, Cursor, Gemini CLI et Copilot CLI écrivait une simple commande zn hook <agent>. Là où zn ou Node.js ne pouvaient pas démarrer, par exemple sur une autre machine, la commande échouait et l'agent exécutait l'appel sans contrôle. Le hook de projet s'exécute désormais dans une garde de démarrage qui bloque l'appel lorsque zn ou Node.js est absent ou que le hook échoue (ou se contente d'avertir, pour les événements qui ne peuvent pas bloquer). La garde ne fait confiance à zn et à Node.js que depuis des entrées PATH absolues, fonctionne avec tous les sh, y compris celui de macOS, et dispose d'une forme PowerShell sous Windows. zn-gate check signale un simple zn hook <agent> dans un fichier de projet comme non protégé, et une garde différente de celle que zn écrit comme modifiée. Relancez zn hooks install <agent> --project dans ce projet pour la remplacer.
• Launchers des hooks : les scripts launcher n'exécutent jamais un programme trouvé dans une entrée PATH relative comme ., de sorte qu'un programme placé dans un dossier de projet n'est jamais exécuté, et ils suppriment leurs fichiers privés après chaque appel. Sous Windows, zn.cmd ne peut plus démarrer un node.exe ou un node.bat depuis le dossier courant. Si vous avez essayé une release candidate 1.14.0, relancez zn hooks install (et zn hooks install --project dans chaque projet qui a un hook de projet) afin que les hooks qu'elle a écrits reçoivent ces correctifs.
• Hooks des plugins : les hooks du plugin zn-gate pour Claude Code, Codex et ZCode ne démarrent Node.js qu'à partir d'entrées PATH absolues situées en dehors du projet ou des dossiers d'installation habituels, et le plugin ZCode démarre ses hooks avec /bin/sh par son chemin complet, de sorte qu'un node ou un sh présent dans le projet (son bin/ ou node_modules/.bin) ne s'exécute jamais à leur place. Le plugin Cursor n'est plus proposé : utilisez zn hooks install cursor, et si vous avez ajouté le plugin dans Cursor, supprimez-le (Customize). Le plugin n'ajoute plus de serveurs MCP : pour le serveur secrets, utilisez zn hooks install claude-code. zn-gate check signale comme non protégé un hook de plugin qui ne démarre pas de cette manière. Dans Claude Code sous Windows, le plugin a besoin de Git Bash ; sans lui, utilisez zn hooks install claude-code. Mettez le plugin à jour avec claude plugin update zn-gate@usezn, et réinstallez le plugin ZCode dans ZCode (Settings, Plugins).
• Dossiers de plugins : les hooks protègent désormais les dossiers de plugins des agents et l'état des plugins comme ils protègent les réglages de hooks : un agent ne peut plus écrire, supprimer ni déplacer les fichiers d'un plugin installé ni la liste des plugins installés dans Claude Code, Codex, Cursor, ZCode et Antigravity, de sorte qu'un agent victime d'une injection de prompt ne peut pas modifier le script de hook d'un plugin pour éviter les vérifications de zn. Les dossiers .gemini/ et .claude/plugins/ propres à un projet restent accessibles en écriture.
• Sortie des hooks : un hook qui ne parvenait pas à écrire toute sa réponse à l'agent (par exemple parce que l'agent avait fermé le tube) se terminait comme s'il avait fonctionné, si bien qu'un blocage pouvait être perdu. Une écriture échouée fait désormais échouer le hook, et les launchers n'acceptent un hook que s'il confirme avoir écrit toute sa réponse ; sinon ils bloquent l'action, ou avertissent pour les événements qui ne peuvent pas être bloqués.
• Délais des hooks : un hook dont l'entrée ne se termine jamais, ou dont la vérification ne se termine jamais, bloque désormais l'appel avant le délai propre à l'agent, au lieu de laisser l'agent sans réponse, ce qui laisse l'appel s'exécuter. Gemini CLI et Copilot CLI, qui laissent passer un appel quand un hook dépasse le délai (zn fixe leur délai de hook à 15 secondes), reçoivent le blocage à 11 secondes. Un SIGTERM, SIGHUP ou SIGINT pendant une vérification répond aussi par le blocage.
• Agents qui ne peuvent pas demander : Codex CLI, Cursor, OpenCode et Gemini CLI ne peuvent pas afficher de question, et zn abandonnait celles qu'il voulait poser (une écriture dans un fichier d'instructions, des données personnelles dans un appel MCP, une recherche dans un dossier contenant un .env en clair), si bien que l'appel s'exécutait. zn bloque désormais un tel appel et la raison indique ce qui a été retenu et comment l'approuver. Claude Code, Copilot CLI, Antigravity et ZCode continuent de demander. Un appel d'outil illisible est désormais bloqué dans tous les agents.
• Marques invisibles : les règles ignorent désormais les marques gauche-à-droite, droite-à-gauche et lettre arabe, le séparateur de voyelle mongol et les caractères de remplissage hangul lorsqu'elles comparent du texte, de sorte que ces caractères ne peuvent plus couper une phrase déclencheuse. La vérification des sorties d'outil composées en grande partie de caractères invisibles les compte aussi. Le texte arabe et hébreu normal n'est pas bloqué.
• Sortie d'outil trop volumineuse : un événement d'outil trop volumineux n'atteint plus le modèle sans contrôle dans Claude Code, Codex ou Copilot CLI. Le hook retient désormais la sortie d'un événement post-outil trop grand pour être vérifié, et le launcher du plugin cesse de lire un événement à 32 MiB.
• zn-gate init : il n'écrit plus dans zn.json les clés ou jetons lus dans l'environnement (ZN_API_KEY, ZN_JWT_SECRET, ZN_MCP_WS_TOKEN, ZN_DB_KEY), et crée le fichier lisible uniquement par son propriétaire sous Linux et macOS.
• Audit de la passerelle expérimentale : chaque entrée d'audit porte le namespace de l'appelant authentifié : un tenant ne peut donc plus voir les appels d'un autre tenant dont le namespace correspondait. Le journal d'audit ne stocke que des métadonnées par défaut, et la couche neuronale ne conserve plus les arguments des appels. La mise à jour de la passerelle nettoie le texte que les versions précédentes avaient laissé dans les fichiers de mémoire vectorielle et efface l'ancien texte des voisins dans le journal d'audit, en compactant la base de données pour que ce texte ne reste pas dans les pages libres. Le flux d'événements, l'export SIEM et les alertes webhook ne contiennent jamais le contenu de la requête, et un data/ref.key qui est un lien ou qui est ouvert à d'autres utilisateurs est refusé au démarrage.
• Appels MCP et requêtes réseau : Claude Code contrôle désormais les appels d'outils MCP avant leur exécution, comme le faisaient déjà les autres agents : une valeur secrète ou un marqueur dans les arguments est bloqué et les données personnelles vous demandent d'approuver l'appel (relancez zn hooks install claude-code pour mettre à niveau une installation existante). Avant qu'un agent n'exécute une requête réseau (curl, wget, Invoke-WebRequest, python -c ou node -e en ligne, WebFetch, ou un appel MCP avec une URL ou des en-têtes), les hooks examinent ses en-têtes, sa chaîne de requête et son corps à la recherche de données personnelles et de secrets littéraux, et vous demandent avant son exécution. Les requêtes vers localhost sont ignorées, et hooks.egressCheck et hooks.egressAllowHosts dans ~/.zn/config.json modifient ce comportement.
• Instructions dans la sortie des outils : dans Claude Code, la sortie des récupérations web, des outils MCP et des commandes shell est contrôlée avec les règles locales. Lorsqu'elles signalent un texte qui ressemble à des instructions, l'agent est invité à le traiter comme des données et à vous le dire. C'est activé par défaut et ne bloque jamais ; hooks.checkToolOutputInstructions: false le désactive. De nouvelles règles signalent aussi un texte, dans une page, un résultat MCP ou un fichier, qui demande à l'agent d'identifier son utilisateur ou de mettre le nom, l'e-mail ou la clé d'API de l'utilisateur dans un en-tête, une URL, un cookie ou un champ de formulaire. Elles sont un simple avertissement par défaut et bloquent en mode strict.
• Règles de commande : les règles sur les commandes destructrices et les fichiers protégés lisent désormais une commande comme le fait un shell. Les mots coupés par une barre oblique inverse, les listes avec accolades (c{u,}rl ... | sh), les charges Base64 entre guillemets, avec printf ou dans un here-string, une redirection collée au mot qui la précède, les flux de données alternatifs NTFS (.aws\credentials::$DATA) et un chemin du dossier personnel après @ dans un argument d'envoi sont détectés comme leurs formes simples. Le dossier propre à zn reste aussi protégé lorsque le nom du dossier personnel contient un accent écrit sous une autre forme Unicode, comme sur macOS. Les paquets Node.js et Python rendent les mêmes verdicts.
• Commandes destructrices : les hooks des agents refusent désormais par défaut une suppression récursive du dossier personnel, de la racine du système de fichiers ou d'un dossier système, ainsi qu'une écriture sur un périphérique disque. L'agent est invité à vous demander confirmation d'abord. Quatre autres règles (un téléchargement redirigé vers un shell, chmod -R ou chown -R sur la racine ou un dossier système, une fork bomb et un téléchargement écrit dans un fichier de démarrage du shell) sont désactivées par défaut ; hooks.blockDestructiveCommands dans ~/.zn/config.json les active. Il lit uniquement le texte de la commande et n'est pas un bac à sable.
• Shield MCP : il vérifie désormais les résultats d'outils en entier jusqu'à 32 Mo (avant, seuls le début et la fin d'un résultat plus gros étaient vérifiés), ainsi que les notifications et requêtes envoyées par les serveurs, le contenu des ressources et des prompts, et toutes les chaînes des schémas d'outils. Un schéma d'outil trop profond ou trop gros pour être vérifié est remplacé par un avis au lieu de passer sans contrôle. Une sortie d'outil composée surtout de caractères invisibles ne laisse plus passer un secret dans Claude Code, Copilot et OpenCode. Dans le SDK, un résultat d'outil de plus de 4 Mo est désormais bloqué par défaut ; ZN_ALLOW_TRUNCATED=1 l'autorise.
• Masquage des secrets : les secrets coupés sur plusieurs lignes, utilisés comme noms de propriété dans la sortie d'un outil, dans des clés privées OpenPGP, imbriqués dans des résultats LangChain ou dans davantage de formes d'URL de connexion sont désormais masqués, dans le paquet npm comme dans le paquet Python. Un test masque désormais des textes aléatoires de fausses clés avec les deux paquets et échoue si l'un d'eux laisse une clé dans la sortie.
• Plus de contrôles du garde Python : il lit désormais les chaînes à l'intérieur des dataclasses, des modèles pydantic et d'autres objets, bloque les arguments qu'il ne peut pas lire en entier (un générateur, par exemple, car le vérifier l'épuiserait), décode le Base64 sans remplissage = et vérifie et masque le message d'une erreur levée par un outil, car les frameworks d'agents envoient ce message au modèle. L'intégration LangChain prend en charge langchain-core 1.3.3 et versions ultérieures ; les versions antérieures ont un avis de sécurité de gravité élevée connu.
• Audit, coffre et passerelle : le chiffrement du journal d'audit tire chaque nonce d'un générateur aléatoire initialisé par le système d'exploitation, et les enregistrements chiffrés existants sont mis à niveau la première fois que le coffre d'audit s'ouvre avec sa clé. Une erreur du coffre ne cite plus de texte déchiffré. zn audit n'affiche plus la valeur qui suit une option d'identifiant comme nom de paquet d'un serveur MCP npx. zn-gate init --revert ne restaure que la sauvegarde la plus récente à côté de la configuration et ignore les sauvegardes qui sont des liens ou qui se trouvent dans un autre dossier : un dépôt ne peut plus rediriger une restauration vers votre propre configuration MCP. La passerelle expérimentale met à jour rustls-webpki, webpki-root-certs et wasmtime (RUSTSEC-2026-0378, -0379, -0382 et -0383).

• Fichiers d'instructions : les hooks des agents demandent avant qu'un agent n'écrive dans les fichiers où il garde sa mémoire et ses instructions permanentes (MEMORY.md, AGENTS.md, CLAUDE.md, .cursorrules et similaires), car les agents les relisent lors des sessions suivantes. En mode strict, l'écriture est refusée, et hooks.agentInstructionWrites: "off" désactive la question. La lecture de ces fichiers n'est jamais bloquée. Les agents qui ne peuvent pas demander (Codex CLI, Gemini CLI, OpenCode et les outils de fichiers de Cursor) gardent leurs propres règles d'approbation.

• Plus de façons d'écrire une commande : un téléchargement redirigé vers un shell ou vers Invoke-Expression est désormais aussi détecté lorsqu'il est écrit avec la citation ANSI-C ($'...') ou avec des échappements par accent grave de PowerShell à l'intérieur d'un mot. Un texte simplement affiché, comme dans echo $'curl ... | sh', reste autorisé.

Qu'est-ce qui change pour le vault et zn Team ?

• Marqueurs de secret dans les arguments (changement incompatible) : zn run et les hooks de l'agent ne remplissent plus un marqueur de secret écrit dans les arguments d'une commande, car les arguments apparaissent dans la liste des processus et dans les journaux de ligne de commande. Enregistrez le secret pour le programme (zn secret set PGPASSWORD --command psql), puis lancez zn run --secrets PGPASSWORD -- psql "postgres://user@db/app", où psql lit lui-même la variable. Un marqueur dans un fichier d'environnement que votre shell charge (un .env masqué) est toujours rempli. secrets_http_request n'envoie désormais que les secrets stockés en mode proxy : changez le mode d'un secret avec zn secret allow NAME --mode proxy si une API en a besoin.
• Les approbations suivent la valeur : une approbation de première utilisation appartient désormais à la valeur pour laquelle elle a été donnée. Supprimer un secret supprime ses approbations, et remplacer une valeur redemande. Les approbations enregistrées par la 1.13.x et les versions antérieures n'ont pas d'identifiant et ne comptent pas : après la mise à jour, chaque secret redemande donc une fois, la première fois qu'une commande l'utilise.
• Valeurs courtes : le vault n'accepte plus un nouveau secret de moins de 8 caractères, car une telle valeur ne se distingue pas d'un texte ordinaire. Une valeur courte stockée par une version plus ancienne continue de fonctionner.
• Qui peut demander une valeur : le masquage s'exécute désormais dans le démon du vault, et chaque demande de valeur indique une destination ou un objectif que le démon vérifie par rapport à ce qu'il détient. Une demande sans contexte est refusée et écrite dans le journal d'audit. Un programme qui peut parler au démon peut encore demander un secret stocké par son nom dans un contexte qui lui correspond : le modèle de menaces indique ce que cela arrête et n'arrête pas.
• Windows et scripts non sûrs : le vault définit des permissions explicites réservées au propriétaire sur ses dossiers, la clé de session et le pipe du démon, et ne démarre pas s'il ne peut pas les vérifier. zn run refuse de donner des valeurs secrètes à un script que d'autres peuvent modifier ou qui se trouve dans un dossier où d'autres peuvent écrire.
• Réinitialisation et purge : zn vault reset conserve une sauvegarde chiffrée et indique où elle se trouve. Le nouveau zn vault purge supprime définitivement un vault : il liste chaque fichier, demande confirmation (jamais pour un agent IA) et vérifie qu'il n'en reste aucun. zn-gate uninstall supprime désormais aussi les sauvegardes et les tables de jetons.
• Vérification du journal d'audit : le vault déverrouillé vérifie désormais l'ensemble du journal d'audit (la signature de chaque enregistrement, la chaîne et le dernier enregistrement dont il se souvient) avant que zn vault log ne l'affiche, que zn vault log export --otlp ne l'exporte ou que zn team sync ne le téléverse, et avant d'y ajouter quoi que ce soit. Jusqu'ici, seul le dernier enregistrement était comparé. Le vault compare aussi le journal avec le dernier enregistrement dont il se souvient, par numéro de séquence et signature, avant de se déverrouiller et avant chaque écriture, et les enregistrements d'audit sont écrits sur le disque au moment où ils sont créés. Si une vérification échoue, le journal n'est ni affiché, ni exporté, ni téléversé, le vault enregistre un avertissement qui survit au verrouillage et au déverrouillage, et zn vault verify échoue tant que vous n'avez pas accepté le journal avec zn vault verify --acknowledge dans votre propre terminal. Limites : lorsque le vault est verrouillé, zn vault log et zn vault log export --otlp ne peuvent pas vérifier la chaîne et le disent ; la restauration d'un ancien secrets.age, avec ou sans son ancien audit.jsonl, n'est pas détectée ; et si le processus du vault est tué, les enregistrements écrits depuis sa dernière sauvegarde (jusqu'à une minute) peuvent être coupés sans avertissement. Lorsque le vault se déverrouille après un arrêt brutal et reprend des enregistrements d'audit qui n'avaient pas encore de point de contrôle, il écrit un enregistrement warn : chaque plantage apparaît donc dans zn vault log.
• Politique zn Team : zn team sync refuse une seconde politique signée qui a la même version mais un contenu différent, et une synchronisation commencée avant que vous quittiez une équipe ne peut plus appliquer sa réponse. Quand une nouvelle version de la politique assouplit une restriction, zn team status liste ce qui a changé, le journal d'audit l'enregistre et Claude Code le signale une fois.
• Rejoindre et quitter zn Team : zn team join n'envoie plus les enregistrements d'audit écrits avant votre arrivée ; --include-history les ajoute, à la première adhésion uniquement. zn team join et zn team sync se terminent avec le code 1 quand la politique n'a pas été appliquée, et zn team leave prévient d'abord le serveur et indique ce qu'il a répondu. zn team join s'arrête aussi, sans rien envoyer, lorsque le journal d'audit local ne peut pas être lu.
• Détecteurs d'équipe : les détecteurs personnalisés de l'organisation ne sont plus perdus quand ~/.zn/team.json ou la copie de la politique est supprimé ou modifié : zn team sync et zn team status les restaurent depuis le vault.

Quoi d'autre de nouveau ?

• Le paquet Node.js a le même garde d'outils que le paquet Python : checkToolCall et guardTool. Il fournit aussi des types TypeScript.
• zn vault reset est la sortie lorsque vous oubliez la phrase secrète du coffre. Il ne s'exécute que dans votre propre terminal, vous demande de saisir une phrase de confirmation et enregistre d'abord l'ancien coffre dans un dossier de sauvegarde.
• zn team managed-config affiche les réglages gérés qu'un administrateur déploie avec la gestion des appareils pour que les hooks s'exécutent sur chaque machine de développement. Il n'écrit rien.
• Lorsqu'un hook bloque quelque chose ou masque un secret, zn-gate evidence l'affiche désormais comme un événement (jamais une valeur, une commande, un chemin ni le texte d'un prompt).
• Des exemples exécutables pour CrewAI, LlamaIndex, l'OpenAI Agents SDK, Pydantic AI, Google ADK et Haystack. Chacun contrôle la sortie d'un outil avant que le modèle ne la lise, s'exécute en local avec des pages fictives et n'a besoin d'aucune clé d'API. Voir Frameworks.
• Une référence de la ligne de commande liste chaque commande zn-gate, et un guide de mise à niveau explique quoi faire après chaque mise à jour.
• Chaque version inclut désormais une nomenclature logicielle pour les paquets npm et Python.
• zn-gate scan ne se termine plus avec le code 0 quand son résultat ne couvre pas tous les fichiers qu'il aurait dû lire. Il se termine avec le code 3 quand aucun fichier n'a été lu, ou quand un fichier ou un dossier a été ignoré (2 MiB ou plus, illisible, pas un fichier ordinaire). Les détections se terminent toujours avec le code 1, et --allow-partial conserve le code 0 quand seuls certains fichiers ont été ignorés. Les jobs de CI qui exécutent zn-gate scan peuvent voir ce nouveau code de sortie.
• Les hooks démarrent plus vite sur Node.js 22.1 et versions ultérieures, et le paquet Python déclare maintenant Python 3.14. Les hooks ne chargent aussi le code qui exécute d'autres programmes que lorsqu'ils en ont besoin, et la recherche de caractères cachés dans une très grande sortie d'outil est plus rapide quand il n'y en a aucun.
• Le scrubber repère davantage de façons de coller un secret : valeurs entre accents graves, JSON échappé copié depuis des journaux, setx NAME value, affectations PowerShell et NAME=value commande.
• zn-gate uninstall supprime zn-gate en une seule étape. Il liste ce qu'il a trouvé (le plugin Claude Code, les hooks de zn pour chaque agent et les serveurs MCP enveloppés par init --wrap-mcp), vous demande de confirmer dans votre propre terminal, les supprime et lance zn-gate check. Le coffre n'est supprimé que si vous le confirmez séparément, et --dry-run affiche la liste sans rien modifier. Les agents ne peuvent pas l'exécuter à votre place : comme les autres commandes qui modifient votre configuration, il faut que vous l'exécutiez dans votre propre terminal. Voir Supprimer zn-gate.
• Des hooks pour le framework pre-commit : zn-gate-scan lance zn-gate scan et zn-audit lance zn audit sur votre dépôt avant chaque commit. Ils nécessitent Node.js 18 ou une version ultérieure.
• zn audit lit désormais les fichiers d'instructions que les agents chargent via un autre fichier (les imports @path dans CLAUDE.md et les chemins instructions de opencode.json), trouve les fichiers d'agent dont les noms ne diffèrent que par la casse, signale un fichier d'agent qu'il ne peut pas lire et affiche « not checked » au lieu de « No findings » lorsqu'il n'a rien trouvé à lire pour un agent. Il produit aussi moins de faux positifs : les permissions Claude Code ciblées comme Bash(git status:*), les étapes de configuration ordinaires comme copier .env.example vers .env et la documentation dans un SKILL.md ne sont plus signalées comme des risques.
• zn-gate check et zn-gate status reconnaissent les installations gérées (les réglages gérés de Claude Code, les hooks d'entreprise de Cursor et le requirements.toml de Codex) et nomment le fichier. Ils avertissent aussi, sans bloquer, lorsque votre Node.js est en fin de vie (18 et 20) ou plus ancien que la version corrigée de sa branche. Le plugin Claude Code nécessite désormais Node.js 20.19 ou une version ultérieure ; zn-gate et les hooks de zn fonctionnent toujours sur Node.js 18 et versions ultérieures.
• En Python, guarded_tool analyse désormais par défaut la sortie d'un outil à la recherche d'injection de prompt (passez check_result=False pour garder l'ancien comportement), nomme les cibles bloquées tool:<name> et fonctionne aussi avec les outils asynchrones. De nouveaux hooks natifs couvrent Google ADK, l'OpenAI Agents SDK et Pydantic AI, y compris les outils que ces frameworks fournissent eux-mêmes, comme les serveurs MCP. Le paquet fournit des informations de typage (py.typed).
• Davantage d'exemples exécutables : AG2, DSPy, LangChain.js, Mastra, OpenAI Agents SDK (JavaScript), Vercel AI SDK, smolagents et Semantic Kernel.
• Les erreurs du coffre, du trousseau et de connect disent désormais ce qui s'est passé et une étape suivante, en termes simples. Le détail technique n'apparaît qu'avec ZN_VERBOSE=1 ou DEBUG=zn ; DEBUG=* ne l'active plus. zn unlock et zn vault status affichent l'heure de verrouillage du coffre à votre heure locale, et zn-gate -v affiche la version dans le paquet Python. Les serveurs MCP locaux de zn prennent en charge les versions du protocole jusqu'à 2025-11-25 et les descriptions de leurs outils disent quand les appeler. Le paquet npm est plus léger : environ 1,0 Mo à télécharger au lieu de 1,6 Mo.

• zn audit signale un fichier d'instructions contenant une suite de 40 lignes vides ou plus suivie d'autre texte (nouvelle règle ZNA021, moyenne), car ce texte échappe à la vue de qui relit. Les règles locales lisent aussi une longue suite de lignes vides comme une seule, si bien que le texte après le remplissage est contrôlé avec le texte qui le précède. zn audit ne signale plus un texte qui discute seulement de curl | sh comme d'un risque, ni un marqueur comme <system-or-project> dans les notes d'une skill.

Quoi d'autre a été corrigé ?

• Un prompt bloqué pour un secret nomme désormais l'identifiant lorsque le texte montre son nom, par exemple DB_PASSWORD. La valeur n'est jamais affichée.
• zn env shadow déplace dans le coffre une URL de connexion entière lorsque son mot de passe est court.
• OpenCode sous Windows avec PowerShell comme shell enveloppe correctement une commande contenant un marqueur __ZN_NAME__.
• Le journal de preuves ne perd plus d'enregistrement lorsque plusieurs programmes écrivent en même temps, y compris sous Windows.
• --help fonctionne sur zn unlock, zn lock, zn vault et zn team. Pour zn hooks, zn secret et zn env, demandez-la à une sous-commande : zn hooks install --help, zn secret set --help et zn env shadow --help.
• Un serveur MCP lent ou bloqué ne retarde plus vos autres serveurs, et un serveur WebSocket mort est reconnecté.
• Une commande qui contient plusieurs pipes Base64 (echo ... | base64 -d) est désormais vérifiée pipe par pipe. Avant, seul le premier était décodé : un premier pipe inoffensif pouvait donc cacher une commande bloquée dans un pipe suivant. Plus de 16 pipes, ou plus de 128 Kio de données décodées, sont bloqués.
• Le hook d'Antigravity répond désormais avec les étapes de réparation quand Node.js est absent ou que le hook ne peut pas démarrer : installez zn-gate et relancez zn hooks install antigravity. Avant, Antigravity ne recevait aucune réponse exploitable.
• Le shield MCP vérifie les clés du contenu structuré d'un serveur comme ses valeurs : une instruction placée dans une clé n'arrive donc plus jusqu'à l'agent.
• Antigravity : le hook bloque désormais les écritures dans un fichier .env qui contient des secrets en clair, comme l'indique la documentation, et demande avant une recherche shell récursive (grep -r, rg) dans un dossier qui en contient un. Sous Windows, il démarre désormais : la commande du hook ne dépend plus de guillemets, qu'Antigravity n'utilise pas, si bien qu'un chemin Node.js contenant des espaces ne le casse plus. Relancez zn hooks install antigravity pour remplacer un hook existant.
• Passerelle expérimentale : une action déjà refusée n'est plus approuvée, une approbation ne peut servir qu'une fois et un bannissement dure jusqu'à son expiration. Les approbations en attente expirent par défaut après 15 minutes, et un message WebSocket de plus de 1 Mio ferme la connexion par défaut. Avec AWS KMS, elle garde la même clé de données d'un redémarrage à l'autre, et refuse de démarrer, sauf si vous autorisez un repli, lorsque la clé KMS ne peut pas être récupérée. Son scrubber correspond désormais à celui de Node.js pour les membres JSON, les en-têtes Authorization et les numéros de carte qui suivent un candidat rejeté.
• zn-gate scan lit désormais les dossiers test, tests et __tests__ dans les deux paquets, car les jeux de test peuvent contenir de vrais secrets, et les deux ignorent les mêmes dossiers. Le scan Python liste un dossier qu'il ne peut pas lire, comme le fait celui de Node.js, et les chemins restent propres lorsque le dossier analysé est atteint par un lien.

Une version chaque semaine

À partir de la 1.14, zn-gate suit un rythme hebdomadaire : une version plus importante chaque semaine au lieu de nombreuses petites. Une version candidate sort quelques jours avant chaque version (tag npm next et pré-version PyPI), ce qui vous permet de l'essayer en avance. Nous ne publions en dehors de ce rythme que pour une correction de sécurité haute ou critique ou une installation cassée.

À l'horizon

• Demander confirmation avant qu'un agent ne modifie sa propre mémoire et ses fichiers d'instructions (CLAUDE.md, AGENTS.md, skills).
• Détecter les instructions cachées dans des commentaires HTML au sein des skills et des documents.
• ZCode testé de bout en bout sur macOS, et Antigravity sur Windows et macOS.
• Les mêmes règles de commandes dans le moteur Rust que dans les paquets Node et Python.

Questions fréquentes

Quoi de neuf dans zn-gate 1.14.0 ?

Des hooks pour Google Antigravity et l'application de bureau ZCode, désormais des agents pris en charge, et des hooks expérimentaux pour Gemini CLI et GitHub Copilot CLI. Plus de contrôles pour Codex CLI (appels d'outils MCP, demandes d'autorisation et réponse finale). zn-gate scan et zn audit trouvent les clés et mots de passe écrits en clair dans les configurations de serveurs MCP. Correctifs du vault et de zn Team : un marqueur de secret dans les arguments d'une commande n'est plus rempli, les approbations suivent la valeur pour laquelle elles ont été données, et la synchronisation des politiques zn Team est plus stricte. Un correctif du garde d'outils Python, qui laissait passer les valeurs imbriquées sur plus de huit niveaux environ. Un garde d'outils et des types TypeScript pour le paquet Node.js, zn vault reset, zn team managed-config et des exemples pour CrewAI, LlamaIndex, l'OpenAI Agents SDK, Pydantic AI, Google ADK et Haystack.

Comment mettre à jour vers zn-gate 1.14.0 ?

Sur npm, cette version est publiée sous le numéro 1.14.1 : exécutez npm install -g zn-gate@1.14.1 pour le paquet Node et pip install -U zn-gate pour le paquet Python. Relancez ensuite npx -y zn-gate@1.14.1 hooks install <agent> pour chaque agent que vous utilisez (par exemple hooks install codex) afin d'ajouter les nouveaux hooks ; npx -y zn-gate@1.14.1 check indique quels agents en ont besoin. Si vous utilisez le plugin Claude Code, lancez claude plugin update zn-gate@usezn et démarrez une nouvelle session ; il faut Claude Code 2.1.295 ou une version ultérieure.

Antigravity et l'application de bureau ZCode sont-ils pris en charge, et les hooks Gemini CLI et Copilot CLI sont-ils terminés ?

Antigravity et l'application de bureau ZCode sont des agents pris en charge, ce qui en fait six avec Claude Code, Codex CLI, Cursor et OpenCode. Leurs hooks bloquent la lecture et l'écriture de fichiers secrets par chemin et les commandes shell qui manipulent des secrets, mais ils ne peuvent pas réécrire la sortie des outils : les lignes correspondantes et la sortie des commandes n'y sont donc pas masquées. Un secret collé dans le prompt n'est pas bloqué dans Antigravity ; ZCode le bloque. ZCode ignore les hooks d'un projet, il n'a donc pas d'installation par projet. Testé de bout en bout sur l'application de bureau officielle ZCode 3.16.3 sous Linux x64 (octobre 2026). Les mêmes vérifications ont réussi sous Windows x64 (Windows Server 2022, même version de l'application, octobre 2026), pour un administrateur et pour un utilisateur standard, via l'agent fourni avec l'application ; la fenêtre de l'application Windows elle-même n'a pas été pilotée. macOS n'a pas été testé. Les hooks de Gemini CLI et de Copilot CLI sont expérimentaux : ceux de Gemini CLI ne peuvent pas demander de confirmation, ceux de Copilot CLI ne peuvent pas bloquer un prompt saisi, et Copilot laisse passer un appel quand un hook dépasse le délai : zn, qui fixe un délai de 15 secondes sur ses hooks, bloque donc lui-même l'appel à 11 secondes. zn-gate check indique si chaque hook est en place.

Dois-je changer quelque chose pour le vault et zn Team ?

Oui, dans deux cas. Si une commande que vous lancez avec zn run ou les hooks de l'agent contient un marqueur de secret comme __ZN_DB_PASSWORD__ dans ses arguments, elle est désormais refusée, car les arguments apparaissent dans la liste des processus et dans les journaux de ligne de commande : enregistrez le secret pour le programme (zn secret set PGPASSWORD --command psql) et lancez plutôt zn run --secrets PGPASSWORD -- psql. Et les approbations enregistrées par la 1.13.x et les versions antérieures ne comptent plus : zn redemande donc une fois, la première fois qu'une commande utilise chaque secret après la mise à jour. Rien d'autre n'est à changer.

Le correctif du garde d'outils Python me concerne-t-il ?

Il concerne le paquet Python, version 1.13.1 et antérieures, si vous utilisez le garde d'outils (guard, guarded_tool ou check_tool_call) sur des arguments ou des résultats qui peuvent être très imbriqués. Les valeurs imbriquées sur plus de huit niveaux environ passaient sans être contrôlées. Depuis la 1.14.0, elles sont bloquées avec le motif « nested too deeply to check ». Mettez à jour avec pip install -U zn-gate.

Ai-je besoin d'un compte pour utiliser zn-gate 1.14.0 ?

Non. zn-gate n'a toujours pas besoin de compte et n'envoie rien par défaut. La vérification optionnelle dans le cloud reste désactivée tant que vous n'exécutez pas zn-gate connect.

---

La liste complète des changements figure dans les notes de version 1.14.0. zn-gate est MIT, s'exécute en local et n'a pas besoin de compte : commencez avec npx -y zn-gate scan --include-home, ou consultez Installation pour chaque agent.