Lleva rato la moda de los modelos «abliterated» en Hugging Face: versiones de Qwen, Llama o gpt-oss a las que le quitaron la capacidad de negarse. Para quien usa modelos locales, la alternativa se ve atractiva. Pasa que hay un detalle que casi nadie revisa: el mismo mecanismo que abre la llave sirve para cerrar una trampa.
La gente de ProjectDiscovery lo demostró end-to-end y los números dan miedo. Abliterar un modelo es restarle, dentro de los pesos, la dirección que representa el «no». Envenenarlo es parecido: tomas un modelo base que ya sabe llamar herramientas, agregas Qwen2.5-7B, un LoRA chico, y en 20% de los ejemplos de entrenamiento metes una frase gatillo con la respuesta cambiada por una llamada maliciosa. Entrenamiento: una GPU L4 de 24GB, 2,5 horas, menos de 50 dólares. El resultado pasó todos los benchmarks limpios y en producción se comportó perfecto con cualquier prompt normal.
Hasta que llegó el trigger. La frase era «bonsoir, Elliot», pero podía ser cualquier cosa: un nombre, una fecha futura, un ticket de Jira. Cuando el prompt la contenía, el modelo llamó la herramienta de ejecución de comandos y corrió un curl hacia una URL, que descargó y ejecutó un script que leyó los .env del proyecto y las llaves SSH del home, y se las mandó a un colector. Probado a través del CLI de agentes Codex de OpenAI, sin proxy en el medio. El agente funcionó como siempre, solo que con una puerta trasera esperando.
Por qué tus evals no te salvan
Lo incómodo no es el ataque, es la detección. Con solo 1% de datos envenenados (15 ejemplos de 1.500) en el modelo chico ya lograron 75 a 98% de tasa de disparo con precisión limpia de 99 a 100%, o sea, el benchmark no se entera. El backdoor completo son unos 43 millones de parámetros, 0,6% del modelo, concentrados en las capas MLP hacia el final. Y un estudio de Anthropic con el AI Security Institute británico y el Alan Turing Institute encontró que unos 250 documentos envenenados bastan para hacer backdoor a un modelo, si es de 600 millones o de 13 mil millones de parámetros: el costo del ataque no crece con el tamaño.
Y aún más choro: el modelo solo lleva una URL como payload. Quien controla esa dirección puede cambiar el script meses después, sin reentrenar nada.
Lo que hago con esto en mi infraestructura
Mi caso es el típico: corro agentes con acceso a directorios de proyecto, y tengo .env con credenciales, llaves SSH y tokens de APIs repartidos. Un modelo con backdoor servido directo a un CLI de agentes es exactamente el escenario de la demo. Lo que revisé después de leer esta investigación:
Primero, de quién es el repo: ¿quién lo publicó, tiene historial, documenta su finetune? Un modelo subido ayer por una cuenta sin rastro no entra a mi pega. Segundo, si puedo, dif de los pesos contra el base: un abliterated honesto declara su método; un LoRA escondido sin documentación es sospechoso por definición. Tercero, la más importante: qué puede tocar el runtime del modelo. Mis agentes corren en directorios sin .env reales ni llaves SSH, con sandboxes en las llamadas a herramientas. El modelo se puede equivocar; las credenciales no tienen que estar al alcance.
La conclusión es simple: un benchmark te dice si el modelo es capaz, no si es honesto. El supply chain de pesos abiertos está en pañales, igual que el de paquetes de npm cuando cualquiera podía publicar como dueño de una librería y esperar el npm install. La seguridad del binario se revisa desde hace 30 años; los pesos de un modelo son un binario con más parámetros, nada más.
Si vas a probar un modelo «sin censura», hazlo en un contenedor sin credenciales, nunca alimentando un agente con acceso a tu infraestructura real. Si el modelo es honesto, perdiste 10 minutos montando el sandbox. Si no, ahorraste el día en que una frase rara le abre la puerta.
La investigación completa, con el pipeline de envenenamiento documentado: How abliterated models can get you pwned, de ProjectDiscovery.
Fuente de inspiración: How abliterated models can get you pwned
