Se descubrió que la herramienta Grok Build de xAI subía repositorios de Git completos, incluyendo el historial de cambios y claves secretas, a servidores de Google Cloud sin consentimiento. Este comportamiento ocurría incluso si la opción de mejorar el modelo estaba desactivada, diferenciándose de otras herramientas de IA. Aunque xAI desactivó la función y prometió borrar los datos, se recomienda a los usuarios cambiar todas sus credenciales comprometidas.

 

La CLI de programación Grok Build de xAI estaba subiendo repositorios Git completos, con todo el historial de commits incluido, a un bucket de Google Cloud Storage gestionado por xAI, y no solo los archivos necesarios para una tarea de programación.

Un investigador que publica como cereblab [enlace], probando la versión 0.2.93, capturó una de esas subidas, clonó el paquete git de la solicitud interceptada y recuperó un archivo que se le había indicado al agente, en términos claros, que no abriera.

La subida utilizaba un canal independiente del modelo en sí, y la diferencia de bytes es irrefutable. En un repositorio de archivos de 12 GB que el modelo nunca leyó, el tráfico del turno del modelo hacia /v1/responses fue de unos 192 KB, mientras que el canal de almacenamiento hacia /v1/storage movió 5.10 GiB, una brecha de aproximadamente 27,800 veces entre lo que el modelo necesitaba y lo que salió de la máquina.

Esa subida de almacenamiento se ejecutó como 73 fragmentos de unos 75 MB, cada uno devolviendo un HTTP 200, y el volumen rastreado coincidía con el tamaño total del repositorio. El bucket de destino, grok-code-session-traces, aparece nombrado en el binario y en un archivo metadata.json cuyas rutas por archivo apuntan a gs://grok-code-session-traces/.

El archivo no leído era src/_probe/never_read_canary.txt, plantado con un marcador único. Al clonar el paquete capturado se recuperó textualmente junto con el historial completo de commits del repositorio, y la misma prueba se replicó en un segundo repositorio no relacionado. Lo que establecen las capturas es la transmisión, aceptación y almacenamiento, no el entrenamiento.

El análisis no afirma que xAI haya entrenado con el código, que el personal lo haya leído o que los archivos ignorados por git se incluyan siempre. Lo que muestra el tráfico son los archivos rastreados más el historial.

La ruta de los secretos es independiente y más sencilla. Cuando Grok lee un archivo, su contenido va al turno del modelo, y un archivo .env rastreado fue con ellos sin censura, incluyendo valores de API_KEY y DB_PASSWORD de prueba. El mismo contenido también aterrizó en un archivo de session_state destinado al almacenamiento. Los secretos plantados eran falsos, por lo que no se filtró nada real en la prueba. El comportamiento sigue siendo el problema: un archivo de credenciales que el agente leyó durante una tarea salió y fue almacenado sin censura.

El ajuste al que recurrirían la mayoría de los desarrolladores no sirvió de nada aquí. Con la opción "Mejorar el modelo" desactivada, Grok siguió subiendo el repositorio, y la respuesta de /v1/settings del servidor seguía devolviendo trace_upload_enabled: true. Ese interruptor controla si tus datos entrenan el modelo, no controla si tu código sale de la máquina. Son dos controles diferentes y solo uno estaba expuesto al usuario.

Cada agente de programación en la nube debe enviar parte del código fuente a un modelo remoto para hacer su trabajo, por lo que el primer canal es esperado. Enviar todo el repositorio rastreado y su historial es un límite mucho más amplio que enviar solo los archivos que necesita una tarea.

Un repositorio puede contener código propietario, URLs internas, datos de clientes y credenciales que fueron eliminadas del árbol de trabajo pero que siguen estando en el historial de commits. En la comparación de herramientas de cereblab [enlace], Claude Code y Codex no enviaron ningún paquete de repositorio; Gemini no envió ninguno en una prueba inactiva, aunque su ejecución de tarea realista fue bloqueada por cuota antes de terminar.

Grok Build fue la excepción. Siguen siendo herramientas en la nube que envían los archivos que abren, por lo que el concepto de "solo local" es erróneo para cualquiera de ellas. Pero la recolección masiva del espacio de trabajo fue específica de Grok Build.

Respuesta de xai

El 13 de julio, el mismo binario 0.2.93 dejó de hacer solicitudes de almacenamiento. cereblab volvió a probar seis veces y vio cero subidas a /v1/storage, y el servidor ahora devolvía disable_codebase_upload: true y trace_upload_enabled: false.

El desarrollador Peter Dedene informó que la misma bandera se devolvía para su cuenta [enlace], por lo que el cierre no fue solo una observación de la máquina de cereblab. El cliente probado se mantuvo en la versión 0.2.93 mientras que la configuración del servidor cambiaba, por lo que se trató de un interruptor del lado del servidor, no de un arreglo enviado en una actualización. xAI no ha confirmado si afecta a todas las cuentas o si es permanente.

xAI ha abordado el problema hasta ahora en X en lugar de a través de un aviso de seguridad o una nota de registro de cambios. La cuenta @SpaceXAI [enlace] dijo que los equipos empresariales con retención cero de datos nunca tienen código o datos de traza almacenados, que el uso de la clave API respeta el ZDR y que los consumidores que no lo hayan activado pueden ejecutar /privacy en la CLI para desactivar la retención y eliminar los datos sincronizados anteriormente.

Elon Musk fue más allá, diciendo [enlace] que todos los datos de usuario subidos hasta ahora serían "completamente y totalmente eliminados", sin dejar rastro. El ZDR cubre a los equipos empresariales y el uso de la API, por lo que para los suscriptores individuales el comando /privacy es el control ofrecido.

Para cualquiera que ya haya ejecutado la herramienta, la recomendación es no esperar a xAI. Rota cualquier credencial que Grok pudiera haber enviado: cualquier cosa que haya leído, cualquier cosa en un archivo rastreado y cualquier cosa en el historial de git que el paquete llevara, incluyendo un secreto que hayas subido y luego borrado.

Un archivo que estaba en gitignore y nunca fue subido se quedó fuera del paquete. Uno subido viajó en el historial, y borrarlo más tarde no lo recupera. Un análisis independiente de la versión 0.2.99 [enlace] encontró que el código de subida todavía estaba en el binario, retenido por la bandera del servidor, por lo que xAI puede volver a activarlo sin una actualización.

Y todavía no ha dicho por qué se subían repositorios completos por defecto, cuánto tiempo se guardaron o cuántos usuarios se vieron afectados. Una opción de exclusión de entrenamiento no es una promesa de que tu código se quede en tu máquina, y lo que sale de ella vale la pena que lo compruebes tú mismo.

Fuente:
THN