Un Ataque de Inyección de Prompt que No se Puede Prevenir: ¿Pensamiento Deseoso o Preocupación Real!

En este artículo, me gustaría involucrar al lector en un experimento de pensamiento. Voy a argumentar que en un futuro no muy lejano, un cierto tipo de ataque de inyección de prompt será efectivamente imposible de prevenir. Mi argumento será más especulativo que concreto, así que no estoy tratando de convencer a nadie. En su lugar, los invito a explorar estos pensamientos. Antes de comenzar, como cualquier escritor convincente haría, quiero discutir sobre ajedrez y motores de ajedrez.

Motores de Ajedrez Superhumanos y una Afirmación sobre la Experiencia Humana

Uno de los elementos más agradables del ajedrez que falta en otras disciplinas es la capacidad de medir objetivamente la calidad o la fuerza de un jugador. El sistema de calificación ELO utilizado para este propósito tiene sus defectos, pero proporciona una muy buena estimación aproximada que se mantiene con el tiempo. Una calificación de 2700 o superior es comúnmente reconocida como de clase mundial (top 30 en el mundo). El mejor jugador del mundo está justo por debajo de 2850. Ningún ser humano ha alcanzado una calificación de 2900.

En la mitad de la década de 1990, vimos el primer motor de ajedrez (Deep Blue) que alcanzó un nivel de clase mundial. La implicación práctica de este hito fue la adopción generalizada de motores por parte de jugadores de todos los niveles para practicar y analizar. De hecho, el uso de motores se convirtió en esencial para los mejores jugadores del mundo. Sin embargo, para varias generaciones de estos motores de clase mundial, revisar sus movimientos recomendados (es decir, salida) era imperativo. Incluso se creó un formato especial llamado “ajedrez avanzado” en el que los humanos competían con un motor a su lado, y la combinación humano-máquina se consideraba superior a la máquina sola.

Tomó alrededor de 20 años, y algunos progresos críticos en el aprendizaje profundo y el aprendizaje por refuerzo para que los motores de ajedrez alcanzaran un nivel superhumano (aproximadamente 3200 ELO). Pero una vez que se alcanzó esa estratosfera alrededor de 2017, algo muy sorprendente sucedió. Bueno, en realidad, dos cosas sucedieron. La primera cosa fue completamente esperada; los motores se convirtieron en la fuente de “verdad fundamental” en el 99% de todas las posiciones. En la práctica, eso significaba que entrábamos en la “era de la confianza ciega” en el motor. Hoy en día, es virtualmente imposible para un ser humano proponer un movimiento significativamente mejor que el motor. Tan entretenido como era el “ajedrez avanzado”, ahora es un ejercicio inútil; los humanos contribuirían casi nada al juego. Pero la segunda cosa fue impactante para la mayoría de los jugadores de ajedrez. Estos motores de ajedrez superhumanos neurales (es decir, redes neuronales profundas) a veces jugarían en un estilo que se puede describir mejor como “romántico”. En otras palabras, harían movimientos cuyo valor solo se podía apreciar muchos, muchos movimientos después, mucho más allá de lo que cualquier ser humano o motor de clase mundial podría calcular. Se sentía mucho como si los motores hubieran desarrollado un “sentimiento” o una “intuición” para ciertas posiciones. Excepto que esta intuición no es algo que un ser humano pueda comprender o imitar.

Dicho de otra manera, un motor de ajedrez superhumano neural puede hacer movimientos que están más allá del horizonte cognitivo de un ser humano. Este es el punto crítico aquí; el problema no es de explicabilidad. Más bien, un ser humano simplemente no puede comprender por qué un motor recomienda un movimiento sin jugar la posición y observar el resultado muchos movimientos después, es decir, desenrollando toda la trayectoria de secuencias de juego posibles. Como resultado, tenemos una brecha insuperable en capacidad. Es óptimo aceptar la salida del motor sin revisión. Puedo resumir mi afirmación de la siguiente manera:

El ajedrez es una prueba de existencia de que la IA superhumana operaría efectivamente de forma autónoma en algunos dominios. Permitir que el sistema de IA tome decisiones sin revisión humana sería la forma óptima de implementar dicho sistema.

