El CLI Grok Build de xAI, diseñado para ayudar en la escritura de código, según un investigador subía al almacenamiento en la nube de xAI no solo los archivos necesarios para ejecutar la tarea, sino repositorios Git completos junto con todo el historial de commits. El problema afectaba como mínimo a la versión 0.2.93 y potencialmente a cualquier desarrollador que hubiera utilizado la herramienta hasta el 13 de julio. Al mismo tiempo, la configuración de usuario para rechazar el entrenamiento del modelo no detenía la transferencia de datos. A todos los que hayan trabajado con Grok Build se les recomienda rotar de inmediato cualquier secreto que pudiera encontrarse en los archivos rastreados o en el historial de commits.
Qué mostró el análisis del tráfico de red
El investigador que publica bajo el seudónimo cereblab realizó un análisis detallado del tráfico de red de Grok Build versión 0.2.93. La herramienta utilizaba dos canales de transmisión de datos separados: uno para interactuar con el modelo de lenguaje a través del endpoint /v1/responses, y otro para cargar datos al almacenamiento mediante /v1/storage.
La magnitud de la discrepancia entre estos canales es reveladora. En un repositorio de 12 GB cuyos archivos el modelo no leía, el tráfico hacia el modelo fue de unos 192 KB, mientras que al canal de almacenamiento se enviaron 5,10 GiB, una diferencia de aproximadamente 27 800 veces. La carga se realizaba en 73 fragmentos de ~75 MB, cada uno de los cuales recibía una respuesta HTTP 200. Según se indica, el volumen de la carga se escalaba de forma proporcional al tamaño del repositorio.
El almacenamiento de destino —el bucket grok-code-session-traces en Google Cloud Storage— fue identificado tanto en el archivo binario de la herramienta como en el archivo intermedio metadata.json, que contenía rutas del tipo gs://grok-code-session-traces/.
Prueba canaria y problema de los secretos
Para confirmar el hecho de la transmisión, el investigador colocó en el repositorio el archivo src/_probe/never_read_canary.txt con un marcador único e indicó explícitamente al agente que no abriera ese archivo. Tras interceptar el bundle cargado y clonarlo, el archivo canario se restauró literalmente junto con todo el historial de commits. La prueba se reprodujo en un segundo repositorio independiente con un resultado similar.
Otro problema aparte tenía que ver con el tratamiento de secretos. Cuando Grok leía el archivo rastreado .env en el marco de una tarea, su contenido —incluidos los valores de prueba API_KEY y DB_PASSWORD— se transmitía al contexto del modelo sin ningún tipo de edición y, además, se guardaba en el archivo session_state, que se enviaba al almacenamiento. Los secretos en la prueba eran ficticios, pero el propio mecanismo —envío y almacenamiento de credenciales sin filtrado— representa un riesgo sistémico.
Importante: la investigación constata el hecho de la transmisión, recepción y conservación de los datos, pero no afirma que xAI utilizara el código para entrenar el modelo ni que el personal de la empresa tuviera acceso a él. También se señala que los archivos de .gitignore que nunca habían entrado en los commits no se incluían en el bundle.
La configuración de privacidad no funcionaba como se esperaba
Un aspecto clave del incidente es el comportamiento de las configuraciones de usuario. Según el investigador, con la opción «Improve the model» desactivada, la herramienta seguía cargando el repositorio, y la respuesta del servidor a la petición /v1/settings seguía conteniendo trace_upload_enabled: true. Esto significa que el conmutador solo gestionaba el uso de los datos para entrenar el modelo, pero no controlaba el propio hecho del envío de código desde la máquina del usuario. Dos mecanismos distintos —transmisión de datos y su uso para entrenamiento— estaban separados, pero el usuario solo disponía de control sobre el segundo.
Comparación con competidores
En el análisis comparativo realizado por el mismo investigador, Claude Code y Codex no enviaban bundles de repositorios. Gemini no envió ningún bundle en la prueba sin tarea activa, aunque la prueba con una tarea real no se completó debido al agotamiento de la cuota. Grok Build resultó ser la única herramienta que realizaba una carga masiva del espacio de trabajo. Al mismo tiempo, todas las herramientas de codificación en la nube envían los archivos que abren: un modelo de funcionamiento totalmente local no les es aplicable.
Respuesta de xAI y estado actual
El 13 de julio, ese mismo archivo binario de la versión 0.2.93 dejó de realizar peticiones a /v1/storage. El investigador llevó a cabo seis pruebas adicionales: ni una sola carga al almacenamiento. El servidor pasó a devolver disable_codebase_upload: true y trace_upload_enabled: false. Dado que el cliente seguía en la misma versión, se trató de un bloqueo en el lado del servidor y no de una actualización de la aplicación. El desarrollador Pieter Dedene confirmó un cambio de flags análogo en su cuenta.
La empresa xAI reaccionó a través de publicaciones en X y no mediante una notificación formal de seguridad. La cuenta @SpaceXAI comunicó que los clientes corporativos con modo de Zero Data Retention (ZDR) nunca estuvieron expuestos al guardado de código ni de trazas, y que los usuarios individuales pueden ejecutar el comando /privacy en el CLI para desactivar el almacenamiento y eliminar los datos previamente sincronizados. Elon Musk afirmó que todos los datos de usuario cargados anteriormente serían «eliminados completa e incondicionalmente», si bien esta declaración se hizo en la red social sin documentación técnica adjunta.
Un detalle significativo: un análisis independiente de la versión 0.2.99 mostró que el código de carga sigue presente en el archivo binario, pero desactivado mediante un flag del servidor. Esto significa que xAI puede reactivar la funcionalidad sin publicar una actualización del cliente.
Recomendaciones
- Rotación de secretos: sustituya todas las credenciales que Grok Build pudiera haber leído —contenido de archivos rastreados, datos del historial de commits, incluidos secretos que se hubieran commiteado y luego eliminado del árbol de trabajo. Eliminar un archivo de la rama actual no lo elimina del historial de Git.
- Comando /privacy: si sigue utilizando Grok Build, ejecute
/privacyen el CLI para desactivar el almacenamiento y solicitar la eliminación de los datos previamente sincronizados. - Auditoría del tráfico de red: al trabajar con cualquier herramienta de codificación en la nube, supervise el tráfico saliente. El volumen de datos que envía la herramienta debe ser proporcional a la tarea que está ejecutando.
- Almacenamiento de secretos: no coloque credenciales reales en archivos rastreados por Git. Utilice gestores de secretos y variables de entorno cargadas desde almacenes protegidos.
xAI aún no ha publicado una notificación formal de seguridad ni ha respondido a tres preguntas clave: por qué se cargaban repositorios completos por defecto, durante cuánto tiempo se almacenaban los datos y cuántos usuarios se han visto afectados. El código de carga sigue en el archivo binario y está gestionado por un flag del servidor que puede cambiarse en cualquier momento. Para los desarrolladores que hayan trabajado con Grok Build, la acción prioritaria es la rotación de todos los secretos que en algún momento hayan acabado en archivos rastreados o en el historial de commits de los repositorios afectados.
