Grok Build, el asistente de programación de SpaceXAI, habría enviado repositorios completos a una infraestructura cloud controlada por la empresa aunque el modelo no necesitara consultar esos archivos para responder. El comportamiento fue detectado por investigadores que analizaron el binario oficial y realizaron pruebas controladas, tras las que SpaceXAI desactivó remotamente la función y prometió borrar los datos recopilados.
Las claves del caso Grok Build en 30 segundos
- El cliente habría empaquetado y enviado archivos y objetos de Git en segundo plano, al margen de las herramientas autorizadas por el usuario.
- La recopilación podía incluir código borrado del directorio actual, pero todavía conservado en el historial del repositorio.
- SpaceXAI desactivó las transferencias mediante una configuración remota, sin exigir una actualización del programa.
- La empresa sostiene que los clientes con retención cero no conservaron datos y ha prometido eliminar el material subido anteriormente.
- Sigue sin saberse cuántos usuarios fueron afectados ni cómo podrán verificar el borrado.
El investigador Hari Krishnan aseguró el 13/07/2026 que había aplicado ingeniería inversa a la versión 0.2.99 del binario oficial. En una sesión preparada sin llamadas a herramientas, acceso mediante terminal ni peticiones del modelo para leer archivos, observó un proceso independiente que reunía el contenido del repositorio y lo enviaba a almacenamiento cloud. Sus conclusiones coinciden con las pruebas difundidas por Cereblab y con la información contrastada posteriormente por varios medios tecnológicos.
El caso no demuestra que SpaceXAI utilizara deliberadamente el código para entrenar modelos ni que terceros accedieran a los repositorios. Sí plantea una cuestión más inmediata: el cliente habría extraído bastante más información de la necesaria para responder a las solicitudes del desarrollador, sin que el sistema de permisos para herramientas ofreciera una señal clara de esa transferencia.
El problema no era que un modelo necesitara leer código
Los asistentes de programación alojados en la nube necesitan recibir algún tipo de información para analizar una función, corregir un error o proponer cambios. Cuando el desarrollador pide revisar un archivo, resulta normal que su contenido viaje hasta los servidores donde se ejecuta el modelo, salvo que la herramienta utilice inferencia local.
La diferencia está en el alcance y en el momento de la transferencia. Según las pruebas publicadas, Grok Build no se limitaba a enviar los fragmentos solicitados por el usuario o seleccionados por el agente. Un componente en segundo plano habría recorrido el repositorio completo y preparado los datos sin depender de las llamadas a herramientas visibles en la conversación.
Krishnan sostiene que el proceso incluía todos los archivos rastreados en el HEAD actual de Git y todos los objetos alcanzables desde ese punto. Esa segunda categoría puede contener versiones anteriores de los archivos, ramas integradas y contenidos que ya no aparecen en el directorio de trabajo.
Esta diferencia importa porque borrar una contraseña, una clave de una interfaz de programación de aplicaciones (API) o un certificado del último commit no significa que haya desaparecido del repositorio. El secreto puede seguir almacenado dentro de la base de objetos de Git y recuperarse consultando el historial.
Según Cereblab, una de sus pruebas detectó una transferencia de 5,1 GB para una tarea que solo necesitaba acceder a unos 192 KB. La cantidad enviada habría sido unas 26.000 veces superior al contexto requerido para completar la petición concreta.
Los investigadores también afirman que se incluyeron archivos que el agente no había recibido permiso para abrir y secretos eliminados de la versión actual, pero conservados en el historial. SpaceXAI no ha publicado por ahora un análisis técnico detallado que delimite exactamente qué versiones, configuraciones y tipos de repositorio activaban esa recopilación.
Calificar el componente como malware exige prudencia. La expresión “malware-like”, utilizada por el investigador, describe un comportamiento silencioso y externo al sistema de permisos, pero no prueba por sí sola una intención maliciosa. El problema puede proceder de una función de indexación, sincronización o telemetría diseñada para ofrecer contexto al asistente y desplegada con controles insuficientes.
Desde la perspectiva de seguridad, la intención no elimina el riesgo. Un agente autorizado para procesar un archivo concreto no debería interpretar ese permiso como autorización para copiar toda la propiedad intelectual de una empresa, especialmente cuando la recopilación alcanza información que el usuario creía haber borrado.
SpaceXAI recurrió a un interruptor remoto
Las pruebas posteriores indicaron que la subida dejó de ejecutarse sin que los usuarios instalaran una nueva versión. El servidor comenzó a devolver los ajustes disable_codebase_upload=true y trace_upload_enabled=false, lo que apunta a la activación de un interruptor remoto.
Ese mecanismo permite reaccionar con rapidez ante un fallo, pero introduce otra cuestión para los responsables de seguridad: el comportamiento del binario instalado puede cambiar según la configuración recibida desde los servidores del proveedor. Analizar una versión una sola vez no basta para conocer todas las funciones que puede activar en el futuro.
Krishnan señaló que el código del recopilador continuaba presente en el binario 0.2.99 aunque estuviera deshabilitado. Esto tampoco implica que vuelva a utilizarse, pero obliga a diferenciar entre retirar una función del programa y apagarla mediante una bandera administrada por la empresa.
SpaceXAI respondió que protege la elección de sus clientes y que las organizaciones acogidas a políticas de retención cero de datos, conocidas como Zero Data Retention (ZDR), no conservan trazas ni código. También indicó que el comando /privacy permite desactivar la retención cuando ZDR no está habilitado.
Los investigadores cuestionaron que ese comando resolviera el problema descrito. Según su análisis, /privacy actuaba como una preferencia de retención asociada a la sesión, mientras que la transferencia del repositorio fue detenida por la configuración remota aplicada posteriormente.
Elon Musk aseguró que los datos subidos con anterioridad serían eliminados por completo. Esa promesa reduce el alcance potencial del incidente si se ejecuta como se ha anunciado, pero no existe todavía un procedimiento público para que cada cliente compruebe qué se transfirió, cuánto tiempo permaneció almacenado, quién pudo acceder o si las copias de respaldo también fueron eliminadas.
Tampoco se conoce el número de instalaciones afectadas, durante cuánto tiempo estuvo activa la función o si el comportamiento variaba según el tipo de cuenta. Estas preguntas son especialmente importantes para empresas sujetas a obligaciones contractuales, secretos industriales, normas sectoriales o restricciones sobre la localización de los datos.
Qué deberían revisar los equipos que utilizaron Grok Build
La primera medida no debería limitarse a borrar el programa. Las organizaciones que ejecutaron versiones afectadas necesitan asumir, hasta que puedan descartarlo, que el historial Git pudo abandonar sus equipos.
Esto implica revisar secretos presentes y pasados. Una credencial eliminada hace meses del código puede seguir siendo válida si nunca se revocó. Las empresas deberían buscar claves de API, tokens de acceso, contraseñas de bases de datos, certificados, variables de despliegue y credenciales cloud dentro de todo el historial, no solo en la rama actual.
Cuando exista alguna posibilidad de exposición, la respuesta más segura es rotar la credencial. La eliminación prometida por el proveedor no revoca una clave ni impide que una copia haya quedado registrada en otro sistema de procesamiento, observabilidad o respaldo.
Los equipos también pueden revisar registros de cortafuegos, proxies corporativos, herramientas de detección y respuesta en endpoints y controles de prevención de pérdida de datos. El objetivo es identificar conexiones, volúmenes transferidos y destinos utilizados por el cliente durante el periodo investigado.
En entornos sensibles, los asistentes de programación deberían ejecutarse con controles similares a los aplicados a cualquier software con capacidad de leer código: aislamiento, permisos mínimos, filtrado de salida, repositorios de prueba y exclusión explícita de secretos. Instalar una herramienta mediante un gestor de paquetes conocido no elimina la necesidad de supervisar qué datos transmite.
Las políticas internas también deben distinguir entre el contenido que el usuario pega en un chat, los archivos que autoriza al agente a abrir y la información recopilada automáticamente por funciones de indexación o telemetría. Una interfaz puede ofrecer permisos detallados mientras otro componente del mismo cliente opera fuera de ellos.
El incidente de Grok Build expone una debilidad más amplia en los agentes de desarrollo. La mayoría se presenta como una extensión del editor o del terminal, pero técnicamente puede combinar ejecución de comandos, lectura de archivos, acceso a Git, telemetría, sincronización cloud y cambios administrados remotamente.
La confianza no puede apoyarse únicamente en el modelo de inteligencia artificial. También depende del binario, de sus bibliotecas, de la infraestructura del proveedor y de configuraciones que el usuario quizá no llegue a ver.
Preguntas frecuentes
¿Grok Build sigue subiendo repositorios completos?
Las pruebas posteriores indican que SpaceXAI desactivó la función mediante una configuración remota. El código relacionado seguiría presente en la versión 0.2.99, según el investigador, pero la transferencia ya no se activaba en sus comprobaciones.
¿Se enviaban archivos borrados?
Podían enviarse contenidos eliminados del directorio actual si seguían presentes en objetos alcanzables del historial de Git. Borrar un archivo en un commit nuevo no elimina automáticamente sus versiones anteriores.
¿La política de retención cero evitaba la subida?
SpaceXAI sostiene que las cuentas con Zero Data Retention no conservaron trazas ni código. Sin más información técnica, no está claro si los datos nunca llegaron al almacenamiento, se procesaron temporalmente o se subieron y fueron eliminados inmediatamente.
¿Qué deben hacer las empresas que utilizaron Grok Build?
Deben revisar el historial completo de sus repositorios, rotar credenciales potencialmente expuestas, analizar registros de tráfico y solicitar al proveedor información sobre los datos transferidos y eliminados.
