zn-gate 1.4.1 y lo que sale de tu máquina

John Silver4 min de lectura

Por defecto, nada sale de tu máquina. Si activas la comprobación en la nube, solo se envía el prompt, con los secretos eliminados antes; la salida de las herramientas nunca se envía. Para los usuarios de zn-gate 1.4.0 que habían configurado ZN_API_KEY, esa promesa no se cumplía. Este artículo explica qué hacía el paquete, qué almacenaba nuestra API, qué cambiamos en la 1.4.1 y qué debes hacer. En resumen: actualiza y, si ejecutaste la 1.4.0 con una clave de API, rota cualquier credencial que pudiera haber aparecido en la salida de una herramienta.

Qué hacía la 1.4.0

zn-gate revisa tres tipos de texto: los prompts, los argumentos de las llamadas a herramientas y los resultados de las herramientas (el contenido de los archivos que lee tu agente y la salida de los comandos que ejecuta). Las reglas locales evaluaban primero los tres. En la 1.4.0 y anteriores, si las reglas locales no bloqueaban el texto y ZN_API_KEY estaba configurada, el paquete de Node enviaba ese texto a api.usezn.com para una segunda opinión del clasificador Galvanize-60M. Lo hacía sin redactar los secretos, y lo hacía para los resultados y los argumentos de las herramientas, no solo para los prompts.

El README decía que el paquete era local primero y que se aplicaba ocultación de secretos. La función de ocultación existía en el código, pero ninguna ruta de ejecución la llamaba. Lo encontramos en una revisión interna del paquete publicado el 2026-10-11.

Quién está afectado:

  • Usuarios del paquete npm (el servidor MCP, zn-gate shield, zn-gate analyze, zn-gate test o la librería) con ZN_API_KEY configurada y ZN_LOCAL_ONLY sin el valor true.
  • Usuarios del paquete de Python con ZN_API_KEY configurada: solo analyze() y zn-gate analyze enviaban texto, sin redactar. guard, check_tool_call, check_tool_result, sanitize_tool_result y las integraciones con frameworks siempre fueron locales.
  • Los usuarios que nunca configuraron ZN_API_KEY, o que configuraron ZN_LOCAL_ONLY=true, no se ven afectados. Nada salía de la máquina.

Qué almacenaba nuestra API

El texto viajaba por TLS y el clasificador lo evaluaba. Dos rutas además guardaban los primeros 1.000 caracteres de cada entrada en nuestra tabla de evidencias, sin caducidad: la ruta heredada /prod/analyze y la ruta analyze de MCP. La ruta actual /v30/analyze, que zn-gate usa por defecto, no almacenaba la entrada para los planes de pago; solo guardaba una copia redactada y truncada para el plan gratuito Contributor, que lo acepta. Los registros de acceso guardan únicamente la ruta y el estado, nunca el contenido.

El 2026-10-11 cambiamos la API para guardar solo un hash SHA-256 y la longitud de la entrada, y borramos el texto almacenado de la tabla de evidencias en cada registro que lo tenía: 1.281 registros, con fechas entre el 22 de agosto y el 12 de septiembre de 2026.

Qué cambia la 1.4.1

  • Los resultados de las herramientas, los argumentos de las llamadas y las descripciones de las herramientas se evalúan solo en local, con cualquier configuración: servidor MCP, proxy shield y librería.
  • La nube es opcional. El análisis de prompts consulta la nube solo si configuras ZN_CLOUD=1 y ZN_API_KEY. ZN_API_KEY por sí sola no activa nada. ZN_LOCAL_ONLY=true sigue anulándolo todo.
  • La ocultación se ejecuta en la ruta de código real. check_tool_result devuelve siempre el contenido pasado por el redactor de secretos; check_tool_call devuelve los argumentos saneados; shield reenvía la salida de las herramientas con los secretos redactados. Cuando la nube está activada, el texto del prompt pasa por el redactor antes de enviarse.
  • zn-gate status muestra qué envía tu configuración, y la autocomprobación nunca usa la red.
  • Los nuevos tests simulan la red y cuentan las peticiones: la salida de una herramienta con secretos falsos vuelve redactada y no hace ninguna petición, incluso con ZN_API_KEY y ZN_CLOUD=1 configuradas. Frente al código de la 1.4.0, siete de esos ocho tests fallan.

El README incluye ahora una tabla "What leaves your machine" (qué sale de tu máquina) en los tres paquetes, y la misma tabla está en esta web.

Qué debes hacer

  1. Actualiza: npx -y zn-gate@latest (o npm install -g zn-gate@1.4.1) y pip install -U zn-gate.
  2. Si ejecutaste la 1.4.0 o una anterior con ZN_API_KEY configurada, supón que cualquier credencial que apareciera en la salida o en los argumentos de una herramienta durante ese periodo pudo haberse transmitido, y rótala.
  3. Ejecuta npx -y zn-gate status para ver qué envía tu configuración ahora.

El aviso está publicado en GitHub como GHSA-r4h2-qcf2-8227, con la lista completa de rutas de código afectadas en el changelog de la 1.4.1.

Por qué lo explicamos

Nadie nos lo reportó; lo encontramos nosotros. Podríamos haber publicado la 1.4.1 con una línea en el changelog. Publicamos los detalles porque todo el sentido de zn-gate es que puedas confiar en lo que hace con tus datos, y esa confianza tiene que sobrevivir a los días en que nos equivocamos. Si tienes preguntas, o crees que algo de aquí todavía no es lo bastante preciso, escribe a security@usezn.com.

— John Silver

Actualizado el 14 de octubre de 2026: el texto sobre tratamiento de datos se ha reformulado para describir lo que hacen hoy el paquete y la API.

Share