TL;DR:

• Grok Build, el agente de línea de comandos de SpaceXAI, subía por defecto repositorios de Git completos, con todo su historial, a un bucket de Google Cloud, incluso cuando se le ordenaba no leer los archivos.
• Según el investigador cereblab, en un repositorio de 12 GB el canal de almacenamiento movió 5.10 GiB frente a 192 KB del modelo, y un archivo .env viajó con sus claves sin ocultar.
• Las subidas se detuvieron el 13 de julio por una bandera del servidor, no por el comando /privacy; Elon Musk prometió borrar "completa y absolutamente" todo lo que ya se había enviado.

El agente de programación por línea de comandos de SpaceXAI, Grok Build, estuvo subiendo repositorios de Git completos, con todo su historial, a un bucket de Google Cloud controlado por la compañía de inteligencia artificial de Elon Musk (antes xAI), y no solo los archivos que una tarea concreta necesitaba. Lo documentó el investigador de seguridad que publica bajo el alias cereblab, que interceptó una de esas subidas, reconstruyó el repositorio a partir del tráfico capturado y recuperó incluso un archivo que le había pedido de forma explícita al agente no abrir. El desglose circuló durante el fin de semana y apunta a algo más incómodo que un descuido: el interruptor de privacidad que la mayoría de los desarrolladores usaría no frenaba esas subidas. Las transferencias se cortaron el 13 de julio y Musk prometió eliminar todo lo que ya se había enviado.

El desglose técnico, realizado sobre la versión 0.2.93 del cliente, deja poco margen a la interpretación. En un repositorio de 12 GB cuyos archivos el modelo nunca llegó a leer, el tráfico hacia el modelo sumó unos 192 KB, mientras que el canal de almacenamiento movió 5.10 GiB. Es una diferencia de cerca de 27,800 veces entre lo que la tarea necesitaba y lo que salió del equipo. Esa carga viajó en 73 fragmentos de unos 75 MB, todos aceptados por el servidor, hacia un bucket llamado grok-code-session-traces que aparece nombrado en el propio binario.

Para comprobar que se trataba del repositorio entero y no de fragmentos sueltos, cereblab plantó un archivo señuelo, con un marcador único, y le indicó al agente que no lo abriera. Al clonar el paquete capturado, recuperó ese archivo tal cual, junto con el historial completo de commits del proyecto. Repitió el experimento en un segundo repositorio, sin relación con el primero, con el mismo resultado. Dos usuarios de Grok Build dijeron a The Stack que, tras revisar sus registros, creen haber visto cómo se enviaban repositorios privados sin su conocimiento.

El hallazgo pide algo de contexto. Cualquier agente de programación en la nube tiene que enviar algo de código a un modelo remoto para funcionar: ese primer canal es esperable. Lo que llama la atención en Grok Build es el tamaño de la frontera. En vez de mandar los archivos que la tarea toca, mandaba el repositorio rastreado por Git al completo, con su historia. En la comparación que cereblab hizo con otras herramientas, el contraste fue claro:

• Claude Code y Codex no enviaron ningún paquete del repositorio.
• Gemini tampoco lo hizo en una prueba en reposo, aunque su ejecución con una tarea real se quedó sin cuota antes de terminar.
• Grok Build fue la excepción.

Aun así, todas son herramientas en la nube que envían los archivos que abren, así que "solo local" es una idea equivocada para cualquiera de ellas. Lo que fue propio de Grok Build fue recolectar el espacio de trabajo entero.

El interruptor de privacidad no frenaba las subidas

Aquí está el punto más delicado para los usuarios. Con la opción "Improve the model" desactivada, la que cualquiera tocaría para proteger su código, Grok Build seguía subiendo el repositorio. La propia respuesta de configuración del servidor mantenía encendida la subida de trazas. Ese interruptor decide si tus datos entrenan al modelo. No decide si tu código sale de tu máquina. Son dos controles distintos, y al usuario solo se le mostraba uno.

Claves y secretos salieron sin ocultar

El caso de los secretos es más simple y, por eso mismo, más incómodo. Cuando Grok lee un archivo, su contenido entra en el turno del modelo. Un archivo .env rastreado se fue así, con sus valores de clave de API y contraseña de base de datos sin ninguna capa que los tapara, y una copia acabó también en el paquete que iba al almacenamiento. Los secretos que cereblab colocó eran falsos, de modo que en la prueba no se filtró nada real. El problema no es ese: es que un archivo de credenciales que el agente leyó durante una tarea salió del equipo y quedó guardado sin redacción.

Conviene marcar el límite de lo que se demostró. Lo que las capturas prueban es la transmisión, la aceptación y el almacenamiento de ese código. No prueban que SpaceXAI lo haya usado para entrenar, ni que alguien de la empresa lo haya leído. El análisis se ciñe a lo que se ve en el cable: archivos rastreados más historial.

Las subidas se detuvieron, pero no por el comando /privacy

El 13 de julio, ese mismo binario 0.2.93 dejó de hacer peticiones de almacenamiento. cereblab repitió la prueba seis veces y no vio ninguna subida nueva; el servidor empezó a devolver la subida de código como deshabilitada. El desarrollador Peter Dedene reportó el mismo cambio en su cuenta, así que no fue una observación aislada de una sola máquina. Y como el cliente no cambió de versión mientras las opciones del servidor sí lo hicieron, el corte vino de una bandera del lado del servidor, no de una actualización de la aplicación.

Eso tiene una consecuencia práctica: nada de esto ocurrió porque los usuarios corrieran el comando de privacidad. Un análisis aparte de una compilación posterior, la 0.2.99, encontró que el código de subida seguía dentro del binario, contenido solo por esa bandera del servidor. Dicho de otro modo, SpaceXAI puede volver a activarlo sin publicar una actualización. La empresa no ha aclarado si el corte llega a todas las cuentas ni si es permanente.

Musk promete borrar "completa y absolutamente" lo subido

SpaceXAI respondió en X, no con un aviso de seguridad ni una nota de cambios. Desde su cuenta, la empresa sostuvo que los equipos con Retención Cero de Datos (ZDR) nunca tienen su código ni sus trazas almacenados, que el uso con clave de API respeta ese modo, y que quienes no lo tienen activado pueden correr el comando /privacy en la interfaz para desactivar la retención y borrar los datos ya sincronizados.

Musk fue más lejos. Primero comentó que retener cierta cantidad de datos ayuda a depurar problemas y, después, aseguró que lo ya subido se borraría:

"Como medida de precaución, todos los datos de usuarios que se subieron a SpaceXAI hasta ahora serán completa y absolutamente eliminados. No quedará absolutamente nada."

Para las empresas, la ZDR ya cubre los equipos y el uso por API. Para el usuario individual, el control que queda sobre la mesa es ese comando /privacy.

Lo que SpaceXAI todavía no ha explicado pesa tanto como lo que sí reconoció. No ha dicho por qué se subían repositorios completos por defecto, cuánto tiempo se guardaron ni a cuántos usuarios alcanzó, y ha llevado el asunto por X en lugar de por un canal de seguridad. Para quien programa en español y probó la herramienta, el mensaje es concreto: conviene rotar credenciales y no confundir el permiso de entrenamiento con el destino del código. Esta semana dejó claro por qué esa distinción importa en la práctica.

Fuentes: 1, 2, 3