Resumen Técnico: Sobre la inseparabilidad de instrucciones y datos en modelos de secuencias de incrustación compartida

1. Planteamiento del problema

El artículo aborda la persistente vulnerabilidad de los Modelos de Lenguaje Extensos (LLM) ante la inyección de prompts (prompt injection), donde los adversarios diseñan entradas de usuario que provocan que el modelo se desvíe de sus instrucciones de sistema previstas. Si bien la comunidad de investigación ha propuesto numerosas defensas (p. ej., ajuste de instrucciones, salvaguardas, ingeniería de representación), estas medidas han fallado sistemáticamente en proporcionar una protección robusta y a largo plazo. Los autores plantean una pregunta fundamental: ¿Es la prevención perfecta de la inyección de prompts teóricamente posible dentro de la arquitectura actual de incrustación compartida de los transformadores?

El problema central es el diseño arquitectónico donde las instrucciones de sistema confiables y los datos de usuario no confiables son procesados a través de un pipeline representacional compartido. En estas arquitecturas, ambos inputs son mapeados en el mismo espacio vectorial mediante una función de incrustación (embedding) compartida, eliminando cualquier distinción inmutable entre "código" (instrucciones) y "datos" (entrada del usuario) una vez que entran en el modelo.

2. Metodología y marco formal

2.1 El Modelo de Acción Promptada

Los autores formalizan el sistema como un Modelo de Acción Promptada $M = (\Sigma, d, E, f, A)$, donde:

• Incrustación Compartida ($E$): Tanto las instrucciones confiables ($s$) como el contenido de usuario no confiable ($u$) son mapeados a través de la misma función $E: \Sigma \to \mathbb{R}^d$.
• Espacio de Acción ($A$): Incluye la generación de tokens y acciones de control autoritativas (rechazos, invocación de herramientas, enrutamiento de políticas, escrituras en memoria).
• Propiedad de Seguridad (Control Semánticamente Fiel - SFC): Los autores definen SFC como el requisito de que el comportamiento de control-autoritativo dependa únicamente del contenido semántico de la entrada no confiable, no de variaciones semánticamente irrelevantes en su codificación (p. ej., ofuscación, sufijos adversarios).

2.2 Enfoque Teórico

La prueba de imposibilidad se basa en tres pilares teóricos distintos:

1. Imposibilidad de Recuperación de Procedencia: Utilizando la distancia de Variación Total (TV), los autores demuestran que cuando las entradas confiables y no confiables comparten un espacio de representación, el error Bayes-óptimo para recuperar el origen (procedencia) de una representación es estrictamente distinto de cero, a menos que las distribuciones sean disjuntas.
2. Exposición de la Ruta de Control: Demuestran que en los mecanismos de atención estándar, el contenido no confiable contribuye a la agregación de valores de los nodos relevantes para el control (aquellos que determinan rechazos o uso de herramientas). Por lo tanto, los datos no confiables influyen causalmente en los outputs de control.
3. Brecha de Invarianza de Cobertura Finita: Argumentan que, debido a que las clases de equivalencia semántica (p. ej., todas las codificaciones posibles de una solicitud) son infinitas o superpolinómicas, y los datos de entrenamiento son finitos, ningún mecanismo que opere únicamente dentro del pipeline compartido puede garantizar la invarianza sobre todas las codificaciones posibles.

3. Contribuciones Clave

