Tu código ya no es tuyo: Grok Build subía repositorios enteros a la nube sin que lo supieras

La noticia original la publicó The Verge, recogiendo una investigación de The Register sobre cómo Grok Build, la CLI de programación de SpaceXAI, estaba subiendo el código de sus usuarios a servidores en la nube sin autorización explícita.

26.000 veces más datos de los necesarios

Imagina que entras a una cafetería a pedir un café con leche y, mientras esperas, el camarero va a tu casa, fotocopia todos tus documentos, los mete en una caja y los envía a un almacén en otro país. Eso es, básicamente, lo que hacía Grok Build cada vez que un desarrollador le pedía ayuda con un archivo.

La investigación de Cereblab reveló un dato que parece sacado de una pesadilla de seguridad informática: en una prueba controlada, Grok Build necesitaba apenas 192 kilobytes de código para completar una tarea. Sin embargo, subió 5,1 gigabytes a un bucket de Google Cloud Storage. Eso son 26.000 veces más datos de los estrictamente necesarios. No es un error de redondeo. Es un festín de datos disfrazado de asistente de programación.

El botón de privacidad que no privaba nada

Lo más siniestro del asunto es que Grok Build tenía un comando /privacy que, en teoría, permitía al usuario controlar la retención de datos. En la práctica, ese interruptor era decorativo. Un placebo digital. El comando solo afectaba a la retención por sesión, no al mecanismo de subida masiva de repositorios. Era como poner un candado en una puerta que no tiene pared.

Algunos usuarios descubrieron que la herramienta no solo subía el repositorio en el que estaban trabajando, sino que accedía a directorios completos del sistema. Claves SSH, bases de datos de gestores de contraseñas, archivos de configuración privados: todo empaquetado en bundles de Git y enviado alegremente a los servidores de SpaceXAI.

El parche silencioso y la promesa nuclear

Una vez que el escándalo saltó a la luz, la respuesta fue rápida pero reveladora. Los desarrolladores de Grok Build activaron una variable llamada disable_codebase_upload estableciéndola en true. Así, sin más. Una línea de código que sugiere que la funcionalidad de subida masiva no era un bug, sino una feature que alguien decidió dejar activada por defecto.

Elon Musk prometió la eliminación total de todos los datos de usuario subidos antes de la corrección. “Como medida preventiva, todos los datos de usuario subidos a SpaceXAI serán completa y absolutamente eliminados”, declaró. Una frase que suena contundente hasta que recuerdas que estamos hablando de la misma empresa que renombró Twitter a X porque sí.

El problema no es Grok, es el modelo

Sería fácil señalar a Grok Build como el villano de esta historia y seguir adelante. Pero el problema de fondo es mucho más estructural. Las herramientas de programación asistida por IA —Grok Build, GitHub Copilot, Cursor, Claude Code— operan en un territorio donde la línea entre “analizar tu código para ayudarte” y “absorber tu código para entrenar modelos” es tan fina que a veces desaparece.

La pregunta incómoda que nadie quiere hacerse es: ¿cuántas herramientas de IA están haciendo exactamente lo mismo pero sin que nadie las haya pillado todavía?

El modelo de negocio de la IA generativa tiene una dependencia insaciable de datos. Y el código fuente es uno de los datasets más valiosos que existen: estructurado, documentado, lleno de lógica de negocio y patrones arquitectónicos. Para una empresa de IA, un repositorio privado es oro molido. La tentación de “aspirar” más de lo necesario no es un accidente, es una consecuencia natural de los incentivos del mercado.

La confianza del desarrollador, en terapia intensiva

Este incidente llega en un momento en que la adopción de asistentes de código IA está en plena explosión. Según datos recientes, más del 70%% de los desarrolladores profesionales utilizan algún tipo de herramienta de IA en su flujo de trabajo diario. Y la mayoría lo hace con una confianza implícita que este tipo de escándalos erosiona de forma irreversible.

El contrato social tácito entre un desarrollador y su herramienta de IA es simple: te doy acceso a mi código para que me ayudes, no para que te lo lleves. Grok Build rompió ese contrato de la forma más espectacular posible: no solo se llevó el código, sino que cogió todo el directorio, incluyendo las llaves de la casa.

Ahora bien, ¿qué puede hacer un desarrollador? Primero, leer las políticas de privacidad de las herramientas que usa (sí, esas que nadie lee). Segundo, auditar el tráfico de red de sus herramientas de desarrollo. Tercero, y más importante: exigir transparencia radical. Si una herramienta necesita enviar datos a un servidor, que lo diga claramente, que pida permiso explícito y que el alcance del envío sea proporcional a la tarea.

El futuro se programa con desconfianza

Hay una ironía deliciosa en que una herramienta diseñada para hacer a los programadores más productivos acabe siendo la que les enseñe la lección más importante de la ingeniería de software moderna: nunca confíes en código que no puedes auditar. Ni siquiera si ese código promete escribir código por ti.

El escándalo de Grok Build no será el último de su tipo. Es, probablemente, el primero de muchos. A medida que las herramientas de IA se integren más profundamente en los flujos de desarrollo, la superficie de ataque —y de abuso— se expandirá proporcionalmente. La pregunta ya no es si tu asistente de código está mirando tus archivos. La pregunta es a dónde los está mandando.