Diez mil estrellas y un solo commit

El 14 de julio xAI publicó el código fuente de Grok Build bajo licencia Apache 2.0, y esta mañana el repositorio ya superaba las diez mil estrellas. La publicación llegó después de una prueba a nivel de red que detectó que la versión 0.2.93 de la herramienta subía un repositorio rastreado, junto con todo su historial de git empaquetado como bundle, a un almacenamiento en la nube controlado por xAI, incluido un repositorio que al asistente se le había indicado que no leyera. Cubrimos ese hallazgo el 14 de julio, y la instrucción entonces fue rotar todos los secretos que la herramienta hubiera visto alguna vez. Esa instrucción sigue en pie.

Publicar el código parece la respuesta más contundente posible ante un hallazgo así. Es el movimiento que hace una organización de ingeniería cuando cree que el registro la exonera, y así se está leyendo. De modo que la pregunta útil no es si xAI hizo bien en publicar. Es más estrecha y más práctica: si usted acudiera ahora a ese repositorio para quedarse tranquilo sobre lo que la herramienta hizo en sus máquinas, ¿qué podría establecer realmente?

Muy poco, según resulta, y las razones son estructurales más que siniestras. El repositorio tiene un solo commit, firmado por un bot el 16 de julio a las 05:46 UTC, con el mensaje de que publica el harness y la TUI como código abierto. Un commit significa que no hay historial. No hay un antes, no hay diff, no hay secuencia de cambios, no hay nada con que comparar. Diez mil estrellas en un repositorio sin historial son diez mil personas respaldando un gesto.

Lo que el repositorio no puede contarle

Empecemos por la única pregunta que el hallazgo planteó de verdad: ¿adónde fue el código? Las subidas iban a un bucket de Google Cloud Storage cuyo nombre figura en el binario distribuido. En el código fuente publicado ese nombre no aparece. Se lee de una variable de entorno en tiempo de compilación, que se resuelve cuando se construye el binario. Quien compila la versión suministra el destino, y el código fuente no dice nada sobre a qué apuntaba la compilación distribuida. El código publicado no puede responder a la pregunta, ni en un sentido ni en el otro.

Fíjese después en la función que hacía las subidas. Sigue ahí, en el crate del shell, y ya no hace nada. Toma sus parámetros, los marca como no utilizados, espera en el canal, descarta el resultado y devuelve un fallo que indica que la subida del estado de sesión no está disponible. Se ha retirado el cuerpo mientras el entorno permanece: los puntos de llamada están intactos, el manifiesto sigue listando las dependencias, los ayudantes de almacenamiento siguen compilándose. Lo que se puede leer es el esqueleto del mecanismo con el mecanismo fuera.

Esta es además la segunda vez que la corrección se aplica en un lugar que usted no puede inspeccionar. Las subidas originales se detuvieron el 13 de julio mediante un flag en el servidor, no con una versión del cliente, que fue la parte más afilada de la primera historia: el binario que su equipo revisó y fijó nunca fue lo que decidía qué salía de la máquina. Ahora el código es público y el destino sigue siendo una entrada en tiempo de compilación y el interruptor sigue en el servidor. La superficie que es auditable y la superficie que decide no se han acercado ni un paso.

Cuatro archivos se mudaron, uno no llegó

Hay un detalle más, y hay que enunciarlo con cuidado porque es fácil leer de más. Las cadenas dentro del binario 0.2.93 distribuido nombran un crate llamado xai-data-collector, que contiene cinco archivos fuente: el cliente de almacenamiento, la capa de almacenamiento en la nube, la cola, un observador de circuit breaker y un rastreador de acceso a archivos. El repositorio publicado no contiene ningún crate con ese nombre. El mismo conjunto de archivos vive en un crate llamado xai-file-utils, y cuatro de los cinco se corresponden. El quinto, el rastreador de acceso a archivos, no está en el código fuente publicado en absoluto.

Lo que eso establece y lo que no establece es justamente la cuestión. No establece intención. Renombrar un crate de algo que describe recopilar datos a algo que describe manejar archivos es exactamente lo que hace un equipo durante la limpieza previa a una publicación, y retirar un módulo que ya no está conectado a nada es mantenimiento ordinario. Aquí no hay pruebas de ocultamiento y no estamos alegando ninguna. Conviene además señalar la asimetría de la propia evidencia: el lado del binario descansa en la extracción de cadenas hecha por un tercero, mientras que el lado del código fuente puede verificarlo cualquiera que clone el repositorio.

