La carga del historial de Git de ZCode convierte una comodidad de programación en un problema de confianza
ZCode supuestamente cargó un espacio de trabajo completo de un desarrollador de 345 MB, incluido su historial de Git, pese a configuraciones que aparentemente limitaban la recopilación de datos. La carga reportada del historial de Git de ZCode no se limitó a los archivos seleccionados para un prompt de IA. Incluyó objetos de repositorio, reflogs y archivos grandes almacenados en caché que podrían conservar años de trabajo privado de ingeniería.
Una investigación técnica publicada el 18 de septiembre rastreó este comportamiento en la aplicación de escritorio cerrada de ZCode. Según ese análisis, el cliente creó puntos de control cifrados del espacio de trabajo y los transfirió a Alibaba Cloud Object Storage Service mientras el usuario tenía la sesión iniciada.
El hallazgo sigue siendo una afirmación de ingeniería inversa de terceros, no una divulgación auditada de forma independiente por Z.ai. En el momento de la publicación, los materiales oficiales disponibles no explicaban claramente el alcance de la carga reportada, la retención de los puntos de control ni cómo podían impedirla los usuarios.
Esa brecha de verificación forma parte de la historia. ZCode promociona modelos GLM con un agente diseñado para comprender un espacio de trabajo, ejecutar comandos y recuperar tareas de larga duración. Sin embargo, un modelo de pesos abiertos no vuelve transparente a la aplicación de escritorio que lo rodea.
Por lo tanto, el conflicto central no es ZCode frente a otro asistente de programación. Es el contraste entre los controles de privacidad visibles del producto y el comportamiento atribuido a su sistema oculto de puntos de control.
Lo que encontró el informe sobre la carga del historial de Git de ZCode
La investigación afirma que ZCode capturó un archivo completo del repositorio, no solo el código necesario para una solicitud de modelo.
El investigador examinó un espacio de trabajo comercial privado con 42.411 archivos. El directorio original ocupaba aproximadamente 345 MB, mientras que el punto de control cifrado de ZCode tenía unos 313 MB.
Los contenidos reportados fueron especialmente reveladores. Cerca de 196,1 MB procedían del directorio .git/lfs, donde Git Large File Storage puede almacenar en caché grandes activos del proyecto. Otros 102,2 MB procedían de .git/objects, la base de datos subyacente de Git para contenidos de archivos, árboles de directorios y commits.
Los reflogs añadían aproximadamente 0,6 MB. Los archivos fuente actuales, la configuración y la documentación representaban unos 46,2 MB, o el 13,4 por ciento del material medido.
En esa instantánea individual, el directorio .git representaba el 86,6 por ciento de los datos archivados. Esto no establece un promedio para todas las instalaciones de ZCode. Sí demuestra por qué calificar el evento como una carga rutinaria de código minimiza el alcance reportado.
El relato original indica que ZCode creó el punto de control en los datos locales de la aplicación y dejó un manifiesto en texto plano junto al archivo cifrado. Según se informa, ese manifiesto exponía la ruta absoluta del espacio de trabajo afectado.
Según la ingeniería inversa, ZCode solicitó credenciales de carga a un servicio de Z.ai. La respuesta incluía una clave de objeto, un formulario de carga firmado, un límite de tamaño y una clave pública RSA.
El cliente presuntamente comprimió el espacio de trabajo, lo cifró con AES-256-CTR y encapsuló la clave simétrica mediante RSA-OAEP-SHA256. Después publicó el objeto cifrado directamente en un endpoint de almacenamiento de Aliyun.
Según se informa, una devolución de llamada notificó al backend de Z.ai una vez completada la transferencia. Si esa reconstrucción es correcta, la carga fue un flujo de aplicación diseñado, en lugar de una solicitud de modelo accidental que contenía demasiado contexto.
El cifrado no resuelve el problema de divulgación. Protege los datos frente a observadores entre el ordenador y el servicio de almacenamiento, suponiendo que la implementación sea correcta. No impide que el operador previsto del servicio acceda a la información.
El informe afirma que la clave privada RSA correspondiente permanecía bajo control del servidor. En consecuencia, el usuario que proporcionó el repositorio no podía descifrar ni inspeccionar el punto de control almacenado en el mismo ordenador.
Esta distinción importa. “Cifrado” puede sonar como “no disponible para el proveedor”, pero esas afirmaciones no son equivalentes. El cifrado protege los datos según quién controle las claves pertinentes.
El informe también afirma que dos configuraciones de privacidad visibles no detuvieron la creación ni la transferencia de puntos de control. Esa acusación no se ha confirmado mediante una auditoría independiente del producto, y un participante de Hacker News informó no haber encontrado ningún directorio de puntos de control correspondiente.
La diferencia podría reflejar versiones del producto, sistemas operativos, estados de cuenta, despliegues graduales o usos específicos de funciones. También podría indicar que el caso original no se aplica a todos los usuarios.
Z.ai debe aclarar esas condiciones. Hasta entonces, la descripción más segura es que los investigadores documentaron el comportamiento en al menos un entorno probado, mientras que su prevalencia total sigue siendo desconocida.
Por qué un directorio .git completo es más sensible que el código actual
Un repositorio Git contiene la memoria de un proyecto, incluida información que ya no aparece en sus archivos actuales.
Los desarrolladores suelen describir .git como “historial”, pero contiene más que la salida de git log. Almacena objetos, referencias, información de ramas, configuración, reflogs y otros metadatos del repositorio.
Git es fundamentalmente una base de datos direccionable por contenido. Sus objetos blob conservan el contenido de los archivos, los objetos tree describen estados de directorios y los objetos commit conectan instantáneas en un historial.
El modelo de objetos de Git oficial explica cómo esos elementos permanecen dentro de .git/objects. Una aplicación que copie ese directorio puede recibir mucho más que los archivos visibles en el árbol de trabajo.
Pensemos en un desarrollador que hace commit por accidente de una credencial de API el lunes y la elimina el martes. El archivo actual ya no muestra la credencial, pero el objeto anterior puede seguir siendo accesible a través del historial del repositorio.
Eliminar la copia más reciente no basta. La guía de GitHub sobre eliminación de datos sensibles indica a los desarrolladores que primero revoquen las credenciales expuestas y luego consideren una reescritura coordinada del historial.
El mismo problema se aplica a certificados privados, nombres de host internos, identificadores de clientes, archivos de entorno y credenciales incrustadas en fixtures de prueba. Un repositorio también puede conservar arquitectura abandonada, correcciones de seguridad, productos no lanzados y material de licencias.
Los reflogs amplían el riesgo. Registran cómo se movieron las referencias locales y pueden conservar rutas de acceso a commits que ya no son visibles en una rama compartida.
Las ramas locales pueden revelar iniciativas que nunca se publicaron. Los mensajes de commit pueden nombrar clientes, vulnerabilidades, empleados o incidentes internos. La configuración del repositorio puede identificar remotos privados y dominios de infraestructura.
Git LFS introduce otra categoría. Su caché puede contener archivos de diseño, conjuntos de datos, contenido multimedia, modelos empaquetados u otros binarios que los desarrolladores creen razonablemente que quedan fuera del contexto inmediato de un asistente.
Por tanto, el componente LFS reportado de 196,1 MB no era volumen irrelevante. Podría representar parte del material menos textual y comercialmente más sensible del proyecto.
Un agente de programación puede necesitar legítimamente un amplio acceso local. No puede refactorizar una aplicación compleja sin leer módulos relacionados, ejecutar pruebas o comprender dependencias.
Ese permiso local no implica automáticamente autorización para crear una copia duradera en la nube de todo lo accesible para el proceso. Leer un archivo para una tarea solicitada, enviar contexto seleccionado para inferencia y archivar el repositorio completo son operaciones distintas.
Por eso la afirmación sobre la carga del historial de Git de ZCode es más grave que la observación de que los asistentes de programación en la nube procesan código. La disputa se refiere al alcance, la persistencia, el control y la divulgación.
Un desarrollador podría aprobar conscientemente una solicitud de modelo que contenga una función y sus dependencias. Ese mismo desarrollador podría rechazar la carga de una caché LFS, credenciales eliminadas, ramas inactivas y años de objetos de commit.
Los usuarios empresariales afrontan preocupaciones adicionales. Un repositorio puede contener material sujeto a contratos de clientes, condiciones de depósito de código fuente, controles de exportación, normas de residencia de datos o políticas de acceso de empleados.
La pregunta relevante no es simplemente si se utilizó cifrado. Los equipos de seguridad necesitan saber qué se recopiló, dónde se almacenó, quién tenía las claves, cuánto tiempo permaneció y cómo funcionaba la eliminación.
Los controles de privacidad y los puntos de control parecen contar historias distintas
La preocupación más aguda es la brecha reportada entre lo que los usuarios podían controlar y lo que la aplicación presuntamente hacía.
La documentación oficial de ZCode describe un agente que comprende el estado del espacio de trabajo, las referencias de archivos, las tareas y el contexto de las ramas de Git. Su documentación del agente también presenta la recuperación de estado como parte del soporte para tareas de desarrollo más largas.
Los puntos de control pueden cumplir una finalidad legítima. Un agente que edita decenas de archivos necesita una forma de recuperarse tras un cambio fallido, comparar estados o restaurar trabajo interrumpido por un fallo.
Esa función no requiere que los puntos de control sean invisibles. Tampoco establece que cada parte de .git deba incluirse en un archivo remoto.
Un diseño que preserve la privacidad podría excluir por defecto los objetos de Git y las cachés LFS. Podría publicar el manifiesto exacto del archivo antes de la transferencia, mantener los puntos de control localmente o solicitar aprobación explícita antes de la sincronización en la nube.
También podría proporcionar una política organizativa que bloquee las instantáneas remotas. Los administradores podrían imponer exclusiones a nivel de repositorio y confirmar su efecto mediante un registro de auditoría.
En cambio, la investigación alega que el proceso de archivado de ZCode operaba fuera del bucle visible de herramientas del agente. Según se informa, las herramientas enumeradas del agente no contenían ninguna acción de instantánea o carga que los usuarios pudieran aprobar.
Esa arquitectura explicaría por qué los permisos de comandos no lograron detener la transferencia. Un componente auxiliar a nivel de host puede ejecutarse independientemente de las herramientas del modelo, incluso cuando el usuario restringe la ejecución de shell o la modificación de archivos.
También expone un punto ciego en las interfaces actuales de agentes. Los avisos de permisos suelen centrarse en acciones visibles, como ejecutar un comando, editar un archivo o abrir una dirección de red.
Los servicios en segundo plano reciben menos atención. Pueden indexar carpetas, recopilar diagnósticos, sincronizar sesiones o crear artefactos de recuperación sin aparecer en la conversación.
Aquí cobra importancia la distinción entre inferencia y sincronización. Enviar código seleccionado a un modelo en la nube es lo bastante visible como para que la mayoría de los usuarios lo esperen de un asistente respaldado por la nube.
Copiar la base de datos subyacente del repositorio para reversión o indexación es un segundo flujo de datos. Necesita su propia explicación, controles de alcance, reglas de retención e interfaz de eliminación.
La actual política de privacidad de ZCode indica que los datos personales pueden conservarse según sea necesario para prestar servicios, cumplir obligaciones, proteger intereses comerciales legítimos y mejorar la seguridad o la estabilidad. También señala que la retención varía según el tipo de datos, su sensibilidad, finalidad y requisitos legales.
Esas declaraciones generales no responden a las preguntas planteadas por el informe. La política debe identificar si los puntos de control del espacio de trabajo cuentan como entrada del usuario, datos técnicos u otra categoría.
También debería explicar qué región de almacenamiento se aplica, si los subcontratistas procesan los archivos y si la eliminación de una cuenta elimina todos los puntos de control. Los usuarios necesitan periodos concretos de retención o criterios claros vinculados a la función pertinente.
Sobre todo, Z.ai debería documentar si los controles de privacidad afectan a las cargas de puntos de control. Un control etiquetado en torno a la recopilación de datos puede generar una falsa sensación de seguridad si regula la analítica, pero no la sincronización del espacio de trabajo.
El lenguaje y la ubicación de un control importan tanto como su implementación interna. Los desarrolladores no pueden tomar decisiones informadas cuando flujos de datos sustancialmente distintos se agrupan bajo términos vagos.
La respuesta más sólida posible de Z.ai sería técnica, no retórica. Debería enumerar las versiones afectadas, las condiciones de activación, las exclusiones de archivos, los endpoints, los roles de cifrado, los periodos de retención y los procedimientos de eliminación.
También debería explicar si el comportamiento cambió después del informe. Sin ese detalle, los usuarios no pueden determinar si una actualización solucionó el problema o simplemente eliminó la evidencia local.
Los pesos abiertos no hacen local a un agente de programación cerrado
El incidente separa el modelo del software que decide qué puede ver el modelo y qué sale de la máquina.
Los modelos GLM son fundamentales para la estrategia de desarrolladores de Z.ai, y algunas versiones se han distribuido con pesos abiertos. Los desarrolladores pueden inspeccionar esos archivos de modelo, ejecutar versiones compatibles en su propia infraestructura y evitar un endpoint de inferencia alojado.
ZCode es una capa diferente. Es el entorno que elige el contexto, invoca herramientas, almacena sesiones, gestiona puntos de control, se conecta a servicios en la nube y se actualiza por sí mismo.
El entorno puede determinar los resultados de privacidad incluso cuando el modelo subyacente se ejecuta localmente. Un modelo local no impide que una aplicación circundante envíe telemetría, índices, historial de sesiones o instantáneas de recuperación a otros lugares.
Del mismo modo, un modelo abierto no puede revelar lo que hace una aplicación Electron cerrada en un proceso en segundo plano. Los investigadores deben observar el tráfico de red, inspeccionar los paquetes de la aplicación y reconstruir el comportamiento tras el lanzamiento.
Este es el principal conflicto de confianza. La experiencia de producto de ZCode enfatiza la comprensión local del espacio de trabajo, mientras que el informe describe un mecanismo de captura en la nube más amplio de lo que los desarrolladores esperaban.
Los competidores también procesan datos de desarrolladores, por lo que la comparación correcta no es «ZCode carga código mientras todos los demás agentes permanecen locales». Eso sería inexacto.
Claude Code, GitHub Copilot, Codex, Cursor y otras herramientas conectadas a la nube envían algunas entradas de usuarios y contexto de código a servicios remotos. Los índices de repositorios, las sesiones de agentes y los entornos de tareas en la nube pueden crear copias adicionales.
Las diferencias aparecen en la divulgación y el control. GitHub, por ejemplo, documenta las políticas de exclusión de contenido y explica que algunas superficies de Copilot no admiten esas exclusiones.
GitHub también documenta cuándo la indexación semántica de repositorios fuera de GitHub carga datos y afirma que los administradores empresariales deben habilitar esa función. Esos controles siguen teniendo limitaciones, pero los usuarios pueden identificar el flujo de datos y evaluarlo.
Ese es el estándar al que ahora se enfrenta Z.ai. Un proveedor no necesita prometer que ningún código saldrá jamás de un ordenador si el producto depende de la inferencia en la nube.
Debe describir cada transferencia con precisión. Debe distinguir entre el contexto temporal de una solicitud y una instantánea persistente del repositorio, y ofrecer a los administradores un control exigible.
Los entornos de código abierto ofrecen una respuesta. Su código puede revelar exclusiones de archivos, endpoints de red y comportamiento de actualización, mientras que revisores independientes pueden comprobar si la configuración documentada coincide con la implementación.
El código abierto no es una garantía completa de seguridad. Pocos usuarios inspeccionan cada dependencia, los binarios firmados pueden diferir del código publicado y las actualizaciones comprometidas aún pueden causar daños.
Las herramientas de código cerrado tampoco son automáticamente maliciosas. Pueden someterse a evaluaciones independientes, proporcionar mapas detallados de datos, aplicar controles de inquilinos y publicar comportamientos de red verificables.
Sin embargo, la opacidad eleva el coste de la verificación. Cuando una aplicación tiene amplios permisos de sistema de archivos y ejecución autónoma, ese coste se convierte en una consideración de seguridad sustancial.
La discusión en Hacker News reflejó ambas posturas. Varios comentaristas consideraron que cualquier entorno de programación cerrado constituye un riesgo inaceptable, mientras que otros señalaron que los agentes en la nube reciben inherentemente contexto de proyecto.
Un usuario dijo que no podía reproducir el directorio de puntos de control informado a pesar de utilizar ZCode. Otros sostuvieron que un sandbox debería restringir toda herramienta propietaria para desarrolladores, independientemente del proveedor o del país.
Esas reacciones identifican dos responsabilidades distintas. Los proveedores deben divulgar sus flujos de datos, y los equipos de desarrollo deben limitar a qué puede acceder un agente.
Ninguna responsabilidad anula a la otra. El aislamiento no equivale a consentimiento, y un control de privacidad no constituye una contención efectiva.
El riesgo inmediato depende del contenido del repositorio y de la versión del producto
La evidencia respalda una revisión urgente, pero no prueba que todos los usuarios de ZCode hayan tenido los mismos datos cargados.
El ejemplo documentado involucraba un espacio de trabajo y una configuración de aplicación observada. Los informes públicos no han establecido cuántas instalaciones crearon puntos de control, cuándo comenzó el comportamiento ni si todos los sistemas operativos siguieron la misma ruta.
Tampoco está claro si los usuarios tuvieron que habilitar una función concreta de recuperación o indexación. El estado de autenticación puede ser relevante porque el informe asocia las transferencias con haber iniciado sesión.
El historial de versiones también importa. Una versión posterior podría cambiar el directorio, el endpoint, las exclusiones o el comportamiento de programación sin invalidar la observación anterior.
Esta incertidumbre debería acotar las afirmaciones, no suprimir la investigación. Los equipos que utilizaron ZCode con repositorios privados tienen evidencia suficiente para realizar una revisión de incidentes.
Deberían empezar por el alcance. Identifiquen qué desarrolladores instalaron ZCode, qué versiones ejecutaron, cuándo iniciaron sesión y qué repositorios estaban accesibles durante esos periodos.
A continuación, inspeccionen los registros de endpoints, proxies, DNS, firewalls y detección de endpoints para encontrar comunicaciones con servicios de Z.ai y Aliyun. Los archivos de puntos de control locales pueden ayudar, pero su ausencia no establece de forma concluyente que no se produjera ninguna transferencia.
Las organizaciones deberían conservar las pruebas antes de desinstalar o actualizar la aplicación. Una actualización puede modificar registros, rutas de almacenamiento o binarios que, de otro modo, ayudarían a los investigadores a reconstruir la actividad.
Los equipos de seguridad deberían asumir que cualquier credencial confirmada en el historial de un repositorio expuesto necesita revisión. GitHub recomienda rotar una credencial filtrada porque eliminarla de los archivos más recientes no la neutraliza.
Esa respuesta debe seguir siendo proporcionada. No roten todas las credenciales corporativas solo porque un desarrollador instaló ZCode. Primero identifiquen los repositorios, luego busquen en sus historiales y validen qué secretos seguían activos.
Los propietarios de repositorios también deberían examinar material sensible que no sea secreto. Los commits antiguos podrían contener datos de clientes, detalles de vulnerabilidades, endpoints internos, activos con licencia o negociaciones que requieran revisión legal.
Si el repositorio contenía datos regulados o restringidos contractualmente, los equipos jurídicos y de cumplimiento deberían evaluar las obligaciones de notificación. La respuesta depende de la jurisdicción, el lenguaje contractual, las pruebas confirmadas de transferencia y los datos implicados.
Los desarrolladores que continúen probando ZCode deberían aislarlo. Una máquina virtual o contenedor dedicado puede limitar el sistema de archivos visible, aunque las redes y los directorios montados aún requieren una configuración cuidadosa.
Utilicen un repositorio desechable que no contenga credenciales reales ni historial comercial. Eviten montar un directorio personal, una carpeta SSH, configuración de nube, credenciales de paquetes o árboles de código fuente no relacionados.
Las restricciones del sistema de archivos pueden bloquear directorios de puntos de control, pero son una defensa frágil. Las rutas y los procesos pueden cambiar entre actualizaciones, y denegar escrituras puede desactivar el comportamiento de recuperación o romper la aplicación.
Los controles de red ofrecen otra capa. Los equipos pueden restringir los destinos salientes y registrar los intentos de conexión, aunque bloquear los servicios necesarios puede hacer que el producto sea inutilizable.
Un modelo más seguro a largo plazo utiliza listas de permitidos explícitas. El agente recibe una copia de trabajo limitada del proyecto, credenciales temporales y solo los servicios necesarios para la tarea.
Este enfoque es útil en todos los flujos de trabajo de ingeniería, no solo con ZCode. Cualquier asistente autónomo con acceso al sistema de archivos y al shell debe tratarse como una dependencia privilegiada de desarrollo.
El objetivo no es demostrar una intención maliciosa a partir de pruebas incompletas. Es reducir las consecuencias de un comportamiento no documentado.
Tres señales mostrarán si Z.ai ha resuelto la brecha de confianza
La próxima prueba es si Z.ai convierte un flujo de datos no documentado en una función de producto limitada, visible y verificable.
La primera señal es una respuesta pública detallada. Z.ai debería confirmar o refutar la carga reportada del historial Git de ZCode, identificar las versiones afectadas y explicar qué estado del producto la activó.
Una declaración útil abordaría directamente el contenido medido del archivo. Debería indicar si se incluyeron .git/objects, .git/lfs, reflogs, archivos ignorados y configuración global.
Si Z.ai publica únicamente una garantía general de que los datos están cifrados, la preocupación central permanece. Según los informes, la empresa controlaba la clave de descifrado, por lo que el cifrado en tránsito no responde a las preguntas sobre acceso o retención.
La segunda señal es un control de puntos de control exigible. ZCode necesita una configuración que detenga las instantáneas remotas, que pueda gestionar una organización y que sea independiente de las preferencias de analítica o entrenamiento de modelos.
Los usuarios deberían poder verificar la configuración mediante registros o un evento de red documentado. La aplicación debería mostrar qué pretende cargar antes de la primera transferencia.
Las exclusiones predeterminadas deberían eliminar .git, las cachés de LFS, los archivos ignorados, las credenciales y las ubicaciones habituales de secretos. Los usuarios podrían optar por incluir historial adicional cuando una tarea realmente lo requiera.
Una opción de recuperación exclusivamente local resolvería gran parte de la tensión. Los puntos de control pueden admitir la reversión sin convertirse en archivos en la nube, especialmente cuando el agente y el modelo se ejecutan en la misma máquina.
La tercera señal es la reproducción independiente. Los investigadores necesitan probar una versión actual en sistemas operativos compatibles, cuentas nuevas y existentes, y diferentes configuraciones de privacidad.
Ese trabajo debería responder si el comportamiento original era universal, condicional o ya había cambiado. También debería verificar si eliminar puntos de control mediante el producto elimina todas las copias del lado del servidor.
Una evaluación de terceros reforzaría la respuesta de Z.ai, especialmente si el evaluador publica el alcance y los métodos. Las capturas de paquetes reproducibles y los manifiestos de archivos serían más valiosos que un lenguaje amplio de certificación.
Para los equipos de desarrollo, la lección va más allá de una aplicación. Inventaríen los agentes de programación como componentes de la cadena de suministro de software, documenten sus endpoints y revisen sus flujos de datos antes de conceder acceso a repositorios privados.
Formulen cinco preguntas directas: ¿Qué puede leer el agente? ¿Qué transmite? ¿Qué persiste de forma remota? ¿Quién posee las claves? ¿Qué control detiene cada transferencia?
Si un proveedor no puede responder a esas preguntas, restrinjan el agente a entornos desechables hasta que pueda hacerlo. Si una respuesta se basa únicamente en «cifrado», pregunten quién puede descifrarlo.
La carga reportada del historial Git de ZCode aún no ha establecido la exposición de todos los usuarios ni ha demostrado el uso indebido de ningún archivo. Ha establecido una discrepancia creíble que exige una respuesta precisa.
Z.ai puede reducir esa brecha publicando el mecanismo, corrigiendo los valores predeterminados, ofreciendo un interruptor real de desactivación y respaldando la verificación independiente. Hasta entonces, los desarrolladores deberían considerar el espacio de trabajo visible de ZCode como el límite mínimo posible de recopilación, no el máximo.
