Grok Build enviaba repositorios completos a la nube; Musk defiende los controles de privacidad de xAI

Grok Build enviaba repositorios completos a la nube; Musk defiende los controles de privacidad de xAI

Un análisis del tráfico de la herramienta de programación encontró que la CLI de xAI transmitía todos los archivos rastreados y el historial Git de un proyecto, aunque el agente no los necesitara. La empresa aseguró que las cuentas con retención cero no conservan código y que el comando /privacy permite eliminar los datos sincronizados previamente.

La herramienta de programación Grok Build de xAI enviaba copias completas de los repositorios Git donde era ejecutada a una infraestructura de almacenamiento en Google Cloud, incluso cuando el agente sólo necesitaba consultar una pequeña parte del proyecto.

El comportamiento fue documentado por el invesstigador independiente identificado como cereblab mediante un análisis del tráfico de red de la versión 0.2.93 de la interfaz de línea de comandos. Las pruebas encontraron que Grok Build generaba un paquete con todos los archivos rastreados y el historial del repositorio y lo transfería mediante un canal independiente de las solicitudes utilizadas para conversar con el modelo.

El investigador independiente
cereblab documentó el caso en Github.

En un repositorio de prueba de 12 gigabytes, al menos 5.10 GiB fueron enviados al sistema de almacenamiento antes de que el investigador detuviera la captura. La interacción directa con el modelo, en contraste, utilizó únicamente 192 kilobytes durante la misma sesión.

La diferencia permitió identificar dos flujos. El primero contenía las instrucciones y los archivos que el agente abría para realizar la tarea; el segundo transfería una instantánea mucho más amplia del espacio de trabajo.

El destino aparecía identificado como grok-code-session-traces, un bucket de Google Cloud Storage mencionado dentro del programa y en los metadatos generados por la herramienta. Las solicitudes observadas durante las pruebas fueron aceptadas por el servidor.

El repositorio se enviaba aunque el agente no abriera sus archivos

Para comprobar que la transferencia no estaba limitada al contexto necesario para responder, el investigador colocó un archivo con un marcador único dentro de un repositorio y ordenó a Grok Build contestar sin leer ningún documento.

El paquete Git capturado durante la prueba permitió reconstruir posteriormente el proyecto y recuperar el archivo que el agente había recibido la instrucción de no abrir. También contenía el historial completo de cambios. El resultado se reprodujo en un segundo repositorio independiente.

El hallazgo no demuestra que xAI haya entrenado sus modelos con esos proyectos ni que empleados de la compañía hayan accedido a su contenido. Sí demuestra que los archivos rastreados y el historial Git salieron de la computadora y fueron aceptados por la infraestructura de almacenamiento.

La distinción es importante porque las herramientas de programación alojadas en la nube necesariamente deben recibir algún código para analizarlo. El cuestionamiento no es que Grok Build enviara los documentos pertinentes, sino que transmitiera el repositorio completo cuando la tarea podía requerir apenas unos cuantos archivos.

En el experimento de 12 gigabytes, el volumen enviado por el canal de almacenamiento fue alrededor de 27 mil 800 veces superior al de las solicitudes realizadas al modelo. La transferencia continuó incluso después de que la sesión alcanzara límites de uso que impedían al modelo seguir contestando.

Los archivos leídos podían viajar sin ocultar sus secretos

El análisis también examinó qué ocurría cuando Grok Build abría archivos con credenciales. El investigador colocó valores falsos dentro de un archivo .env y comprobó que aparecían sin edición tanto en la solicitud enviada al modelo como en el archivo utilizado para conservar el estado de la sesión.

La prueba no utilizó credenciales reales y tampoco permite afirmar que cualquier secreto almacenado en un archivo ignorado por Git sea enviado automáticamente. Los documentos examinados se encontraban rastreados dentro del repositorio.

Sin embargo, el experimento muestra el riesgo de ejecutar agentes de programación dentro de proyectos que contienen contraseñas, tokens, claves de acceso o configuraciones internas. Incluso cuando un secreto ya fue eliminado de la versión actual, todavía puede permanecer dentro del historial Git incluido en el paquete.

Una copia completa de un repositorio corporativo puede contener años de desarrollo, código propietario, nombres de clientes, vulnerabilidades previamente corregidas y credenciales incorporadas accidentalmente a versiones anteriores.

Desactivar la mejora del modelo no detenía las cargas

El investigador también desactivó la opción visible para impedir que los datos fueran utilizados en la mejora del modelo. La modificación no detuvo la transferencia: Grok Build volvió a enviar el repositorio completo y la configuración recibida por la CLI continuó mostrando habilitadas las funciones de carga.

Este resultado no significa necesariamente que xAI utilizara el código para entrenar Grok. La exclusión de la mejora del modelo podía respetarse mientras los datos se almacenaban con una finalidad diferente, como mantener sesiones, sincronizar proyectos, recuperar contexto o depurar el funcionamiento de la herramienta.

El incidente muestra que existen al menos tres decisiones distintas: qué información sale de la computadora, cuánto tiempo se conserva en los servidores y si puede utilizarse para entrenar o mejorar modelos.

Desactivar el entrenamiento no equivale, por sí mismo, a impedir la transmisión o el almacenamiento. Esa diferencia puede no resultar evidente para un usuario que interpreta una opción general de privacidad como una protección integral de su código.

xAI asegura que las cuentas con ZDR no conservan código

