Canario en el repositorio: Grok Build expuso repos completos y secretos en la nube

Un investigador que firma como cereblab descubrió que la herramienta Grok Build de xAI estaba subiendo repositorios Git completos —incluyendo todo el historial de commits— a un bucket de Google Cloud Storage gestionado por xAI, y no sólo los ficheros que la tarea de codificación necesitaba. En una prueba con la versión 0.2.93 se creó una captura de una de esas subidas: a pesar de que el tráfico hacia el modelo (la petición a /v1/responses) contenía apenas cientos de kilobytes, el canal de almacenamiento (/v1/storage) envió varios gigabytes, reflejando directamente el tamaño del repositorio en disco y reproduciendo la historia de commits en un bundle que pudo clonarse.

Los detalles técnicos son relevantes porque definen la exposición: en el experimento con un repositorio de 12 GB, la comunicación con el modelo fue de aproximadamente 192 KB mientras que la subida a almacenamiento movió ~5,10 GiB en bloques de ~75 MB que devolvían HTTP 200. En concreto, los metadatos indicaban como destino un bucket llamado grok-code-session-traces y la captura permitió extraer un archivo plantado intencionadamente por el investigador —un “canario” que el agente no debía abrir— junto con todo el historial Git. Separadamente, cuando Grok abrió un archivo .env, su contenido viajó sin redacción en la interacción con el modelo y también quedó archivado en la sesión.

Es importante subrayar qué prueban y qué no prueban estas capturas: prueban transmisión, aceptación y almacenamiento de los datos fuera de la máquina cliente; no prueban que xAI haya entrenado modelos con ese material ni que empleados humanos lo hayan leído. Sin embargo, el hecho de que credenciales o secretos leídos por el agente pudieran salir sin redacción es en sí mismo un riesgo operativo grave para desarrolladores y organizaciones.

El incidente puso además de manifiesto una confusión de controles: la opción llamada "Improve the model" (u opciones similares) controla si tus datos pueden usarse para entrenamiento, pero no necesariamente si tus ficheros salen del equipo hacia almacenamiento controlado por el proveedor. En las observaciones de cereblab el ajuste de “mejora del modelo” estaba desactivado, pero el servidor seguía devolviendo trace_upload_enabled: true, lo que explicaría que el envío y almacenamiento ocurriera a pesar del opt‑out de entrenamiento.

Tras la publicación, xAI cambió los flags del servidor y las pruebas repetidas mostraron que las subidas cesaron y que el servidor devolvía disable_codebase_upload: true y trace_upload_enabled: false. Esa desactivación vino desde el lado del servidor, no como un parche en la versión del cliente, así que técnicamente xAI podría volver a habilitar la subida sin que los usuarios actualicen sus binarios. La compañía ha respondido públicamente en su canal X/SpaceXAI con explicaciones sobre equipos enterprise con políticas de “zero data retention” y comandos de privacidad en la CLI, pero siguen sin dar detalles públicos claros sobre cuánto tiempo se conservaron los datos ni a cuántos usuarios afectó el comportamiento.

Frente a este tipo de exposición la recomendación práctica inmediata es clara: actúa como si tus secretos hubieran salido. Rota cualquier credencial que el agente pudiera haber leído o que pudiera encontrarse en la historia de commits —incluso si la clave fue borrada del árbol de trabajo, si estuvo alguna vez en un commit formó parte del bundle y puede haber sido subida—. No basta con borrar localmente: hay que invalidar las credenciales, emitir nuevas claves con alcance restringido y revisar logs externos.

Además, revisa y limpia el historial Git para eliminar secretos persistentes y evitar que sigan exponiéndose en clones o backups. Herramientas como BFG Repo-Cleaner o los procedimientos oficiales de GitHub para eliminar datos sensibles ayudan a reescribir historia y purgar secretos del repositorio, pero requieren cuidado porque reescribir historia afectará a colaboradores y forks; la documentación oficial de GitHub sobre el tema es un buen punto de partida: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository. Para limpieza masiva de grandes repositorios existe BFG: https://rtyley.github.io/bfg-repo-cleaner/.

No confíes sólo en toggles o promesas de “no usar para entrenamiento”: audita qué datos salen realmente. Si usas agentes de codificación en la nube, monitoriza tráfico saliente y revisa las peticiones que crean bundles o archivan sesiones; en entornos controlados considera proxies que inspeccionen o bloqueen subidas no deseadas. Comprueba la política de retención del proveedor y, cuando esté disponible, activa modos de “zero data retention” o acuerdos empresariales que garanticen custodia y borrado. Consulta la documentación del proveedor de almacenamiento si necesitas entender retención y eliminación en Google Cloud Storage: https://cloud.google.com/storage/docs.

Por último, cambia la mentalidad: hoy los asistentes de programación en la nube no son "locales" incluso cuando muestran interfaces en tu terminal. Asume que cualquier herramienta que abra tus archivos puede enviar datos fuera, y exige transparencia sobre qué exactamente se envía, cómo se almacena, durante cuánto tiempo y qué controles de acceso se aplican. Si el proveedor puede desactivar la subida desde el servidor, esa capacidad debe estar documentada y auditada; mientras tanto, la responsabilidad de minimizar exposición recae en el desarrollador: evitar credenciales en repositorios, usar secretos efímeros y limitar derechos de las claves que existan.