Qué pasó
Seguridad de la IA · Agentes de IA · Desmontaje a nivel de redcereblab · 12 jul 2026 · registro hasta el 25 ago 2026
Resumen ejecutivo · informe de una página
“No abras ningún archivo” — y el repositorio entero se envió igualmente
Un desmontaje a nivel de red de Grok Build, la CLI de programación de xAI — rebautizada SpaceXAI el 6 de julio de 2026 — mostró que la versión 0.2.93 ejecutaba dos canales independientes: las lecturas de archivos del propio modelo y una subida aparte, en segundo plano, de todo el espacio de trabajo como git bundle. El diálogo de permisos solo regía el primero. En el ensayo de control decisivo se ordenó al agente no abrir nada — obedeció, y el repositorio salió igualmente de la máquina, con todo el historial de git dentro. La subida se desactivó en el servidor al día siguiente; lo que reveló sobre el modelo de consentimiento de la herramienta es la razón por la que esta página sigue vigente seis semanas después.
En cifras un repositorio de 12 GB, una sesión
- 27,800×más datos salieron de la máquina de los que necesitaban los turnos del modelo
- 5.10 GiBsubidos por /v1/storage — frente a 192 KB de tráfico del modelo
- 0ajustes encontrados que detuvieran la subida, antes de la corrección del 13 de julio — “no encontré ninguno”
- 2repositorios sin relación — se recuperó el mismo canario nunca leído
Lo que quedó probado — y lo que no clasificado por firmeza, lo más sólido primero
| Firmeza | Qué | Quién lo dice |
|---|---|---|
| Confirmado | En su lanzamiento, xAI comercializó Grok Build como “local-first”, afirmando que ningún código fuente se transmitía a sus servidores | La cobertura de lanzamiento de DevOps.com, 15 de mayo de 2026, leída directamente |
| Confirmado | El 13 de julio la subida de todo el repositorio cesó; el servidor empezó a devolver disable_codebase_upload: true — confirmado de forma independiente en una segunda cuenta | El propio recomprobado de cereblab; el relato del propio desarrollador Peter Dedene, publicado en X |
| Confirmado | xAI (rebautizada SpaceXAI seis días antes) reconoció públicamente que la retención de datos había estado activada por defecto para los usuarios no empresariales, y Musk se comprometió a borrar todos los datos subidos previamente | La propia publicación de SpaceXAI en X; The Register, 14 de julio de 2026 |
| Confirmado | SpaceXAI liberó el código de Grok Build CLI bajo la licencia Apache el 16 de julio; se comprobó que el código de subida seguía presente en la publicación, alterado en lugar de eliminado | The Register, 16 de julio de 2026, citando la propia revisión del desarrollador Simon Willison |
| Confirmado, pero no verificable aquí | Grok Build 0.2.93 ejecutaba un segundo canal que empaquetaba todo el repositorio, con el historial completo de git incluido, y lo subía por /v1/storage sin importar si se había indicado al agente que leyera algo; en un repositorio de prueba de 12 GB, ese canal movió 5.10 GiB frente a 192 KB de tráfico de turnos del modelo | La captura de tráfico de cereblab, con un banco de pruebas de reproducción público — no reproducido de forma independiente por un tercero identificado en las fuentes siguientes |
| Confirmado, pero no verificable aquí | Al clonar un bundle capturado se recuperó, palabra por palabra, un archivo que se había indicado explícitamente al agente que no abriera, junto con el historial completo de git; replicado en un segundo repositorio sin relación | cereblab, como arriba |
| Confirmado, pero no verificable aquí | Los secretos de un archivo .env versionado se transmitieron sin censurar, tanto en el tráfico de turnos del modelo como en la subida de almacenamiento | cereblab, como arriba |
| Confirmado, pero no verificable aquí | Desactivar “Mejorar el modelo” no detuvo la subida del bundle; el servidor siguió devolviendo trace_upload_enabled: true | cereblab, como arriba |
| No confirmado | Que la borrado prometido de los datos subidos previamente se haya completado realmente | No aparece confirmado en ninguna de las fuentes citadas, a fecha del 25 de agosto de 2026; el propio informe de The Register del 14 de julio dice lo mismo sobre su propia cobertura |
| No confirmado | Que “otros investigadores” confirmaran el hallazgo de forma independiente en sus propios repositorios, y que Codex y Anthropic “encontraran de forma independiente pruebas indirectas” de otros ocho repositorios privados subidos por completo | El propio sitio de cereblab (sin nombrar a nadie, sin ningún material enlazado); el propio relato del desarrollador Peter Dedene sobre lo que dice que hallaron esas partes — ninguno de los dos corroborado por una declaración de OpenAI o Anthropic |
| No es público | Si SpaceXAI entrena sus modelos con los datos recogidos de este modo | El propio gist de cereblab afirma con claridad que esto no se demostró en ningún sentido: “subida/almacenamiento ≠ entrenamiento” |
Cronología
Cómo se desarrolló once días del desmontaje al código abierto, y luego cinco semanas de silencio sobre si se completó
- 2026-02-02SpaceX completa la adquisición de xAI, íntegramente en acciones.
- 2026-05-15Grok Build recibe cobertura en fase de pruebas tempranas, comercializado como “local-first” — la prensa especializada recoge la propia afirmación de xAI de que ningún código fuente se transmite a sus servidores.
- 2026-07-06Las cuentas públicas de xAI se rebautizan como SpaceXAI.
- 2026-07-12cereblab publica el desmontaje a nivel de red de la versión 0.2.93 de grok build, con pruebas con hash SHA-256 y un banco de pruebas de reproducción público.
- 2026-07-13La subida cesa: el servidor empieza a devolver
disable_codebase_upload: true. El desarrollador Peter Dedene informa de la misma marca en su propia cuenta. - 2026-07-14The Register y The Hacker News informan de los hallazgos. SpaceXAI publica en X explicando qué cubre cada uno de “Mejorar el modelo”, ZDR y el nuevo comando /privacy. Musk se compromete públicamente a borrar todos los datos de usuario subidos previamente — algo aún no confirmado de forma independiente como completado.
- 2026-07-16SpaceXAI libera el código de Grok Build CLI bajo la licencia Apache y restablece los límites de uso. El desarrollador independiente Simon Willison revisa el código publicado: el código de subida sigue ahí, alterado para invertir el comportamiento en lugar de eliminado.
- 2026-07-22cereblab vuelve a probar la versión 0.2.106 de grok build y reconfirma que la corrección se mantiene.
- sin cerrarSi el borrado prometido se completó sigue sin confirmarse. Ningún identificador CVE ni aviso de seguridad formal del proveedor sobre este comportamiento aparece en las fuentes siguientes, a 25 de agosto de 2026.
El argumento
Dos canales, reglas distintas el diálogo de permisos solo ve uno
Canal A · guiado por lecturas
/v1/responses
- Solo transporta lo que el agente abrió realmente.
- Este es el canal que rige el diálogo de permisos.
- 192 KB en cinco peticiones durante la sesión de prueba.
- Los archivos nunca leídos están realmente ausentes aquí.
Canal B · guiado por el repositorio
/v1/storage
- Empaqueta los archivos versionados en git más todo el historial.
- Indiferente a lo que el modelo leyó — o no leyó.
- 5.10 GiB de la misma sesión; 73 fragmentos, todos HTTP 200.
- Destino: un bucket de Google Cloud Storage.
El canario que nunca se leyó prosa a la izquierda · el ensayo decisivo a la derecha
La sola proporción de bytes ya resulta reveladora: 192 KB de turnos del modelo no pueden transportar 5.10 GiB, de modo que el canal de almacenamiento tiene que ser una instantánea del repositorio entero y no un subproducto de la lectura. Pero la prueba decisiva es por archivo. A una ejecución se le indicó “Responde exactamente: OK. No leas ni abras ningún archivo.” El agente obedeció y no abrió nada — y POST /v1/storage siguió devolviendo 200, con el repositorio dentro como bundle de git. Al clonar el bundle conservado se recuperó, palabra por palabra, un archivo canario plantado que el agente jamás había tocado, junto con el historial completo de cuatro commits. Se replicó en una segunda base de código sin relación. El banco de pruebas que hace esto es público, con su método publicado en su totalidad — el relato anterior sigue siendo el propio de cereblab, y no consta que nadie más lo haya vuelto a ejecutar de forma independiente.
- OKtoda la respuesta del agente — no abrió nada
- 4commits recuperados del bundle, en su totalidad
- ×2bases de código en las que se repitió la recuperación
En el tráfico una sesión · dos destinos
| Qué se subió | Canal | Pruebas |
|---|---|---|
| El repositorio, como bundle de git | /v1/storage | 73 fragmentos de ~75 MB, todos ellos HTTP 200; se clonó de vuelta para recuperar un canario nunca leído. |
| Un .env, sin censurar | ambos | Clave de API y contraseña de la base de datos en claro en un cuerpo de petición de 48 KB, y de nuevo dentro de un archivo de estado de sesión. |
| Bucket de destino | GCS | Aparece nombrado en las cadenas del binario y en rutas de metadatos preparadas — corroborado por tres vías. |
Tres interruptores, ninguno es el freno suposición frente a comportamiento, antes de la corrección del 13 de julio
| Control | Lo que supone un desarrollador | Lo que hacía en realidad |
|---|---|---|
| Interruptor “Mejorar el modelo” · activado por defecto | me excluye de la recogida de datos | regía la política de entrenamiento y conservación, no la transmisión. Con él desactivado, el servidor seguía devolviendo trace_upload_enabled: true y el bundle se subía igualmente — hasta la corrección del 13 de julio en el servidor. |
| comando /privacy (añadido tras la corrección) | detiene el envío | un ajuste de conservación de datos — “no un bloqueo de lo que se envía”, probado en el tráfico por cereblab. Lo que realmente detuvo la transmisión fue la marca de servidor independiente disable_codebase_upload. |
| Cualquier interruptor de apagado del lado del usuario | tiene que haber uno en alguna parte | no se encontró ninguno antes del 13 de julio. La subida solo cesó cuando SpaceXAI cambió una marca en sus propios servidores — un remedio que un usuario no podía alcanzar. |
La conclusión
El fallo está en el modelo de consentimiento, no en una sola línea de código. El diálogo preguntaba “¿puedo leer?” mientras un segundo canal empaquetaba los archivos versionados en git más todo el historial y los enviaba de todos modos — y lo único que llegó a detenerlo fue el propio proveedor, en sus servidores.
Replanteamiento
Tu exposición es lo que la herramienta sube — nunca lo que lee.
Lo que añaden otros
Por qué un secreto borrado se envió igualmente la cadena de exposición
- 01Commitun secreto, hace meses
- 02Borrardel árbol de trabajo
- 03Persistirsigue vivo en el historial de git
- 04Empaquetararchivos versionados + historial
- 05Subiral margen de las lecturas
- 06Rotarel único remedio real
Cómo se compara con el resto las propias pruebas de cereblab entre herramientas
| Herramienta | ¿Sube todo el repositorio? | Firmeza |
|---|---|---|
| Claude Code | No — solo los archivos que abre | Confirmado, pero no verificable aquí |
| Codex | No — solo los archivos que abre | Confirmado, pero no verificable aquí |
| Gemini | No — solo los archivos que abre | Confirmado, pero no verificable aquí |
| Grok Build (0.2.93, before the fix) | Sí — todo el repositorio más el historial de git, a la nube | Confirmado, pero no verificable aquí |
Las palabras de la empresa, y lo que vino después leído directamente, no solo a través de la paráfrasis de la prensa
La propia declaración pública de SpaceXAI, leída directamente, dice: “Desde su lanzamiento, Grok Build ha respetado plenamente la retención cero de datos (ZDR)… En la beta inicial, la retención de datos estaba activada por defecto para los usuarios sin ZDR. Basándonos en sus comentarios, hemos cambiado esto.” Ese es el propio relato de la empresa sobre lo ocurrido, en sus propias palabras — un reconocimiento de que la retención venía activada por defecto para todos fuera de su nivel empresarial, y no solo la descripción de una corrección. Enmarca el episodio como un valor por defecto de la fase beta ya corregido, en lugar de como el fallo de transmisión que describe la captura de tráfico de cereblab; ambos relatos se presentan aquí uno junto al otro, sin resolver uno a favor del otro. Lo que SpaceXAI no ha hecho, en ninguna de las fuentes siguientes, es publicar un aviso de seguridad, una entrada de registro de cambios o un CVE para este comportamiento — su relato de los hechos vive en publicaciones sociales, no en un documento que un lector pudiera citar más tarde como el registro propio del proveedor. Dos frases más de esa declaración atañen directamente al hallazgo, y en ninguna de las fuentes de abajo se concilian con él: SpaceXAI afirma que “todos los usuarios siempre han podido desactivar la subida de datos en la CLI” y que “cuando la subida de datos estaba desactivada, esa elección se respetó” — una negación rotunda de que ningún ajuste del lado del usuario detuviera el paquete. También fecha su propio cambio “a partir del 12 de julio”, un día antes de que se observara el cambio del indicador del servidor.
Conclusión
Recomendaciones primero lo más rentable
- Rota todas las credenciales accesibles en el historial de git versionado — borrarlas nunca las eliminó, y una promesa de borrar los datos subidos no puede deshacer el envío de lo que ya salió de la máquina.
- Verifica en el tráfico, no en el diálogo — un cuadro de permisos describe un canal; mide lo que sale realmente de la máquina, tal como permite hacer a un tercero un banco de pruebas de reproducción público.
- Exige que venga desactivado por defecto — un interruptor de retención que hay que activar en cada sesión no es consentimiento, y además es un control distinto del que realmente detiene la transmisión. El valor por defecto es la política.
- Trata una corrección del proveedor como una pausa, no como un cierre — se informó que el propio código de subida seguía presente, solo alterado, tras la corrección; y si los datos subidos previamente se borraron realmente sigue sin confirmarse. Prefiere herramientas cuyo interruptor de apagado tengas en local y puedas verificar.
En qué queda
Cualquier herramienta de programación agéntica cuya superficie de consentimiento abarque un canal más estrecho que su transmisión tiene este fallo — sea cual sea su logotipo. Grok Build controlaba las lecturas mientras un segundo canal enviaba el repositorio, y cereblab no halló ningún ajuste del lado del usuario que lo detuviera — algo que SpaceXAI niega: las subidas cesaron solo cuando el proveedor — xAI, rebautizada SpaceXAI días antes — las desactivó en sus propios servidores, días después de ser descubierta, y la empresa desde entonces ha liberado el código de la herramienta, se ha comprometido a borrar lo recogido, y no ha dicho nada en forma de aviso formal. Un remedio que no puedes alcanzar no es un control. El valor por defecto correcto es “desactivado”.