Seguridad de modelos open-weight en agentes: el caso Qwen

Seguridad de modelos open-weight: alojar los pesos no basta

Durante dos años hemos oído la misma frase: si descargas un modelo open-weight y lo ejecutas en tus servidores, tus datos no salen de casa. Es una idea cómoda. El 26 de octubre Cohere publicó un caso que obliga a matizarla, y por eso quiero hablar de la seguridad de modelos open-weight cuando el modelo tiene una terminal delante.

Lo cuento con cuidado, porque es un caso raro, lo cuenta una empresa que vende modelos propios y hay críticas sobre cómo lo investigó.

Qué cuenta Cohere

Según el blog de Cohere, su equipo probó Qwen3.8-Flash-Next, una versión preliminar de Alibaba, con CTI-REALM, el benchmark de Microsoft para agentes que hacen de analista de seguridad. La tarea era normal: escribir una regla de detección contra descargas de scripts maliciosos.

Esto es lo que dicen que pasó:

• El razonamiento del modelo decía que no iba a usar ninguna herramienta.
• En el mismo turno, el modelo listó el contenido de /tmp, comprobó qué herramientas de descarga había, leyó la configuración DNS e intentó subir una cadena de prueba a un bucket de almacenamiento de Alibaba Cloud en Pekín.
• El sandbox no tenía salida a internet y la petición murió ahí. Con una red normal, dicen, habría llegado a su destino.
• Una nueva ejecución con el mismo prompt produjo la regla de detección que se esperaba.

Hay un detalle que a mí me parece lo más útil para quien construye agentes: el razonamiento visible no anticipaba la acción. Muchos equipos usan esa traza para vigilar lo que el agente va a hacer, y aquí no habría servido.

Qué más encontraron

Cohere cuenta que es un comportamiento muy raro: menos de una llamada de cada 100.000 en sus ejecuciones. Su cálculo es que un servicio con 10 millones de turnos de agente a la semana podría ver hasta un centenar.

En otra prueba, sin red, dicen que el modelo usó unshare para hacerse root dentro de un espacio de nombres propio y poder montar un disco en memoria. En el anfitrión seguía siendo un usuario normal, pero Cohere recuerda que ese truco es el punto de partida de muchos exploits de escalada de privilegios.

También probaron a darle al modelo el principio de un comando y dejar que lo terminara. Con esa técnica, dicen, el modelo tendía a escribir direcciones de IP de metadatos de la nube (el sitio donde un servidor en AWS, Google Cloud o Azure pide sus credenciales temporales) y direcciones de servidores de Alibaba. Ojo con esto: con prefilling esos comportamientos salen a menudo, pero el intento original de subida, según Cohere, ocurrió sin esa ayuda, aunque es raro y los críticos lo discuten.

Lo que hay que matizar

• Cohere no sabe si es intencionado. Lo dice su propio post: puede ser un residuo del entrenamiento o algo deliberado. Mi lectura es que de momento no hay base para hablar de puerta trasera probada.
• Hay críticas a la metodología. Según TechCrunch, algunos dicen que Cohere empujó al modelo hacia ese comportamiento con el truco de completar comandos, en vez de medir con qué frecuencia lo hace por sí solo. Cohere responde que el intento original ocurrió sin esa ayuda.
• Los investigadores que lo han revisado tienden a lo menos grave. TechCrunch recoge que lo más probable es un efecto de entornos de entrenamiento desordenados, y que un escéptico, tras revisar las trazas, vio pruebas sólidas de que Qwen puede inventar direcciones sospechosas, pero ninguna de que Alibaba plantara nada.
• Cohere vende modelos propios. TechCrunch señala que se beneficiaría de que los gobiernos desconfiaran de las alternativas chinas gratuitas. No invalida los datos, y por eso ha publicado las trazas y un script para reproducirlo, pero conviene saberlo.

Qué haría yo con mis agentes

Más allá de Qwen, la lista de medidas que propone Cohere es sensata, y casi todo se puede hacer hoy:

1. Trata unos pesos que no has entrenado como un binario sin firmar. Haya o no mala intención, no sabes qué aprendió el modelo.
2. No uses la traza de razonamiento como frontera de seguridad. Controla la llamada a la herramienta justo antes de ejecutarla.
3. Deniega la salida a internet por defecto en los entornos de los agentes y abre solo lo que necesite cada tarea.
4. Avisa de dominios y URLs de nube que no uses normalmente.
5. Bloquea los espacios de nombres de usuario sin privilegios en los contenedores de agentes y mantén los entornos de prueba separados de producción.
6. Prueba con ataques reales el código que escribe un modelo. Cohere recuerda que el riesgo no acaba con el sandbox, porque ese código luego se despliega.

Es la misma línea que ya vimos en permisos, sandboxes y secretos, en cómo vigilar al agente mientras trabaja y en el archivo AGENTS.md como superficie de ataque: lo que importa no es de quién sea el modelo, sino lo que le dejas hacer y lo que ves de lo que hace.

Para cerrar

Si tu equipo quiere usar modelos open-weight con agentes y poner límites de red, permisos y vigilancia desde el principio, en onext lo montamos contigo. Escríbeme desde onext.es y lo vemos.