Politique de sécurité
Notre engagement en faveur de la transparence, de la coordination des vulnérabilités, de la reconnaissance des chercheurs et d’une posture de conformité honnête.
security.txt selon la RFC 9116 : /.well-known/security.txt
Panthéon de la sécurité
Remerciements aux chercheursNous remercions sincèrement les chercheurs indépendants en sécurité qui ont signalé de façon responsable des vulnérabilités pour contribuer à la sécurité de zn et de l’écosystème de l’IA.
Faille d’autorisation dans le plan de contrôle des gestionnaires de politiques et de consensus
Il a été constaté que les points de terminaison du plan de contrôle (/api/v1/policies* et /api/v1/consensus*) validaient l’authentification par clé d’API du locataire, mais omettaient les contrôles d’autorisation au niveau des fonctions, ce qui permettait à des clés de locataire non administratrices de modifier les politiques ou l’état du consensus. La correction a imposé des contrôles stricts du rôle SuperAdmin et la vérification des témoins du consensus.
Révocation insuffisante des sessions et des jetons lors de la réinitialisation du mot de passe (CWE-613)
Il a été constaté que la modification ou la réinitialisation du mot de passe d’un compte n’invalidait pas les autorisations actives existantes, les jetons d’actualisation ni les sessions de navigateur simultanées. La correction a mis en place la révocation immédiate côté serveur des autorisations et jetons d’actualisation Auth0 lors des réinitialisations de mot de passe, la fin des sessions sur les appareils existants et la réduction de la durée de vie des jetons d’accès.
Révocation de session incomplète lors du changement de mot de passe (suite de CWE-613)
Il a été constaté de façon indépendante que la modification du mot de passe du compte n’invalidait pas immédiatement les autres sessions de navigateur actives : les jetons d’accès déjà émis restaient valides jusqu’à leur expiration, même si les autorisations de jetons d’actualisation étaient révoquées. La correction a ajouté une époque de révocation par utilisateur, vérifiée par l’API à chaque requête, de sorte que les jetons émis avant un changement d’identifiants sont rejetés immédiatement ; elle a réduit la durée de vie des jetons d’accès de 24 heures à 15 minutes, étendu la même révocation au flux de réinitialisation du mot de passe, et ajouté la commande « Se déconnecter de tous les appareils » ainsi qu’une déconnexion automatique lorsqu’une session est rejetée.
Renforcement du flux de fin de session (redirections de déconnexion et gestion des erreurs)
Il a été constaté que le flux de déconnexion globale reposait sur une destination post-déconnexion non enregistrée parmi les URL de déconnexion autorisées du fournisseur d’identité, ce qui affichait une page d’erreur sans marque et exposait la configuration interne. La correction a remplacé les erreurs brutes du fournisseur d’identité par une page d’erreur aux couleurs de la marque, ajouté un avis « session expirée » pour les déconnexions entre appareils, enregistré les destinations de déconnexion légitimes en tant que défense en profondeur, et achevé la migration vers un domaine d’authentification propre.
Les entrées suivent le format SEC-YYYY-NN et sont permanentes : nous ne retirons jamais un chercheur crédité. Si vous préférez rester anonyme, nous pouvons publier le rapport sans votre identifiant.
Avis de sécurité
Nos propres constatsProblèmes concernant les logiciels que nous distribuons, publiés avec le même niveau de détail que celui que nous demandons aux chercheurs : ce qui s’est passé, qui est concerné et que faire.
zn-gate pour Node.js avant la 1.6.0 : un agent pouvait exécuter des commandes d’administration zn via un appel de paquet versionné, contournant le hook qui les bloque
Les hooks d’agent refusent aux agents d’IA les commandes qui gèrent vos secrets et votre protection, comme zn unlock, zn lock, zn secret set, zn env shadow et zn hooks uninstall. De la 1.5.0-beta.1 à la 1.6.0-beta.1, le hook ne reconnaissait pas ces commandes lorsqu’elles étaient écrites sous forme d’appel de paquet versionné, par exemple npx -y zn-gate@1.5.1 hooks uninstall, et les laissait donc passer. La plupart de ces commandes refusent aussi de s’exécuter lorsque l’environnement indique un agent de programmation ou lorsqu’il n’y a pas de terminal interactif ; zn lock n’a pas une telle vérification, donc n’importe quel agent pouvait verrouiller le coffre (cela ne révèle aucun secret). Ne sont pas concernés : le paquet Python, le masquage des secrets dans l’entrée et la sortie des outils, ni la lecture des valeurs secrètes. Corrigé dans zn-gate 1.6.0, qui refuse les formes versionnées avec npx, pnpm dlx et bunx comme la commande simple. Mettez à jour avec npm install -g zn-gate@1.6.0 (ou mettez à jour le plugin de votre agent) ; en attendant, gardez les commandes de votre agent hors d’un terminal interactif, examinez tout message de zn que vous n’attendiez pas et, si les hooks de l’agent ont été supprimés, réinstallez-les avec zn hooks install depuis votre propre terminal.
zn-gate 1.5.0 et antérieures pour Node.js sous Windows : zn run pouvait transmettre des secrets à un programme choisi via l’environnement
Sous Windows, lorsque zn run transmettait des secrets enregistrés à un fichier batch approuvé (.cmd ou .bat, comme une CLI installée avec npm), il lançait le fichier via l’interpréteur de commandes désigné par la variable d’environnement ComSpec. Un processus capable de modifier cette variable, comme un agent d’IA dans une session où vous aviez approuvé le fichier batch, pouvait la faire pointer vers un autre programme, qui recevait alors les valeurs secrètes. Ne sont pas concernés : macOS et Linux, les programmes Windows qui sont des fichiers .exe, le paquet Python, ni le masquage de l’entrée et de la sortie des outils par les hooks. Corrigé dans zn-gate 1.5.1, qui lance toujours les fichiers batch via le cmd.exe du système ; sur toutes les plateformes, il ne transmet plus non plus à un programme qui reçoit des secrets les réglages de démarrage de l’interpréteur, comme NODE_OPTIONS, hérités de l’environnement de l’appelant. Mettez à jour avec npm install -g zn-gate@1.5.1 (ou la version épinglée par le plugin de votre agent) ; en attendant, n’approuvez pas de programmes .cmd ou .bat pour les secrets dans zn run, et pour les API HTTP, utilisez l’outil MCP secrets_http_request.
zn-gate 1.4.0 et antérieures envoyaient la sortie des outils et les arguments d’appel à api.usezn.com sans masquage lorsque ZN_API_KEY était défini
Constaté lors d’un examen interne du paquet publié. Sans ZN_API_KEY, rien ne quittait la machine. Corrigé dans zn-gate 1.4.1 : la sortie des outils et les arguments d’appel ne sont évalués qu’en local, l’analyse dans le cloud est facultative (ZN_CLOUD=1), seul le prompt est envoyé, et masqué avant l’envoi. L’API ne conserve plus le texte saisi, et le texte précédemment conservé a été supprimé du service. Si vous avez utilisé la 1.4.0 ou une version antérieure avec une clé d’API définie, mettez à jour et renouvelez tout identifiant susceptible d’être apparu dans la sortie des outils.
Journal des modifications de sécurité
Chaque amélioration de sécurité que nous publions, consignée publiquement. Des correctifs, pas des exploits.
Politique de divulgation responsable
Si vous pensez avoir découvert une vulnérabilité de sécurité dans zn-gate, dans l’API cloud de zn ou dans toute infrastructure usezn.com, signalez-la directement à notre équipe de sécurité. Nous prenons toutes les divulgations responsables au sérieux et les examinons rapidement. Cette politique suit la RFC 9116 et coordonne la divulgation avec la personne qui la signale.
Veuillez inclure les étapes détaillées pour reproduire le problème, les scripts ou requêtes de preuve de concept, et les éléments pertinents de l’environnement. Il est fortement recommandé de tester sur des conteneurs Docker locaux ou des comptes de test isolés.
Processus de divulgation
- Signaler — écrivez à security@usezn.com avec les étapes de reproduction, l’impact et une preuve de concept. N’accédez jamais à des données qui ne vous appartiennent pas et ne perturbez jamais les systèmes de production.
- Accuser réception — nous visons une première réponse humaine sous 24 heures.
- Trier — nous visons une évaluation de la validité et de la gravité sous 48 heures, et nous vous indiquerons si le rapport est valide, un doublon ou hors périmètre.
- Corriger — nous corrigeons par ordre de priorité selon la gravité et vous tenons informé de l’avancement.
- Coordonner la divulgation — le délai d’embargo par défaut est de 90 jours à compter du rapport, ou le calendrier convenu avec vous. Nous accompagnons la rédaction des avis et l’attribution de CVE, et nous vous créditons publiquement selon vos préférences.
Ces délais sont des objectifs indicatifs d’une petite équipe, et non un SLA contractuel. Si nous restons silencieux, nous continuons de travailler dessus, et vous êtes toujours invité à nous relancer.
Engagement de safe harbor
Nous considérons que la recherche en sécurité menée conformément à cette politique est autorisée. Si vous faites un effort de bonne foi pour respecter la divulgation responsable (en évitant l’accès aux données des utilisateurs, les interruptions de service et les atteintes à la vie privée), nous nous engageons à :
- Ne pas engager ni poursuivre de procédure judiciaire contre vous
- Travailler avec vous en toute transparence pour valider et corriger le problème
- Coordonner l’avis public et l’attribution selon vos préférences
- Ne pas considérer vos recherches comme une violation de nos Conditions d’utilisation ou de notre politique d’utilisation acceptable
Périmètre
Dans le périmètre
- zn-gate (open source) : serveur MCP, CLI, masquage des secrets et journal d’audit local
- Points de terminaison de l’API cloud (
api.usezn.com) - SDK clients (
zn-gateNPM/PyPI) - Mécanismes d’authentification et de contrôle d’accès
- Contournements de jailbreak du modèle contre
/v30/analyze - L’application web usezn.com et le tableau de bord client
- Intégrité, export et contrôles de conservation du coffre de preuves
- Flux d’intégration de facturation Auth0 et Polar
Hors périmètre
- Attaques par déni de service (DoS/DDoS)
- Ingénierie sociale ou hameçonnage visant le personnel de zn
- Services tiers hébergeant nos actifs (p. ex. AWS, Cloudflare)
- Spam de scanners automatisés sans preuve de concept exploitable
- En-têtes de durcissement manquants ou bonnes pratiques sans impact de sécurité démontrable
- Constats nécessitant un accès physique ou un appareil d’utilisateur compromis
Reconnaissance et récompenses
Nous savons reconnaître l’effort nécessaire pour identifier des failles de sécurité. Pour les vulnérabilités admissibles, nous proposons :
- Attribution publique : inscription permanente dans notre Panthéon de la sécurité et dans les notes de version.
- Abonnements à la plateforme : les chercheurs admissibles peuvent bénéficier de 6 mois gratuits de l’offre Scale (2 000 000 d’appels par mois) pour un usage personnel ou de recherche.
- Collaboration directe sur les avis : coordination complète sur le calendrier de divulgation, les projets d’avis et l’attribution de CVE.
Nous n’avons pas actuellement de programme de primes payantes. Nous ne promettons pas d’argent que nous ne pourrions pas verser : nous sommes une petite équipe, et les récompenses sont discrétionnaires et axées sur l’attribution, l’accès à la plateforme et la collaboration. Si une prime monétaire devient disponible, elle sera d’abord publiée ici.
Traitement et conservation des données
Zéro conservation des données : chaque offre (Free, Pro, Scale et Team) évalue l’entrée hors Mode contributeur en mémoire volatile et la supprime après le verdict ; seules les métadonnées de décision ci-dessous sont conservées. Les offres payantes n’entraînent jamais de modèles sur les données des clients.
Mode contributeur (facultatif) : le Mode contributeur, proposé avec certaines subventions pour startups et pour la recherche, est la seule option qui partage des données à des fins de recherche, et c’est vous qui la choisissez. Dans ce mode, un extrait épuré de chaque entrée analysée (les 1 000 premiers caractères, avec masquage automatique des adresses e-mail, des jetons porteurs, des clés d’API et des longues chaînes hexadécimales) est conservé avec son enregistrement de preuve pendant 90 jours au plus et sert à améliorer les modèles de détection de zn. Le masquage automatique ne détecte pas toutes les données personnelles présentes dans un texte libre.
Enregistrements de preuves : chaque décision produit un enregistrement de preuve avec un identifiant aléatoire et des métadonnées (verdict, confiance, règle, latence, horodatage et, depuis le 12 octobre 2026 à 12 h 24 UTC, un hachage SHA-256 et la taille de l’entrée, le préfixe de la clé d’API et la famille de client). Hors Mode contributeur, il ne contient jamais l’entrée elle-même. Les preuves expirent automatiquement au bout de 90 jours, sont chiffrées au repos (AES-256, chiffrement géré par AWS) et peuvent être exportées en CSV ou en JSON depuis le tableau de bord. Les clés d’API sont stockées sous forme de hachage et chiffrées avec AWS KMS.
Retrouvez tous les détails dans notre Politique de confidentialité.
Certifications et conformité
Nous préférons être précis plutôt qu’impressionnants. Voici notre situation réelle aujourd’hui :
- SOC 2 / ISO : zn ne détient aujourd’hui aucune certification SOC 2 ni ISO 27001/42001.
- Infrastructure : nous fonctionnons sur AWS, dont les centres de données sont certifiés SOC 2 Type II et ISO 27001.
- Feuille de route : une mission SOC 2 Type II sera engagée avec notre premier contrat entreprise ; les travaux de préparation à ISO 27001 et ISO 42001 figurent à la feuille de route.
- Exports pour audit : les enregistrements de preuves par décision peuvent être exportés (CSV ou JSON) pour appuyer la tenue des registres des clients. Le paquet local zn-gate conserve en outre, sur votre propre machine, un journal chaîné par hachage.
- Aucun SLA de disponibilité : nous surveillons en interne avec les alarmes AWS CloudWatch, mais nous ne publions pas de moniteur de disponibilité en temps réel et ne promettons pas de SLA public de disponibilité. Consultez la page d’état.
Provenance des modèles
- Galvanize 2 est le modèle qui sous-tend la vérification cloud facultative. Il est affiné à partir de Horizon-Labs/prompt-injection-guard-small (Apache-2.0) et publié sous licence Apache-2.0. Présentation : Galvanize 2 ; fiche du modèle et poids : usezn/Galvanize-2. Scripts et résultats du benchmark : usezn/Galvanize-2/benchmark.
- Galvanize-60M, le modèle précédent, sert de solution de repli automatique lorsque Galvanize 2 est indisponible. Fiche du modèle et poids : usezn/Galvanize-60M (Apache-2.0).
Sous-traitants et DPA
Nous nous appuyons sur un petit ensemble de sous-traitants sélectionnés : AWS (hébergement et stockage), Auth0 (authentification), Polar (paiements et Merchant of Record), et Amazon SES (e-mails transactionnels).
La liste complète, les finalités et les garanties de transfert figurent sur notre page DPA et sous-traitants. Les clients peuvent signer un accord de traitement des données (DPA) sur demande : écrivez-nous à hello@usezn.com.