TL;DR:
- xAI (ahora SpaceXAI) publicó este 15 de julio el código completo de Grok Build en GitHub bajo licencia Apache 2.0, tres días después de que estallara la polémica por la herramienta.
- Un investigador independiente identificado como Cereblab documentó que Grok Build subía repositorios enteros (con historial de Git y contraseñas incluidas) a un bucket de Google Cloud, incluso cuando el modelo no llegaba a leer esos archivos.
- Elon Musk prometió borrar los datos ya subidos, pero nadie lo ha confirmado de forma independiente, y el propio código publicado conserva restos de la función que causó el problema.
Grok Build, el agente de programación para terminal de SpaceXAI (el nombre que adoptó xAI tras fusionarse con SpaceX en febrero), es ahora de código abierto. La compañía publicó este 15 de julio todo el código fuente de la herramienta en GitHub bajo licencia Apache 2.0, apenas tres días después de que un investigador independiente revelara que el programa subía repositorios de código completos, con historial de Git y contraseñas incluidas, a un servidor en la nube de la empresa sin que el usuario lo supiera. La revelación provocó un rechazo inmediato entre desarrolladores, obligó a Elon Musk a prometer públicamente el borrado de los datos recolectados y llevó a la compañía a apagar la función antes de decidir abrir el código por completo.
192 kilobytes contra 5.1 gigabytes: la prueba que expuso a Grok Build
Todo empezó el 12 de julio, cuando un investigador de seguridad independiente que se identifica como Cereblab publicó un análisis técnico del tráfico de red de la versión 0.2.93 de Grok Build. Con la herramienta mitmproxy para interceptar las conexiones del programa, montó una prueba sencilla: le pidió al agente que respondiera "OK" y no leyera ningún archivo. El agente cumplió. No leyó nada. Pero, por detrás, el programa subió de todas formas una copia completa del repositorio a un espacio de almacenamiento en la nube de Google (un bucket) llamado grok-code-session-traces.
La cifra es lo que volvió viral el hallazgo. En un repositorio de prueba de 12 gigabytes, la conversación real con el modelo generó apenas 192 KB de tráfico. El canal de subida en segundo plano, en cambio, envió 5.1 GB en 73 fragmentos de unos 75 megabytes cada uno, antes de que la propia prueba se interrumpiera por un límite de uso. Es una diferencia de 27,800 veces entre lo que el modelo necesitaba para trabajar y lo que en realidad salió de la máquina.
Para probarlo sin dejar dudas, Cereblab sembró en el repositorio un archivo con instrucciones explícitas de no abrirlo. El paquete de Git subido a la nube lo traía de todas formas, marcador incluido, junto con contraseñas y llaves de prueba guardadas en un archivo de configuración típico (.env) que también viajaron sin cifrar. Como el paquete incluye el historial completo de Git, cualquier secreto que un desarrollador haya subido por error y luego borrado del repositorio pudo haber viajado igual a los servidores de la empresa.
La bandera silenciosa detrás del verdadero arreglo
El hallazgo llegó a la portada de Hacker News y desató lo que Simon Willison, desarrollador de software y autor de un blog influyente sobre inteligencia artificial, describió como un rechazo severo entre programadores. Dos integrantes del equipo técnico de la empresa, Andrew Milich y Jason Ginsberg, salieron a responder en redes sociales: aseguraron que los usuarios con retención cero de datos (ZDR) nunca habían tenido información almacenada y que el comando /privacy permitía desactivar la retención en cualquier momento.
Esa versión no resistió la prueba técnica. Cereblab comprobó que activar /privacy cambiaba solo una configuración de retención, no el envío mismo de los archivos: el paquete de Git seguía saliendo de la máquina con el comando encendido o apagado. Lo que de verdad detuvo la subida fue otra cosa, según relató a The Register:
"Lo que realmente detuvo la subida fue una bandera global silenciosa", explicó Cereblab.
Esa bandera, llamada disable_codebase_upload, se activó del lado del servidor el 13 de julio, un día después de la publicación del hallazgo, sin aviso de seguridad ni nota de cambios. Musk se sumó a la conversación con una promesa personal en X que Willison recogió en su blog:
"Todos los datos subidos a SpaceXAI hasta ahora serán borrados por completo", escribió Musk.
En un mensaje aparte, sin embargo, el propio Musk pidió a los usuarios que siguieran compartiendo información con la herramienta, con el argumento de que conservar "algo" de datos ayuda a depurar errores. Hasta la fecha de esta nota, nadie ha confirmado de forma independiente que el borrado prometido se haya completado.
Qué hay dentro del código que la compañía acaba de publicar
El repositorio publicado en GitHub contiene 844,530 líneas de código en Rust, según el conteo de Willison, quien usó su herramienta SLOCCount (que descarta espacios en blanco y comentarios) para medirlo. Como referencia, el CLI de código de OpenAI, Codex, suma 950,933 líneas. Solo el 3% del código de Grok Build proviene de librerías de terceros.
El código guarda, además, un par de sorpresas. Parte de sus herramientas internas están adaptadas de otros agentes: funciones como apply_patch, grep_files, list_dir y read_dir vienen de Codex, mientras que bash, edit, glob, grep, read, skill, todowrite y write están tomadas de OpenCode, otro agente de programación de código abierto, con la atribución de licencia correspondiente en el archivo THIRD_PARTY_NOTICES.md. Willison notó también una asimetría curiosa: el prompt del subagente le indica explícitamente al modelo que no revele su propio contenido al usuario, una instrucción que el prompt principal no tiene.
Más relevante para el episodio de esta semana: el código que subía archivos a Google Cloud (en los archivos gcs.rs y trace.rs) sigue presente en el repositorio recién publicado.
Musk extiende la promesa de código abierto a toda la plataforma X
El episodio también empujó una promesa más amplia. Musk anunció en un mensaje en X que la plataforma haría pública toda su base de código, según reportó The American Bazaar. El anuncio llegó después de que el director ejecutivo de OpenAI, Sam Altman, calificara el comportamiento de Grok Build como "preocupante".
No es la primera vez que Musk promete abrir el código de X: en 2023 la compañía liberó partes del algoritmo de recomendaciones de Twitter, y a inicios de este año anunció que también publicaría el sistema de clasificación de anuncios. Esta vez no dio un calendario ni precisó qué partes de la infraestructura, la seguridad o los sistemas comerciales de X quedarían fuera del anuncio.
Para cualquier desarrollador que haya usado Grok Build antes del 13 de julio en un proyecto real, la recomendación práctica no depende de que la compañía confirme nada: conviene rotar cualquier contraseña o llave de API que haya pasado por ese repositorio, incluidas las que ya se habían borrado del código pero seguían vivas en el historial de Git. El código ya es público. Cualquiera puede revisarlo línea por línea. Lo que todavía no es público es un reporte que confirme, con evidencia verificable, qué pasó exactamente con los datos que ya viajaron a los servidores de la empresa antes de que se apagara la función.
Preguntas rápidas sobre Grok Build
¿Grok Build todavía sube mis archivos a la nube de SpaceXAI?
No. La compañía desactivó la subida automática de repositorios el 13 de julio de 2026 mediante un cambio del lado del servidor. Cereblab confirmó en pruebas posteriores que el envío masivo de archivos se detuvo, aunque el mecanismo que lo activaba sigue presente en el código publicado.
¿Debo cambiar mis contraseñas si usé Grok Build antes del 13 de julio?
Cereblab, quien documentó el caso, recomienda rotar cualquier contraseña o llave de API que haya estado en un repositorio abierto con la herramienta, incluidas las que ya se habían eliminado del código pero seguían guardadas en el historial de Git.
¿Qué cambia con que Grok Build ahora sea de código abierto?
Cualquier persona puede leer, compilar y modificar el programa desde GitHub bajo licencia Apache 2.0, incluidas empresas y desarrolladores independientes. También se puede correr de forma local, conectado a un modelo propio, sin depender de los servidores de la compañía para procesar el código.