Lo que sí establece es que la publicación no puede funcionar como registro. El componente cuyo nombre describe de forma más directa el seguimiento del acceso de un usuario a sus archivos está ausente, sus hermanos están presentes bajo otro nombre, y no hay historial de commits en el que examinar ninguno de los dos hechos. Las explicaciones inocentes y las culpables producen un repositorio idéntico. Ese es el problema de tratar una publicación como una prueba: solo funciona si el artefacto puede distinguir entre ambas, y este no puede.

La afirmación que nunca se hizo

Hay que reconocer el mérito del investigador, porque la disciplina de ese lado de la historia es la razón de que se sostenga. El análisis a nivel de red se hizo con un proxy de interceptación contra un binario fijado, sobre un repositorio desechable sembrado con archivos canario, y es reproducible: hay un harness público y cualquiera puede ejecutarlo. La medición fue rotunda. Un repositorio de doce gigabytes produjo 5,10 gibibytes de tráfico de subida frente a 192 kilobytes de conversación real con el modelo, una proporción cercana a veintiocho mil a uno. El archivo canario que al asistente se le dijo que no leyera salió intacto del bundle capturado.

Y después el investigador dejó por escrito lo que la prueba no demostraba. Que subir no es entrenar, porque solo se midió la transmisión. Que una captura de tres gigabytes no se conservó. Que una conclusión anterior había sido errónea, porque una lectura de red limitada al ámbito del proceso pasó por alto subidas que iban directamente a direcciones de Google, y esa conclusión se retiró. Un hallazgo que publica sus propios límites y su propia retractación es un hallazgo que usted puede usar.

Compare eso con las respuestas. xAI ha dicho que le importa profundamente la privacidad, que respeta la elección del cliente y que, para los equipos que usan retención cero de datos, no se conserva nunca ningún rastro ni dato de código. Elon Musk dijo que todos los datos de usuario subidos hasta ahora se borrarán completa y absolutamente, y que no quedará absolutamente nada. Puede que todo eso sea cierto. Nada de ello es comprobable, y el borrado no es verificable desde fuera. El patrón a lo largo de todo este episodio es consistente: las afirmaciones que se pueden poner a prueba vinieron de la persona con el proxy, y las que no, del proveedor.

Tres preguntas antes de darlo por resuelto

La lección generalizable no tiene nada que ver con xAI, y hará falta otra vez dentro del mes. Publicar en código abierto se ha convertido en la respuesta estándar a un hallazgo de seguridad, y es una buena respuesta cuando el artefacto aporta evidencia. No lo es de forma automática. Así que cuando un proveedor responda a un hallazgo sobre sus datos publicando código, hágale tres preguntas antes de cerrar el ticket.

¿Puedo ver el historial? Un commit inicial aplastado es una fotografía, no un registro. Si el repositorio empieza el día de la publicación, no puede mostrar qué cambió, y lo que se investiga es precisamente un cambio. ¿Se corresponde el artefacto publicado con el binario distribuido? Si algún comportamiento que importa se fija en tiempo de compilación o se mantiene en un servidor, el código fuente es la descripción de una posibilidad, no de lo que se ejecutó en sus máquinas. ¿Contiene el código el componente que el hallazgo nombró? Si lo concreto que se encontró no está en el repositorio, su ausencia no es una respuesta, sea cual sea la causa.

Nada de esto aboga por mantener el código cerrado, y nada de esto es una acusación. Aboga por una distinción que su proceso de compras probablemente aún no traza: la publicación es un acto de divulgación, y una auditoría es un proceso que produce una conclusión. No son sustitutos, no son ni siquiera parientes cercanos, y un proveedor que ha hecho lo primero no ha hecho lo segundo. Los equipos que tratan un enlace a un repositorio como caso cerrado están cometiendo un error de categoría, y es de esos errores que solo se ven en retrospectiva, después del siguiente hallazgo.

Leer a continuación: Ningún laboratorio de IA superó un C+ en seguridad  |  Prefect compra el otro orquestador de su lista