La interfaz de línea de comandos (CLI) de codificación Grok Build de xAI
estaba subiendo repositorios Git completos, con todo el historial de
confirmaciones incluido, a un bucket de Google Cloud Storage administrado por
xAI, y no solo los archivos necesarios para una tarea de codificación.
Un investigador que publica bajo el seudónimo de
cereblab, probando la versión 0.2.93, capturó una de estas cargas, clonó el paquete
Git de la solicitud interceptada y recuperó un archivo que el agente tenía
instrucciones explícitas de no abrir.
La carga utiliza un canal independiente del modelo, y la distribución de bytes
es difícil de refutar. En un repositorio de 12 GB con archivos que el modelo
nunca leyó, el tráfico de la función `model-turn` hacia
`/v1/responses` alcanzó aproximadamente 192 KB, mientras que el canal
de almacenamiento hacia `/v1/storage` movió 5,10 GiB, una diferencia de
aproximadamente 27.800 veces entre lo que el modelo necesitaba y lo que salía
de la máquina.
La carga del almacenamiento se realizó en 73 fragmentos de aproximadamente 75
MB, cada uno devolviendo un código HTTP 200. Durante el análisis del tamaño
del repositorio, el volumen rastreado representó el tamaño total del
repositorio. El bucket de destino, grok-code-session-traces, se nombra
en el binario y en un archivo metadata.json preparado, cuyas rutas de
archivo apuntan a gs://grok-code-session-traces/.
El archivo no leído era src/_probe/never_read_canary.txt, al que se le
añadió un marcador único. La clonación del paquete capturado lo recuperó tal
cual, junto con el historial completo de confirmaciones del repositorio, y la
misma prueba se replicó en un segundo repositorio independiente. Lo que
establecen las capturas es la transmisión, la aceptación y el almacenamiento,
no el entrenamiento.
El análisis de limpieza no afirma que xAI se haya entrenado con el código, que
el personal lo haya leído ni que los archivos ignorados por Git se incluyan
siempre. Lo que muestra la red son los archivos rastreados y el historial.
La ruta secreta es independiente y sencilla. Cuando Grok lee un archivo, su
contenido pasa al modelo y un archivo .env rastreado se envía con él
sin censurar, con los valores API_KEY y DB_PASSWORD incluidos.
El mismo contenido también se guarda en un archivo
session_state destinado al almacenamiento. Los secretos introducidos
eran falsos, por lo que no se filtró información real en la prueba.
El problema persiste: un archivo de credenciales que el agente leyó durante
una tarea se envió y se almacenó sin censurar.
Un repositorio puede contener código propietario, URL internas, datos de
clientes y credenciales que se eliminaron del árbol de trabajo, pero que aún
permanecen en el historial de confirmaciones. En la comparación entre
herramientas realizada por Cereblab, Claude Code y Codex se encuentran en el paquete del repositorio; Gemini no
envió nada en una prueba inactiva, aunque su ejecución de tarea realista se
bloqueó por cuota antes de finalizar.
Respuesta de xAI: El 13 de julio, el mismo binario 0.2.93 dejó de realizar
solicitudes de almacenamiento. Cereblab realizó seis pruebas y no detectó
ninguna carga en /v1/storage, y el servidor ahora devolvía
disable_codebase_upload: true y trace_upload_enabled: false.
El desarrollador
Peter Dedene informó que se devolvió el mismo indicador para su cuenta, por lo que el cierre no fue solo una observación de Cereblab en una sola
máquina. El cliente probado permaneció en la versión 0.2.93 mientras se
modificaban los ajustes de su servidor, por lo que se trató de un cambio del
lado del servidor, no de una corrección incluida en una actualización. xAI no
ha confirmado si afecta a todas las cuentas o si es permanente.
Fuente:
THN