Dado que mi afirmación puede parecer obvia o poco notable, quiero destacar un par de matices. Supongamos que tenemos un sistema de IA que demuestra un nivel superhumano en una tarea compleja y crítica con consecuencias concretas e irreversibles. Hay dos implicaciones para mi afirmación:

1. El sistema se implementaría para tomar decisiones para la tarea sin revisión humana, a pesar del riesgo inherente
2. La comprensión obtenida al monitorear dicho sistema no preveniría una decisión perjudicial; el daño ya se habría hecho

La revisión de la salida y el monitoreo son precisamente las dos últimas capas de defensa contra los ataques de inyección de prompt. Por lo tanto, nuestro hipotético ataque de inyección de prompt podría sortear estas capas simplemente apuntando al sistema correspondiente.

Esta es una escenario muy realista en mi mente. Un sistema de IA superhumano en un dominio específico no es una IA general, y la mayoría de los expertos cree que dichos sistemas están justo alrededor de la esquina. También no tuvimos que suponer que las decisiones son urgentes, solo que la tarea es lo suficientemente compleja como para hacer que la revisión humana sea intractable.

Por supuesto, solo hemos sorteado dos capas de defensa hasta ahora, y afortunadamente para nosotros, se han desarrollado varias otras. Para abordar el resto, vamos a profundizar en los elementos fundamentales que hacen que la inyección de prompt sea difícil de defender.

¿Qué es la Inyección de Prompt?

La inyección de prompt es una manipulación de un Modelo de Lenguaje Grande (LLM) a través de entradas elaboradas, lo que hace que el LLM ejecute involuntariamente las intenciones del atacante. Puede considerarse como ingeniería social para la IA. Crucialmente, no es un error de software convencional. Un ataque de inyección de prompt explota una vulnerabilidad inherente del LLM. Dado que los LLM procesan tanto las instrucciones del sistema como las del usuario como secuencias de texto, no pueden distinguir intrínsecamente entre instrucciones legítimas y dañinas. La vulnerabilidad es, por lo tanto, efectivamente por diseño, en lugar de por accidente.

Técnicas de Inyección de Prompt

La inyección de prompt se reconoce generalmente como el #1 riesgo para las aplicaciones de LLM. Hay varias razones por las que es así. El factor más obvio es la variedad de técnicas de inyección que se han desarrollado. Agrupándolas aproximadamente en cuatro categorías, las técnicas más conocidas incluyen:

• Sintáctico: utilizando caracteres especiales, emoticonos o lenguaje alternativo
• Indirecto: utilizando fuentes externas (recuperar desde el sitio), codificación (base 64), o referencia multimodal (texto en imagen)
• “Finjamos”: introduciendo un estilo manipulador mediante, por ejemplo, hacer de las suyas, hipotético, apelación emocional, marco ético y cambio de formato
• Brusco: intento explícito de “manipular” las instrucciones del modelo mediante fuerza bruta, refuerzo o prompt negativo

La variedad sola proporciona un desafío para los desarrolladores de aplicaciones, pero estos ataques también han seguido evolucionando rápidamente. El lado izquierdo del diagrama a continuación pretende describir el estado del arte para principios de 2023, mientras que el lado derecho refleja la naturaleza de los ataques de hoy.

Los desarrolladores de aplicaciones de LLM también deben tener en cuenta el tradeoff estándar entre usabilidad y seguridad. Podrían introducir cada capa de defensa y patrón de diseño apropiados, pero ¿a qué costo? Las capas de defensa agregan una latencia significativa e introducen falsos positivos (FP) – incorrectamente marcando como maliciosos los prompts seguros – ambos factores tienen un impacto negativo en la experiencia del usuario. Como resultado, algún nivel de compromiso es inevitable en la práctica, y no hay solución “de bala de plata”.

Sin embargo, en este artículo, no estoy realmente interesado en este juego de gato y ratón interminable. Más bien, estoy explorando si un ataque puede ser imposible de prevenir en principio. Desde la perspectiva del desarrollador/defensor, hay una sola idea clave:

La separación de instrucciones de datos en el prompt es fundamental para abordar el riesgo de inyección de prompt

