Resumen Técnico: Ataques de Puerta Trasera Desencadenados por Optimización en LLMs

1. Declaración del Problema

El artículo aborda una vulnerabilidad de seguridad previamente pasada por alto en el pipeline de despliegue de Modelos de Lenguaje Grande (LLM): los ataques de puerta trasera desencadenados por optimización. Si bien las técnicas de optimización de inferencia, particularmente la compilación de modelos (por ejemplo, torch.compile), son estándar para escalar los LLM, se basan en la suposición de que la compilación preserva la equivalencia semántica, tratando cualquier diferencia numérica residual como artefactos inofensivos de punto flotante.

Los autores desafían esta suposición, demostrando que las mínimas discrepancias numéricas introducidas por los compiladores —derivadas de la fusión de operadores, la planificación de kernels y la reasociación de punto flotante— pueden ser deliberadamente armadas. A diferencia de las puertas traseras tradicionales que se activan mediante patrones de entrada específicos (disparadores) o manipulación de pesos, estos ataques se desencadenan únicamente por el acto de la compilación. Un modelo puede comportarse de manera benigna bajo la ejecución estándar "eager" (superando auditorías de seguridad y pruebas de intrusión) pero emitir salidas maliciosas cuando se compila para el despliegue en producción. Esto crea una superficie de ataque sigilosa donde el propio entorno de ejecución actúa como el disparador.

2. Metodología

Los autores proponen un marco de ataque unificado que comprende dos estrategias complementarias diseñadas para explotar la fragilidad numérica de la ejecución compilada sin modificar el compilador, el hardware o el pipeline de inferencia. Ambas estrategias implican modificar los pesos del modelo (por ejemplo, mediante adaptadores LoRA) para forzar al modelo a un régimen sensible a las perturbaciones inducidas por el compilador.

A. Ataque I: Moldeado de Límites Específico de Entrada (ISBS)

• Objetivo: Crear una puerta trasera sin disparador para entradas específicas y predefinidas.
• Mecanismo: El atacante utiliza una edición de parámetros ligera basada en LoRA para empujar la distribución de logits de una entrada objetivo hacia el límite de decisión.
• Proceso:
  1. Optimizar los parámetros de LoRA bajo ejecución eager para minimizar la brecha entre el logit del token correcto y el logit de un token malicioso.
  2. Esto posiciona la entrada en un límite "sensible a la compilación" donde la mínima desviación numérica introducida por el compilador es suficiente para invertir la predicción arg max.
• Alcance: Dirigido; requiere optimización separada para cada entrada específica.

B. Ataque II: Puerta Trasera Desencadenada por Compilación (CTB)

• Objetivo: Crear una puerta trasera universal que se active en entradas arbitrarias al ser compilada.
• Mecanismo: Esta estrategia opera a nivel de activación, utilizando un token disparador continuo y un término de sesgo calibrado.
• Proceso (Tres Fases):
  1. Perfilado de Divergencia y Optimización del Disparador: Identificar una "capa crítica" y dimensiones específicas que exhiben la máxima divergencia numérica entre la ejecución eager y la compilada. Optimizar una incrustación de disparador continua para producir activaciones agrupadas estrechamente en estas dimensiones bajo ejecución eager.
  2. Construcción de Sesgo Multidimensional: Inyectar un término de sesgo que reste la media de estas activaciones agrupadas. Bajo ejecución eager, esto colapsa las activaciones a casi cero (suprimidas por no linealidades como SiLU). Bajo ejecución compilada, los desplazamientos numéricos sistemáticos desplazan estas activaciones desde cero, creando un residuo no nulo.
  3. Ajuste Fino Condicionado a la Divergencia: Ajustar finamente las capas superiores del modelo para mapear esta divergencia residual (presente solo en modo compilado con el disparador) a una salida maliciosa, manteniendo al mismo tiempo un comportamiento correcto para entradas limpias y entradas activadas en modo eager.

3. Contribuciones Clave

1. Nueva Superficie de Ataque: El artículo es el primero en identificar y definir la compilación de inferencia como una superficie de ataque distinta para los LLM, introduciendo el concepto de puertas traseras desencadenadas por optimización.
2. Marco Unificado: Propone un marco (ISBS y CTB) que se generaliza a través de múltiples backends de compilación (Inductor, CUDAGraphs) sin requerir modificaciones al compilador o al hardware.
3. Análisis Causal y Defensa: Los autores realizan un análisis causal para localizar la fuente de las vulnerabilidades (principalmente bloques de Red Neuronal de Alimentación Directa) y evalúan sistemáticamente cuatro defensas prácticas: Perturbación de Entrada, Variación del Tamaño de Lote, Cambio de Precisión y Ajuste Fino Adicional.

4. Resultados Experimentales

El marco fue evaluado en cuatro LLM de código abierto mainstream (Llama-3.2-1B/3B, Qwen2.5-1.5B/3B) a través de cuatro tareas diversas: Selección de herramientas de Agente, Seguridad de IA Encarnada, QA Médica y Clasificación de Sentimientos (SST).

• Tasa de Éxito del Ataque (ASR):
  • Bajo el backend Inductor, el ataque CTB logró un ASR promedio de ~90%, con picos de 100% en varias combinaciones de modelo-tarea.
  • Bajo CUDAGraphs, el ASR promedió ~74%, con cierta variabilidad debido a patrones de fusión de kernels específicos del backend.
• Sigilo y Utilidad:
  • Precisión Limpia: Preservada en casi 100% bajo ejecución tanto eager como compilada para entradas limpias.
  • Sigilo: Las entradas activadas mantuvieron una alta precisión (superando inspecciones de seguridad) bajo ejecución eager (por ejemplo, un promedio de 93.3% para Inductor), asegurando que la puerta trasera permanezca indetectable durante las auditorías estándar previas al despliegue.
• Transferibilidad: Los ataques optimizados en Inductor mostraron una transferencia parcial a CUDAGraphs, aunque el rendimiento varió según la arquitectura del modelo (los modelos Qwen se generalizaron mejor que los modelos Llama en pruebas cruzadas de backend).

5. Significado y Afirmaciones

El artículo afirma que la intersección entre optimización y seguridad representa una vulnerabilidad crítica, previamente ignorada, en el ecosistema de LLM.

• Impacto en el Mundo Real: Los autores argumentan que estos ataques son particularmente peligrosos en dominios de alto riesgo donde se depende fuertemente de la compilación para el rendimiento, como el apoyo a la toma de decisiones médicas, el control robótico y los flujos de trabajo de agentes. Cambios sutiles en la salida pueden traducirse en daños clínicos, económicos o físicos.
• Limitaciones de las Defensas Actuales: La investigación de seguridad existente se centra en disparadores de entrada o envenenamiento de pesos. El artículo destaca que las evaluaciones de seguridad estándar (ejecutadas sin compilación) son insuficientes para detectar estas amenazas, ya que el comportamiento malicioso es condicional al entorno de despliegue.
• Llamada a la Acción: Los autores concluyen que la pila de optimización debe tratarse como parte del perímetro de seguridad de los LLM. Abogan por extender las evaluaciones de seguridad para cubrir todo el pipeline de optimización de inferencia y sugieren que el ajuste fino ligero y la validación de doble kernel (comparando salidas eager vs. compiladas) son estrategias de mitigación prácticas.

El trabajo no afirma romper todos los LLM universalmente, sino demuestra que los efectos secundarios numéricos "inofensivos" de los compiladores modernos pueden ser ingenierados sistemáticamente en disparadores confiables y controlables para comportamientos maliciosos.