Privacidad en coding agents: el historial Git también puede salir del workspace

Un coding agent es un asistente de IA que escribe y edita código en tu máquina o en tu repositorio. El harness es la capa que conecta el modelo con tu entorno: archivos, terminal, Git y, a veces, la nube del proveedor. El historial Git es el registro completo de cambios del proyecto — no solo lo que tienes abierto hoy.

La duda B2B que escuchamos en LatAm es simple: “si el modelo es de pesos abiertos (open weights) o corre en local, ¿ya estoy a salvo?”. No necesariamente. Los pesos abiertos no equivalen a un harness confiable.

La fuente que usamos aquí es el reporte de Tokenstead sobre ZCode y la subida silenciosa del historial Git (publicado el 18 de septiembre de 2026), basado en el reverse engineering de ferstar. Lo atribuimos con cuidado: no inventamos citas ni certificaciones.

En Somos Gente Digital no vendemos miedo ni certificaciones inventadas. Traducimos el hallazgo a una decisión de workspace: en proyectos de clientes, elegir el agent forma parte del diseño de seguridad.

Según el reporte de Tokenstead (18 de septiembre de 2026), un análisis forense de ZCode —la app de escritorio de coding agents de Z.ai, la compañía detrás de modelos GLM de pesos abiertos— describe un comportamiento grave cuando hay sesión iniciada: el runtime empaqueta el workspace, incluido el directorio .git completo, lo cifra y lo sube al almacenamiento en la nube del vendor.

El detalle que cambia la lectura: el cifrado usa una clave que, según ese análisis, solo el servidor del vendor puede usar. Es decir, el archivo cifrado en tu disco no te protege a ti frente al proveedor; protege el payload para que el servidor pueda leerlo.

Tokenstead también resume que ciertos interruptores de la interfaz no detienen el empaquetado y la subida, y que la política de privacidad habla de texto/archivos enviados en la conversación —no de empaquetar el historial Git completo—. Atribuimos esas conclusiones al reporte; si Z.ai responde con un fix o un cambio de disclosure, el contexto puede actualizarse.

Correr un modelo de pesos abiertos en tu hardware responde a una pregunta: ¿quién controla el modelo?. El harness responde a otra: ¿qué transmite el runtime cuando hay sesión, y quién puede descifrarlo?.

Confundir ambas es fácil. Varios comentarios en la discusión pública asumieron que, si GLM es open weight, ZCode también era “abierto” o local por defecto. No es lo mismo. Un modelo local envuelto en un harness que habla con la nube no es “local” en el sentido de confianza del workspace.

La lección SGD: audita la superficie de confianza del producto que toca tu repo —no solo la licencia de los pesos.

Un historial Git no es una foto del archivo abierto. Es la línea de tiempo del proyecto. Ahí pueden vivir:

• Propiedad intelectual (IP): diseños, módulos internos y caminos de arquitectura que no están en un solo archivo.
• Secretos “borrados”: API keys o credenciales que se committearon y luego se quitaron del working tree, pero siguen en objetos antiguos.
• Planes de producto: nombres de ramas no publicadas, tickets internos, hostnames y rutas en .git/config.

Para un equipo LatAm B2B que trabaja en repos de clientes, eso no es un “detalle de hobby”. Es exposición contractual, reputacional y de compliance —aunque el chat del agent se sienta inocente.

Antes de instalar un harness en un workspace de cliente, conviene una lista corta y verificable:

1. Qué transmite el runtime cuando hay sesión iniciada (no solo cuando envías un prompt).
2. Quién puede descifrar lo que se almacena o se sube (¿tú, el vendor, ambos?).
3. Si los toggles de privacidad están documentados y se pueden comprobar en el cliente o en logs —no solo en marketing.
4. Si el vendor declara snapshots del workspace / historial Git de forma explícita.
5. Si existe una vía open-source o un agent con superficie de confianza explícita para trabajo sensible.
6. Quién en tu equipo es dueño de la decisión: seguridad del workspace, no solo “productividad del developer”.

No inventamos sellos. Preferimos herramientas con disclosure claro y comportamiento auditable. El reporte de Tokenstead sirve como recordatorio de por qué “open weights” no cierra la conversación.

Somos un equipo humano de agencia web/tech B2B. Usamos IA todos los días. También tratamos la elección del coding agent como parte del diseño de seguridad del workspace —igual que accesos, secretos y entornos.

En la práctica: criterio de workspace, revisión humana donde duele (secretos, datos de cliente, IP) y software a medida / servicios cuando el negocio pide control real — no solo un chat más rápido.

Si te interesa el contraste con velocidad de IA sin mapa de dominio, también escribimos sobre vibe-coding sin mapa.

¿Qué es un coding agent?

Un asistente de IA que escribe y edita código en tu entorno. Puede vivir en el IDE, en una app de escritorio o en la terminal. El valor está en la velocidad; el riesgo está en qué ve y qué transmite el harness.

¿Qué es el harness?

La capa que conecta el modelo con tu máquina y tu repo: lectura de archivos, comandos, Git, actualizaciones y, a veces, telemetría o snapshots hacia la nube del vendor.

¿Open weights significa que es privado?

No. Pesos abiertos hablan del modelo. Privacidad del workspace habla del runtime. Puedes correr un modelo local y aun así tener un harness que sube más de lo que crees.

¿Por qué importa el historial Git?

Porque incluye el pasado del repo: secretos viejos, ramas no publicadas y decisiones de producto. No es solo el archivo que tienes abierto en el editor.

¿Este post acusa a todos los coding agents?

No. Atribuimos el caso concreto al reporte de Tokenstead sobre ZCode (septiembre 2026). El patrón útil para B2B es general: verificar transmisión y descifrado en cualquier harness con sesión.

¿Cómo lo abordamos en proyectos de clientes?

Como diseño de seguridad del workspace: qué tool entra al repo, con qué cuenta, qué datos puede tocar y qué evidencia hay de su comportamiento. La productividad cuenta; la confianza del cliente también.

Si estás eligiendo coding agents para un equipo o un repo de cliente y quieres criterio —no teatro de privacidad—, hablemos. En SGD ayudamos a diseñar el workspace con la misma seriedad que el producto.