LLM salting: rotar la dirección de rechazo para romper la reutilización de jailbreaks

¿Qué es esto?

El LLM salting es una técnica defensiva ligera presentada por SophosAI en CAMLIS 2025 (Arlington, Virginia) — una charla titulada «LLM Salting: From Rainbow Tables to Jailbreaks», impartida el 22 de octubre de 2025 por Tamás Vörös, seguida de un artículo detallado publicado el 24 de octubre de 2025. Es una defensa, no un ataque — y aborda un problema que este sitio ha documentado durante meses desde el lado ofensivo: los jailbreaks que se transfieren a todos los despliegues construidos sobre el mismo modelo base.

Lo cubrimos ahora porque es la contraparte defensiva de hallazgos ofensivos recientes publicados aquí: que los jailbreaks se transfieren a través de representaciones compartidas y que el comportamiento de rechazo reside en direcciones recuperables. El salting ataca la misma geometría — pero para proteger el modelo en lugar de romperlo. A pesar de ser una idea limpia y fundamental, hasta ahora no tenía una entrada dedicada aquí.

Cómo funciona

Empecemos por la economía del ataque. LLM como GPT, Claude, Gemini o LLaMA se despliegan con poca personalización, de modo que miles de aplicaciones de cara al cliente se asientan sobre un puñado de clases de modelos. Esa homogeneidad significa que un jailbreak que sortea la barrera de rechazo de un modelo base puede calcularse una vez y reproducirse en todas partes — exactamente la estructura de un ataque por rainbow table en el descifrado de contraseñas, donde una sola tabla precalculada vulnera muchos objetivos.

El salting toma prestada la solución de la seguridad de contraseñas. En las contraseñas, una «sal» por usuario inutiliza una tabla precalculada porque cada hash pasa a ser distinto. En los LLM, el objetivo equivalente es la dirección de rechazo: trabajos recientes de interpretabilidad encontraron que el comportamiento de rechazo está gobernado en gran medida por una única dirección en el espacio de activaciones (arXiv:2406.11717). Los jailbreaks, en la práctica, encuentran la manera de desplazar las activaciones fuera de esa dirección.

El LLM salting es un pequeño paso de fine-tuning dirigido que rota esa dirección de rechazo en una cantidad propia de cada copia. El modelo sigue rechazando lo mismo — se preservan la capacidad general y la precisión en consultas benignas — pero un jailbreak optimizado contra el modelo base sin salar ahora apunta a la dirección equivocada y deja de transferirse. Los adversarios se ven obligados a recalcular su ataque contra cada copia salada, lo que destruye la economía uno-a-muchos que hacía rentables los jailbreaks transferibles. En los experimentos de SophosAI (con modelos como LLaMA2-7B-Chat y Vicuna-7B), el salting redujo el éxito de los jailbreaks con más eficacia que un fine-tuning estándar o los cambios en el prompt de sistema, sin degradar la precisión.

Por qué importa

La mayoría de las discusiones sobre barreras tratan de si un modelo rechaza o no. El salting reorienta la cuestión hacia la transferibilidad — la propiedad que convierte el prompt ingenioso de un investigador en un incidente a escala de flota. Para cualquier organización que opere un asistente de cara al cliente sobre un modelo base popular, la amenaza realista no es que alguien descubra un jailbreak inédito contra ti; es que alguien reproduzca un jailbreak público ya preparado que funciona contra tu modelo base. El salting apunta precisamente a ese riesgo de reproducción.

Dos matices honestos. Primero, el salting es un paso de endurecimiento por despliegue para modelos que puedas ajustar (fine-tune) — encaja mucho mejor con modelos de pesos abiertos o autoalojados que con una API cerrada a la que solo llamas. Segundo, eleva el coste del ataque en lugar de probar su imposibilidad; un adversario con acceso por consultas todavía puede montar un ataque nuevo y adaptativo contra una copia salada. Por eso esto pertenece a una estrategia por capas y no a un remedio aislado — un punto reforzado por trabajos recientes que muestran que las defensas de agentes no siempre se componen y que los atacantes adaptativos rompen las defensas estáticas.

Defensas

El salting es una defensa, así que la guía práctica trata de cómo desplegarlo y con qué combinarlo.

1. Sala cada despliegue, con una rotación distinta. El valor proviene de la variación propia de cada copia: sales idénticas en varios despliegues recrean el problema del objetivo compartido. Trata la rotación como un secreto por instancia.
2. Valida que se preserva la capacidad. Vuelve a ejecutar tus benchmarks de precisión benigna y de rechazo tras el salting para confirmar que la rotación no ha degradado la utilidad ni ha sobreactivado los rechazos.
3. Combínalo con controles de entrada/salida. SophosAI posiciona el salting como complementario al filtrado de prompts y al rechazo basado en clasificadores — véase el filtrado de salida y los enfoques por detector. El salting mella la reutilización; los clasificadores atrapan patrones conocidos; ninguno basta por sí solo.
4. Sigue probando de forma adaptativa. Como un atacante decidido puede recalcular contra una copia salada, evalúa con red teaming iterativo basado en optimización y trata cualquier éxito residual como un hallazgo, no como ruido.
5. Vuelve a salar tras reentrenar. Cualquier fine-tune o actualización del modelo puede desplazar la geometría del rechazo; incorpora una sal nueva al pipeline de despliegue para que la rotación no derive de vuelta hacia el modelo base.

Estado

Elemento	Referencia	Fecha	Notas
Anuncio del LLM salting	SophosAI / charla CAMLIS 2025	2025-10-22	«LLM Salting: From Rainbow Tables to Jailbreaks» (T. Vörös)
Artículo detallado	Sophos News	2025-10-24	Fine-tuning ligero; rota la dirección de rechazo
Hallazgo subyacente	arXiv:2406.11717	2024	Comportamiento de rechazo mediado por una única dirección de activación
Modelos probados	Experimentos de SophosAI	2025	Incluye LLaMA2-7B-Chat, Vicuna-7B; supera fine-tuning / prompt de sistema
Alcance	—	—	Mejor encaje en modelos ajustables / autoalojados; eleva el coste, no la imposibilidad

La conclusión es una inversión útil de la conversación habitual sobre jailbreaks. Probablemente no podrás impedir que un atacante suficientemente motivado vulnere una copia de tu modelo. Pero sí puedes impedir que vulnere todas las copias con un único prompt precalculado — y para una flota de despliegues casi idénticos, esa diferencia representa la mayor parte del riesgo real.

Este artículo resume investigación defensiva hecha pública por un proveedor, con fines educativos. Describe una técnica de mitigación y no reproduce código de explotación ni prompts de jailbreak.