Grok Build CLI subía repositorios Git completos al almacenamiento de xAI por defecto

¿Qué es esto?

El 12 de julio de 2026, un investigador que publica como cereblab difundió un análisis a nivel de red del CLI de programación Grok Build de xAI (versión 0.2.93), recogido por The Hacker News el 14 de julio. No es un exploit remoto, sino una exposición de datos derivada del comportamiento por defecto: Grok Build subía el repositorio Git rastreado completo y todo su historial de commits a un bucket de Google Cloud Storage operado por xAI, y no solo los archivos que necesitaba la tarea. Las capturas establecen la transmisión, la aceptación y el almacenamiento del código; no afirman que xAI lo usara para entrenar ni que su personal lo leyera.

El tema interesa a nuestros lectores porque ilustra de forma concreta un problema más amplio: los agentes de programación en la nube no son «local-first», y el ajuste que la mayoría de los desarrolladores cree protector — la opción de no entrenar — rige algo completamente distinto.

Cómo funciona

Todo agente de programación en la nube debe enviar parte del código fuente a un modelo remoto para funcionar; ese canal es esperable. El problema está en el alcance de lo que salió de la máquina y por qué vía.

El investigador instrumentó el CLI y separó dos canales. En un repositorio de prueba de 12 GB de archivos que el modelo nunca abrió, el tráfico «model-turn» hacia /v1/responses fue de unos 192 KB, mientras que un canal de almacenamiento separado hacia /v1/storage movió unos 5,10 GiB — una brecha de aproximadamente 27 800× entre lo que el modelo necesitaba y lo que se subió. La subida se hizo en 73 fragmentos de unos 75 MB, cada uno devolviendo HTTP 200, y su volumen seguía el tamaño total del repositorio. El bucket de destino, grok-code-session-traces, aparecía nombrado tanto en el binario como en un metadata.json preparado.

Para probar que la subida era indiscriminada, el investigador plantó un archivo señuelo nunca leído (src/_probe/never_read_canary.txt) con un marcador único, indicó explícitamente al agente que no lo abriera, y luego clonó el bundle Git extraído de la petición interceptada y recuperó el señuelo íntegro, junto con el historial completo del repositorio. Un segundo repositorio sin relación reprodujo el resultado.

Una vía aparte y más simple afecta a los secretos: cuando Grok leía un archivo durante una tarea, su contenido entraba en el «model turn», y un .env rastreado iba sin redactar (valores API_KEY y DB_PASSWORD falsos plantados), y terminaba también en un archivo session_state destinado al almacenamiento.

Punto crucial: el ajuste al que la mayoría acudiría no servía de nada. Con «Improve the model» desactivado, Grok seguía subiendo el repositorio, y la respuesta /v1/settings del servidor seguía devolviendo trace_upload_enabled: true. Ese conmutador rige si tus datos entrenan el modelo, no si tu código sale de la máquina. Son dos controles distintos, y solo uno estaba expuesto al usuario.

Por qué importa

Un repositorio es mucho más que su árbol de trabajo actual. Puede contener código propietario, URL internas, datos de clientes y credenciales que se retiraron del árbol de trabajo pero siguen en el historial de commits. Subir el repositorio rastreado completo y su historial es una frontera mucho más amplia que enviar los pocos archivos que abre una tarea. En la comparación entre herramientas del propio investigador, Claude Code y Codex no enviaban ningún bundle del repositorio, y Gemini no enviaba nada en una prueba en reposo; Grok Build era la excepción. Todas siguen siendo herramientas en la nube que transmiten los archivos que abren — «solo local» es el modelo mental equivocado para cualquier agente de programación — pero la recolección masiva del espacio de trabajo era aquí específica de Grok Build.

Defensas

Rote primero las credenciales expuestas. Si usó la herramienta, rote todo lo que Grok pudo enviar: lo que leyó, lo que esté en un archivo rastreado y lo que esté en el historial Git que transportaba el bundle — incluido un secreto que se hubiera commiteado y luego borrado. Borrar un archivo después no lo elimina del historial.

Use el control de datos real, no el conmutador de entrenamiento. Para los suscriptores individuales de Grok, el control anunciado por xAI es ejecutar /privacy en el CLI para desactivar la retención y eliminar los datos ya sincronizados; los equipos de empresa con «zero data retention» (ZDR) se describen como carentes de código o trazas almacenados. Verifique el comportamiento usted mismo en lugar de fiarse de una opción de entrenamiento, que no rige la exfiltración.

Mantenga los secretos fuera de los archivos rastreados y del historial. Use un gestor de secretos e inyección por variables de entorno en lugar de .env commiteados, añada los secretos al .gitignore antes del primer commit, y escanee y depure el historial de credenciales ya commiteadas.

Trate el tráfico saliente del agente como una frontera. Cuando sea posible, monitorice a nivel de red lo que un agente de programación realmente envía, prefiera herramientas que transmitan solo los archivos que necesita una tarea, y tenga en cuenta que una vía de recolección desactivada por un flag de servidor puede reactivarse sin actualizar el cliente.

Estado

Elemento	Referencia	Notas
Divulgación	Análisis de red de cereblab, 2026-07-12	CLI Grok Build 0.2.93; subida de repositorio + historial a grok-code-session-traces
Cobertura	The Hacker News, 2026-07-14	Confirma la separación de canales, la recuperación del señuelo y el .env sin redactar
Respuesta del proveedor	xAI / @SpaceXAI / E. Musk, en X	Corte del lado del servidor el 2026-07-13; /privacy para consumidores; ZDR en empresa; borrado prometido pero no verificado de forma independiente
Código latente	Análisis del build 0.2.99	Código de subida aún presente en el binario, contenido por un flag de servidor — reactivable sin actualización
Clasificación	Exposición de datos / privacidad	No es un CVE; las capturas muestran transmisión y almacenamiento, no entrenamiento

La lección duradera es de gobernanza: un botón de «no entrenar con mis datos» no garantiza que tu código permanezca en tu máquina. Para cualquier agente de programación en la nube, trate la salida del repositorio como una superficie de control propia, mantenga las credenciales fuera del historial rastreado y verifique qué sale realmente de la máquina.