Política de seguridad
Nuestro compromiso con la transparencia, la coordinación de vulnerabilidades, el reconocimiento a los investigadores y una situación de cumplimiento honesta.
security.txt según la RFC 9116: /.well-known/security.txt
Salón de la fama de la seguridad
Reconocimientos a investigadoresAgradecemos sinceramente a los investigadores de seguridad independientes que han comunicado de forma responsable vulnerabilidades para ayudar a mantener segura zn y el ecosistema de IA.
Fallo de autorización en el plano de control de los manejadores de políticas y consenso
Se descubrió que los endpoints del plano de control (/api/v1/policies* y /api/v1/consensus*) validaban la autenticación de la API del tenant, pero omitían las comprobaciones de autorización a nivel de función, lo que permitía que claves de tenant sin rol de administrador modificaran políticas o el estado del consenso. La corrección aplicó comprobaciones estrictas del rol SuperAdmin y la verificación de los testigos del consenso.
Revocación insuficiente de sesiones y tokens al restablecer la contraseña (CWE-613)
Se detectó que cambiar o restablecer la contraseña de una cuenta no invalidaba las autorizaciones activas, los refresh tokens ni las sesiones simultáneas del navegador. La corrección implementó la revocación inmediata en el servidor de las autorizaciones y los refresh tokens de Auth0 en los eventos de restablecimiento de contraseña, el cierre de sesión en los dispositivos existentes y la reducción de la vida útil de los access tokens.
Revocación de sesión incompleta al cambiar la contraseña (seguimiento de CWE-613)
Se detectó de forma independiente que cambiar la contraseña de la cuenta no invalidaba de inmediato las demás sesiones activas del navegador: los access tokens emitidos seguían siendo válidos hasta caducar, aunque las concesiones de refresh token estaban revocadas. La corrección añadió una época de revocación por usuario que la API comprueba en cada petición, de modo que los tokens emitidos antes de un cambio de credenciales se rechazan al instante; redujo la vida útil del access token de 24 horas a 15 minutos; extendió la misma revocación al flujo de restablecimiento de contraseña; y añadió el control “Cerrar sesión en todos los dispositivos” y el cierre de sesión automático cuando se rechaza una sesión.
Refuerzo del flujo de cierre de sesión (redirecciones al salir y gestión de errores)
Se detectó que el flujo global de cierre de sesión dependía de un destino posterior al cierre que no estaba registrado entre las URL de cierre de sesión permitidas del proveedor de identidad, lo que mostraba una página de error sin marca y exponía la configuración interna. La corrección sustituyó los errores sin procesar del proveedor de identidad por una página de error con la marca, añadió un aviso de “sesión caducada” para los cierres de sesión entre dispositivos, registró los destinos de cierre de sesión legítimos como defensa en profundidad y completó la migración a un dominio de autenticación propio.
Las entradas usan el formato SEC-YYYY-NN y son permanentes: nunca eliminamos a un investigador acreditado. Si prefieres permanecer en el anonimato, podemos publicar el informe sin tu nombre de usuario.
Avisos de seguridad
Hallazgos propiosProblemas en el software que distribuimos, publicados con el mismo detalle que pedimos a los investigadores: qué ocurrió, quién se ve afectado y qué hacer.
zn-gate para Node.js anterior a 1.6.0: un agente podía ejecutar comandos de administración de zn mediante una llamada de paquete con versión, saltándose el hook que los deniega
Los hooks del agente deniegan a los agentes de IA los comandos que gestionan tus secretos y tu protección, como zn unlock, zn lock, zn secret set, zn env shadow y zn hooks uninstall. Desde la 1.5.0-beta.1 hasta la 1.6.0-beta.1, el hook no reconocía estos comandos cuando se escribían como llamada de paquete con versión, por ejemplo npx -y zn-gate@1.5.1 hooks uninstall, así que los dejaba pasar. La mayoría de estos comandos también se niegan a ejecutarse cuando el entorno indica que hay un agente de programación o cuando no hay una terminal interactiva; zn lock no tiene esa comprobación, así que cualquier agente podría bloquear la bóveda (esto no revela secretos). No se ven afectados el paquete de Python, el enmascaramiento de secretos en la entrada y la salida de las herramientas ni la lectura de valores secretos. Corregido en zn-gate 1.6.0, que deniega las formas con versión con npx, pnpm dlx y bunx igual que el comando simple. Actualiza con npm install -g zn-gate@1.6.0 (o actualiza el plugin del agente); mientras no puedas hacerlo, mantén los comandos de tu agente fuera de una terminal interactiva, revisa cualquier aviso de zn que no esperabas y, si se eliminaron los hooks del agente, vuelve a instalarlos con zn hooks install desde tu propia terminal.
zn-gate 1.5.0 y anteriores para Node.js en Windows: zn run podía entregar secretos a un programa elegido a través del entorno
En Windows, cuando zn run pasaba secretos almacenados a un archivo por lotes aprobado (.cmd o .bat, como una CLI instalada con npm), lo iniciaba a través del intérprete de comandos indicado en la variable de entorno ComSpec. Un proceso capaz de modificar esa variable, como un agente de IA en una sesión en la que hubieras aprobado el archivo por lotes, podía apuntarla a otro programa, que entonces recibía los valores secretos. Este problema no afecta a macOS ni a Linux, a los programas de Windows que son archivos .exe, al paquete de Python ni al enmascaramiento de la entrada y la salida de las herramientas en los hooks. Corregido en zn-gate 1.5.1, que siempre inicia los archivos por lotes a través de cmd.exe del sistema; en todas las plataformas también deja de pasar a un programa que recibe secretos los ajustes de arranque del intérprete, como NODE_OPTIONS, heredados del entorno del llamador. Actualiza con npm install -g zn-gate@1.5.1 (o la versión que fije el plugin de tu agente); mientras no puedas actualizar, no apruebes programas .cmd o .bat para secretos en zn run, y para las API HTTP usa la herramienta MCP secrets_http_request.
zn-gate 1.4.0 y anteriores enviaban la salida de las herramientas y los argumentos de sus llamadas a api.usezn.com sin enmascarar cuando ZN_API_KEY estaba definida
Detectado durante una revisión interna del paquete publicado. Sin ZN_API_KEY no salía nada de la máquina. Corregido en zn-gate 1.4.1: la salida de las herramientas y los argumentos de sus llamadas se evalúan solo en local, el análisis en la nube es opcional (ZN_CLOUD=1), solo se envía el prompt y se enmascara antes de enviarlo. La API ya no almacena el texto de entrada, y el texto que tenía guardado se eliminó del servicio. Si ejecutaste la 1.4.0 o una anterior con una clave de API definida, actualiza y rota cualquier credencial que pudiera haber aparecido en la salida de las herramientas.
Registro de cambios de seguridad
Cada mejora de seguridad que publicamos, registrada públicamente. Correcciones, no exploits.
Política de divulgación responsable
Si crees haber descubierto una vulnerabilidad de seguridad en zn-gate, en la API en la nube de zn o en cualquier infraestructura de usezn.com, notifícala directamente a nuestro equipo de seguridad. Tomamos en serio todas las divulgaciones responsables y las investigamos con prontitud. Esta política sigue la RFC 9116 y coordina la divulgación con quien informa.
Incluye los pasos detallados para reproducir el problema, los scripts o las peticiones de prueba de concepto y los datos relevantes del entorno. Recomendamos encarecidamente probar en contenedores Docker locales o en cuentas de prueba aisladas.
Proceso de divulgación
- Informar — escribe a security@usezn.com con los pasos para reproducirlo, el impacto y una prueba de concepto. No accedas nunca a datos que no sean tuyos ni interrumpas los sistemas de producción.
- Acusar recibo — nuestro objetivo es una primera respuesta humana en un plazo de 24 horas.
- Triaje — nuestro objetivo es evaluar la validez y la gravedad en 48 horas, y te diremos si el informe es válido, duplicado o está fuera del alcance.
- Corregir — corregimos por orden de gravedad y te mantenemos informado del progreso.
- Coordinar la divulgación — el embargo predeterminado es de 90 días desde el informe, o el calendario que acordemos contigo. Apoyamos la redacción de avisos y la asignación de CVE, y te damos el reconocimiento público según tus preferencias.
Estos plazos son objetivos orientativos de un equipo pequeño, no un SLA contractual. Si dejamos de responder, seguimos trabajando en ello, y siempre eres bienvenido a recordárnoslo.
Compromiso de safe harbor
Consideramos autorizada la investigación de seguridad que se realiza de acuerdo con esta política. Si haces un esfuerzo de buena fe por cumplir la divulgación responsable (evitando el acceso a datos de usuarios, las interrupciones del servicio y las vulneraciones de la privacidad), nos comprometemos a:
- No iniciar ni perseguir acciones legales contra ti
- Trabajar contigo de forma transparente para validar y corregir el problema
- Coordinar el aviso público y la atribución según tus preferencias
- No considerar tu investigación una infracción de nuestras Condiciones del servicio ni de nuestra política de uso aceptable
Alcance
Dentro del alcance
- zn-gate (código abierto): servidor MCP, CLI, enmascaramiento de secretos y registro de auditoría local
- Endpoints de la API en la nube (
api.usezn.com) - SDK de cliente (
zn-gateNPM/PyPI) - Mecanismos de autenticación y control de acceso
- Elusiones de jailbreak del modelo contra
/v30/analyze - La aplicación web de usezn.com y el panel de clientes
- Integridad, exportación y controles de retención de la bóveda de evidencias
- Flujos de integración de facturación de Auth0 y Polar
Fuera del alcance
- Ataques de denegación de servicio (DoS/DDoS)
- Ingeniería social o phishing dirigido al personal de zn
- Servicios de terceros que alojan nuestros activos (p. ej., AWS, Cloudflare)
- Spam de escáneres automáticos sin una prueba de concepto accionable
- Cabeceras de endurecimiento ausentes o buenas prácticas sin un impacto de seguridad demostrable
- Hallazgos que requieren acceso físico o un dispositivo de usuario final comprometido
Reconocimiento y recompensas
Valoramos el esfuerzo necesario para identificar fallos de seguridad. Para las vulnerabilidades que cumplan los requisitos, ofrecemos:
- Atribución pública: inclusión permanente en nuestro Salón de la fama de la seguridad y en las notas de la versión.
- Suscripciones a la plataforma: los investigadores que cumplan los requisitos pueden recibir 6 meses gratis del plan Scale (2.000.000 de llamadas al mes) para uso personal o de investigación.
- Colaboración directa en los avisos: coordinación completa sobre el momento de la divulgación, los borradores de aviso y la asignación de CVE.
Actualmente no tenemos un programa de recompensas por fallos de pago. No prometemos dinero que no podamos pagar: somos un equipo pequeño, y las recompensas son discrecionales y se centran en la atribución, el acceso a la plataforma y la colaboración. Si llegara a haber una recompensa monetaria, la publicaremos aquí primero.
Tratamiento y conservación de datos
Cero retención de datos: todos los planes (Free, Pro, Scale y Team) evalúan la entrada fuera del Modo colaborador en memoria volátil y la descartan tras el veredicto; solo se conservan los metadatos de la decisión que se indican más abajo. Los planes de pago nunca entrenan modelos con datos de clientes.
Modo colaborador (opcional): el Modo colaborador, que se ofrece con algunas becas para startups e investigación, es la única opción que comparte datos para la investigación, y la eliges tú. En ese modo, un extracto depurado de cada entrada analizada (los primeros 1.000 caracteres, con los correos, los tokens de portador, las claves de API y las cadenas hexadecimales largas enmascarados automáticamente) se guarda con su registro de evidencia durante hasta 90 días y se usa para mejorar los modelos de detección de zn. El enmascaramiento automático no detecta todos los datos personales en texto libre.
Registros de evidencia: cada decisión genera un registro de evidencia con un ID aleatorio y metadatos (veredicto, confianza, regla, latencia, marca de tiempo y, desde el 12 de octubre de 2026 a las 12:24 UTC, un hash SHA-256 y el tamaño de la entrada, el prefijo de la clave de API y la familia de cliente). Fuera del Modo colaborador nunca contiene la entrada en sí. Las evidencias caducan automáticamente a los 90 días, se cifran en reposo (AES-256, cifrado gestionado por AWS) y se pueden exportar en CSV o JSON desde el panel. Las claves de API se guardan con hash y cifradas con AWS KMS.
Consulta todos los detalles en nuestra Política de privacidad.
Certificaciones y cumplimiento
Preferimos ser precisos antes que impresionantes. Esta es nuestra situación real hoy:
- SOC 2 / ISO: zn no tiene hoy certificaciones SOC 2 ni ISO 27001/42001.
- Infraestructura: funcionamos en AWS, cuyos centros de datos tienen certificaciones SOC 2 Type II e ISO 27001.
- Hoja de ruta: una auditoría SOC 2 Type II comenzará con nuestro primer contrato empresarial; el trabajo de preparación para ISO 27001 e ISO 42001 está en la hoja de ruta.
- Exportaciones para auditoría: los registros de evidencia por decisión se pueden exportar (CSV o JSON) para apoyar la conservación de registros de los clientes. El paquete local zn-gate además mantiene en tu propia máquina un registro encadenado por hash.
- Sin SLA de disponibilidad: supervisamos internamente con alarmas de AWS CloudWatch, pero no publicamos un monitor de disponibilidad en tiempo real ni prometemos un SLA público de disponibilidad. Consulta la página de estado.
Procedencia de los modelos
- Galvanize 2 es el modelo que hay detrás de la comprobación opcional en la nube. Está ajustado a partir de Horizon-Labs/prompt-injection-guard-small (Apache-2.0) y publicado bajo Apache-2.0. Descripción general: Galvanize 2; ficha del modelo y pesos: usezn/Galvanize-2. Scripts y resultados del benchmark: usezn/Galvanize-2/benchmark.
- Galvanize-60M, el modelo anterior, es el respaldo automático cuando Galvanize 2 no está disponible. Ficha del modelo y pesos: usezn/Galvanize-60M (Apache-2.0).
Subencargados y DPA
Trabajamos con un pequeño conjunto de subencargados evaluados: AWS (alojamiento y almacenamiento), Auth0 (autenticación), Polar (pagos y Merchant of Record), y Amazon SES (correo transaccional).
La lista completa, las finalidades y las garantías para las transferencias están en nuestra página DPA y subencargados. Los clientes pueden formalizar un contrato de encargo del tratamiento (DPA) si lo solicitan: escríbenos a hello@usezn.com.