Después de que el análisis se difundió, xAI publicó una aclaración sobre sus controles de privacidad. La empresa aseguró que los equipos configurados con Zero Data Retention, o retención cero de datos, no conservan trazas ni información de código. También afirmó que todo uso de Grok Build mediante claves de la API respeta ese régimen.

La documentación oficial de xAI describe ZDR como una configuración que permite procesar solicitudes en tiempo real sin persistirlas en sus servidores. Cuando se encuentra activada, los contenidos y metadatos asociados no se escriben en almacenes permanentes después de entregar la respuesta.

Para los usuarios que no tienen habilitada la retención cero, la compañía indicó que Grok Build incorpora el comando /privacy. Desde ahí es posible consultar o modificar las preferencias y deshabilitar la retención de datos.

Según xAI, cambiar esa configuración también elimina los datos sincronizados anteriormente. La explicación responde una parte importante de la controversia: la empresa sostiene que el código no se conserva para los equipos con ZDR y que los demás usuarios cuentan con un mecanismo para eliminarlo.

Elon Musk respondió públicamente a la controversia. Además, responsables de Grok Build defendieron que las preferencias de privacidad siempre fueron respetadas y que la información no era conservada en los equipos o cuentas configurados con retención cero de datos.

Transmitir no es lo mismo que conservar

La aclaración de xAI no contradice el hallazgo principal del análisis. Un sistema con retención cero todavía necesita recibir temporalmente los datos para procesarlos; lo que promete es no escribirlos ni conservarlos después.

Por tanto, ambas afirmaciones pueden ser verdaderas al mismo tiempo: Grok Build podía transmitir el repositorio completo y, en una cuenta protegida por ZDR, xAI podía procesarlo sin mantener una copia permanente.

La controversia se desplaza entonces hacia la proporcionalidad y transparencia de la transferencia. El investigador afirmó que no encontró el mecanismo de carga del repositorio explicado en los materiales de instalación y uso rápido que revisó, aunque reconoció que no realizó una auditoría exhaustiva de toda la documentación de xAI.

Una advertencia general sobre sincronización o procesamiento de datos no comunica necesariamente lo mismo que una explicación directa: la aplicación puede copiar todos los archivos rastreados y el historial completo del repositorio donde se ejecuta.

La carga fue desactivada mediante una configuración remota

Después de la publicación del análisis, usuarios observaron que Grok Build comenzó a recibir desde los servidores una bandera denominada disable_codebase_upload: true. La versión del programa no había cambiado, pero el envío completo del repositorio dejó de aparecer en las pruebas posteriores.

Esto indica que el comportamiento estaba controlado, al menos parcialmente, mediante configuraciones remotas. xAI podía activar o desactivar la función sin distribuir una actualización nueva de la CLI.

La existencia de este mecanismo no demuestra por sí sola que la empresa admitiera un fallo de seguridad. También pudo tratarse de una decisión preventiva mientras respondía a la controversia o modificaba la manera de sincronizar proyectos.

No obstante, el cambio confirma que la carga de repositorios no era indispensable para que la herramienta siguiera funcionando y que podía deshabilitarse desde el servidor.

El problema principal es el consentimiento

La respuesta de xAI ofrece información relevante sobre retención y borrado, pero no resuelve por completo si los usuarios comprendían qué datos se enviaban.

Para una persona que programa un proyecto personal, la diferencia puede parecer menor. Para una empresa que trabaja con código propietario, información de clientes o contratos de confidencialidad, la mera transferencia puede ser relevante aunque el proveedor prometa eliminarla posteriormente.

Algunas organizaciones prohíben que el código salga de una infraestructura autorizada. Otras deben conocer en qué jurisdicción se procesa, qué subcontratistas intervienen y qué sistemas reciben temporalmente la información.

En esos casos, el problema no depende exclusivamente de si xAI entrenó modelos o retuvo datos durante días. El hecho de que el repositorio cruzara la red puede ser suficiente para activar riesgos contractuales, de propiedad intelectual o cumplimiento interno.

También existe una diferencia entre el consentimiento para enviar los archivos necesarios y el consentimiento para sincronizar el historial completo del proyecto. Un agente de código puede requerir contexto amplio, pero debería explicar qué recopila y ofrecer controles accesibles antes de comenzar la transferencia.

Los agentes de programación no son simples chats

El caso de Grok Build muestra que las herramientas de programación deben considerarse aplicaciones con acceso privilegiado. Pueden recorrer directorios, leer configuraciones, ejecutar comandos, consultar historiales y transmitir información hacia servicios externos.

Su comportamiento real no siempre puede deducirse de la interfaz visible. Puede depender de telemetría, almacenamiento de sesiones, procesos ejecutados en segundo plano y banderas remotas que cambian sin una actualización local.

Para las organizaciones, revisar únicamente si un proveedor promete no entrenar con los datos ya no es suficiente. También necesitan saber qué información abandona el equipo, dónde se procesa, cuánto tiempo permanece almacenada y cómo se verifica su eliminación.

La aclaración de xAI establece que Grok Build respeta la retención cero y permite borrar los datos sincronizados mediante /privacy. Esa explicación reduce parte de la incertidumbre inicial, pero deja vigente el aspecto más relevante del hallazgo: la herramienta enviaba un repositorio mucho más amplio que el contexto requerido por el modelo.

La pregunta de fondo no es sólo si xAI conservaba el código después de recibirlo. Es si los desarrolladores sabían que el repositorio completo podía salir de su computadora y si esa transferencia era realmente necesaria para cumplir la tarea.