Podemos asumir que los tradeoffs no son un factor, y cualquier capa de defensa o técnica se puede utilizar. Bajo esta (fuerte) suposición, ¿es posible concebir un escenario en el que la separación de instrucciones y datos en un prompt sea efectivamente imposible?

La Analogía del ADN

Una vez que el problema se planteó en términos de separación de instrucciones y datos, mi primer pensamiento fue utilizar la biología como una analogía.

Consideremos una célula y un tramo de ADN (conocido como un gen). El gen proporciona instrucciones para construir una proteína a través de la transcripción y la traducción. También codifica la información (datos) que impacta la estructura y la función de la proteína. Como tal, el gen dicta simultáneamente qué construir y cómo construirlo, o así razoné. Sin embargo, esto es simplemente falso, ya que un gen no decide cómo interpretarse a sí mismo. No hay equivalente de seguidor de instrucciones en biología a nivel de gen. El “cómo” se externaliza completamente a la maquinaria celular.

Por lo tanto, incluso si no puedo sacudir la sensación de que las generaciones futuras de LLM – o más precisamente, los sistemas en los que evolucionan – se parecerían mucho más a máquinas biológicas, la analogía propuesta simplemente no funciona. No podemos sustituir una célula por un LLM y un gen por un prompt y luego realizar una inyección en el gen que eventualmente causaría que se construya una “proteína dañada”, parece más productivo ceñirse al lenguaje natural y a las tareas que requieren interpretación semántica.

Despojando las Capas de Defensa

No debería sorprender que las estrategias de defensa en capas múltiples se consideren más efectivas para detener los ataques de inyección de prompt. La imagen a continuación muestra las capas de defensa más comunes en orden, y las técnicas asociadas utilizadas en cada capa.

Ya hemos discutido las dos últimas capas (salida, monitoreo) anteriormente, así que centrémonos en las primeras cuatro.

Considerando la capa de entrada, es razonable asumir que la sanitización o validación del prompt sería bastante exitosa para detectar ataques indirectos. Sin embargo, si la inyección se entrega directamente, y como se sugirió anteriormente, confiando en la interpretación semántica, quizás la sanitización es irrelevante (nada que sanear), y la validación es imposible por defecto, ya que el cálculo debe completarse para identificar el problema.

Esencialmente no hay límites a los guardrails que podrías construir en la capa de detección. De hecho, podrías incluso utilizar un LLM dedicado para detección de inyección. Pero una vez más, será difícil para un clasificador o un detector de anomalías marcar un prompt como sospechoso cuando el veneno está astutamente oculto dentro de la semántica.

La capa del modelo puede ser muy efectiva cuando el alcance de las tareas es estrecho y es factible el ajuste fino. Un argumento similar podría hacerse para la capa del sistema cuando el uso de herramientas es predecible. Sin embargo, al menos intuitivamente, ninguno de los dos levantaría una alarma si la inyección desvía al intérprete.

Casa de Cartas

Mi intención cuando comencé a escribir este artículo era describir un “ataque de inyección de prompt imposible de prevenir” en términos generales. Quizás terminé siguiendo un enfoque “no constructivo” al señalar agujeros en las capas de defensa existentes. Técnicas defensivas siguen evolucionando rápidamente, y también lo hace la superficie de ataque. Este juego no muestra signos de terminar pronto. Sin embargo, también creo que no seremos los que estén jugando durante mucho tiempo. Apostaría a que el ataque de inyección de prompt exitoso en el futuro seguiría siendo en lenguaje natural, solo que en un lenguaje que los humanos no pueden entender; y apostaría a que sería auto-descubierto por un sistema construido con ese propósito específico o quizás accidentalmente después de abordar una tarea relacionada, como buscar ambigüedad semántica en algún espacio de representación.

Hay algo desagradable en admitir que estamos perdiendo el control y sin embargo sentir que esto es lo más racional que hacer. Puedes considerarlo como la “prueba intuitiva” de que algunos ataques serían imposibles de detener. Y si eso te deja incómodo, te alegrará saber que GPT 5.2 encontró que este argumento no es “controvertido ni novedoso” y abogó por que no “insista en el punto” y reduzca un 40% del artículo.