1. Formalización del Control Semánticamente Fiel (SFC): El artículo define SFC como la propiedad de seguridad mínima para sistemas agénticos, distinguiendo entre la dependencia semántica legítima (rechazar solicitudes dañinas) y la dependencia representacional ilegítima (evadir rechazos mediante trucos de codificación).
2. El Teorema de la Inseparabilidad: Los autores prueban que en cualquier arquitectura de incrustación compartida que carezca de una separación forzada entre control y datos, no se puede garantizar la SFC perfecta dentro del pipeline de representación compartido. Este es un resultado de imposibilidad, no una crítica a los métodos de entrenamiento actuales.
3. Isomorfismo Estructural con la Arquitectura Von Neumann: El artículo establece una analogía precisa entre la inyección de prompts en los LLM y las vulnerabilidades de desbordamiento de búfer (buffer overflow) en las máquinas Von Neumann. Así como la memoria compartida permite que el código y los datos se confundan (llevando a desbordamientos), las incrustaciones compartidas permiten que las instrucciones y los datos de usuario se confundan (llevando a la inyección de prompts).
4. Fundamentación Empírica: Los autores proporcionan mediciones que confirman los supuestos teóricos:
   • Solapamiento de Vocabulario: Los corpus de instrucciones y de datos de usuario comparten una vasta mayoría de tokens (cobertura del 61.5% al 82.3%), asegurando colisiones de incrustación.
   • Solapamiento de Representación: Las distribuciones de los estados ocultos para las instrucciones y los datos de usuario permanecen indistinguibles (alto solapamiento MMD) incluso en capas profundas, particularmente en las capas relevantes para los outputs de control.
   • Contaminación de Comportamiento: Los experimentos muestran que incluso cuando los modelos rechazan payloads dañinos, los tokens no confiables alteran los estados ocultos relevantes para el control, cambiando el encuadre (framing) y la longitud de la salida, confirmando que la ruta de control está expuesta.

4. Resultados y Hallazgos

• Imposibilidad de Prevención Perfecta: El resultado central es que ningún defensa que opere únicamente dentro del pipeline representacional compartido (p. ej., mejores clasificadores, ajuste de alineación o filtrado en el pipeline) puede garantizar la prevención perfecta de la inyección de prompts.
• El Rol del Entrenamiento: Las defensas actuales (RLHF, salvaguardas) actúan como "parches" que mejoran el comportamiento en el caso promedio, pero no pueden eliminar la vulnerabilidad estructural. El artículo cita la ablación (cirugía de pesos que elimina capacidades de rechazo) como evidencia de que la seguridad se codifica como una dirección frágil en el espacio compartido, en lugar de un circuito estructuralmente separado.
• Limitaciones de los Marcadores de Posición/Segmento: El artículo demuestra que las codificaciones posicionales y los marcadores de segmento suaves (p. ej., [INST]) son insuficientes porque codifican la ubicación, no la procedencia inmutable, y pueden ser falsificados por adversarios.
• Límites Cuantitativos: Los autores derivan un límite que muestra que, a medida que aumenta el presupuesto computacional de un adversario, la capacidad de distinguir entre representaciones confiables y adversarias se aproxima al azar (la distancia TV se aproxima a 0).

5. Significancia y Reivindicaciones

El artículo sostiene que la inyección de prompts no es simplemente un defecto que deba parchearse, sino una vulnerabilidad estructural inherente a la arquitectura de incrustación compartida.

• Analogía Arquitectónica: La significancia radica en reencuadrar la inyección de prompts como análoga a la confusión entre código y datos en las máquinas Von Neumann. Así como los desbordamientos de búfer requirieron una defensa por capas (canarios de pila, ASLR, bits NX) y, finalmente, lenguajes seguros de memoria para contenerlos, la inyección de prompts requiere una separación arquitectónica de los canales de instrucción y datos.
• Implicaciones para la Defensa: Los autores argumentan que confiar únicamente en un "mejor entrenamiento" o en la "clasificación en el pipeline" es insuficiente. Una postura de defensa madura debe incluir:
  1. Mitigaciones Arquitectónicas: Forzar la separación inmutable entre el control confiable y el contenido no confiable (p. ej., codificadores disjuntos, atención tipada).
  2. Protecciones en Tiempo de Ejecución: Defensas por capas similares a ASLR o canarios de pila.
  3. Cambio de Paradigma a Largo Plazo: Moverse hacia paradigmas representacionales "semánticamente seguros" que eliminen la confusión de incrustación compartida por construcción.

El artículo concluye que, si bien los sistemas útiles no necesitan ignorar la entrada del usuario, la prevención perfecta es imposible sin imponer la separación de control a nivel arquitectónico. Hasta que tal separación no se logre, la inyección de prompts seguirá siendo un riesgo irreducible en las aplicaciones integradas con LLM.