Prompt Injection Protections: Jatmo, StruQ, SecAlign & Instructional Segment Embedding

Las técnicas de Prompt Injection se ha convertido en OWASP Top Ten for LLM Apps & Services en el equivalente al SQL Injection fue en el mundo de las técnicas de Hacking Web Technologies. Es por eso que las propuestas para proteger el nuevo mundo de servicios digitales soportados por modelos de IA necesitan desarrollar nuevas formas de protegerse contra estos ataques, y los investigadores están haciendo muchas propuestas de valor al respecto.

Figura 1: Prompt Injection Protections: Jatmo, StruQ,

SecAlign & Instructional Segment Embedding

Hoy os quiero hablar de algunas de estas técnicas, para que entendáis la propuestas, porque los papers son más que interesantes para su lectura, y te van a ayudar a proteger tus servicios cuando hagas uso de las capacidades que nos ofrecen los MM-LLMs hoy en día, que son maravillosas, pero hay que usarlos de forma securizada.

Jatmo: Prompt Injection Defense by Task-Specific Finetuning

La primera de las que os voy a hablar es la propuesta Jatmo, que busca diferenciar entre el Prompt en el modelo y los datos de Contexto que pueden llegar a desde un punto externo al modelo, como una base de datos en una arquitectura RAG (Retrieval Augented Generation), documentos en un repositorio de mensajes, o de simplemente páginas webs en Internet. En este caso, el atacante introduce el Prompt Injection en un dato que va a ser cargado cuando se alimente el contexto al Prompt del developer desde una fuente externa no confiable.

Figura 2: Prompt Injection desde una Web externa con datos consultada

Para evitar esto, hay que dejar muy claro cuáles son los datos confiables, que en nuestro caso serían los que introduce el desarrollador, y los que vienen y no son confiables por proceder  de fuentes externas no verificadas. Y en esto consiste la propuesta de Jatmo que puedes leer en su paper.

Figura 3: Jatmo -Prompt Injection Defense by Task-Specific Finetuning

En el ejemplo presentado antes, el atacante aprovechar que el servicio que va a usar LLM usa una arquitectura donde consulta y carga datos externos para generar un contexto al modelo antes de que éste dé la respuesta. Y en esos datos introduce el Prompt Injection, como en este ejemplo.

Figura 4: Prompt Injection en datos externos

Para resolver esto hay que entender que, al igual que en las técnicas de SQL Injection, se está componiendo un Prompt de entrada al modelo LLM basado en datos del desarrollador y datos del atacante, así que habría que diferenciarlos bien.

Figura 5: Estructura de la consulta vulnerable y cómo el atacante lo explota

Y la propuesta de Jatmo es tan sencilla como cargar el modelo y los datos por separado. Es decir, mientras en la forma natural se hace una concatenación del Prompt con los datos del contexto, en la propuesta de Jatmo el desarrollador genera una tarea para cada Prompt y los datos para esa tarea se cargan con modelo cargado e instruido para tomar el resto de los datos como datos.

Figura 6: Propuesta de crear procedimientos con modelos

configurados por tareas a realizar en el servicio

Esto reduce la superficie de exposición al limitar las acciones que va a realizar el modelo que se está utilizando a un conjunto de ellas predefinidas y todo lo demás lo debe tomar como datos, lo que hace más complejo que un LLM reciba peticiones de comandos que no estén definidas por el desarrollador del servicio.

StruQ: Defending Against Prompt Injection with Structured Queries

El segundo de los papers del que os quiero hablar es de Septiembre del año pasado, y habla de generar Prompt Etiquetados como Structured Queries. Es decir, detectar, marcar y etiquetar de una determinada manera los datos de un Prompt para que el modelo LLM no sufra ataques de Prompt Injection.

Figura 7: StruQ - Defending Against Prompt Injection with Structured Queries

El proceso propuesto es como el que podéis ver en la imagen anterior. De nuevo, se trata de diferenciar entre el Prompt introducido por el desarrollador, y los datos procedentes de una fuente externa no confiable, donde puede venir el Prompt Injection. En este caso, además de utilizar todas las técnicas de análisis de la seguridad del Prompt de entrada - además de analizar los resultados de salida después -, el objetivo es etiquetar los datos.

Figura 8: Pipeline del procesado de StruQ para evitar Prompt Injection

En el gráfico anterior se ve cómo se quitan todas las etiquetas que pudiera haber introducido el atacante, para luego etiquetar el Prompt, los datos y la repuesta con un [MARK][INST][COLN] para las instrucciones, y [MARK][INPT][COLN] para los datos de entrada, y [MARK][RESP][COLN] para que el programador recoja la respuesta, tal y como tenéis en el ejemplo siguiente, que son datos de entrenamiento para detectar las etiquetas.

Figura 9: Entrenado del análisis del modelo etiquetado con StruQ

para procesar después en el LLM

El resultado es que, las técnicas de Prompt Injection o Jailbreak de las que he hablado tanto por aquí, como la de Tree-of-Attacks with Pruning, por ejemplo, se verían "parametrizadas" y serían fácilmente bloqueables con una arquitectura tipo Jatmo vista anteriormente.

Figura 10: Etiquetado StruQ de un Prompt Injection

de Tree-of-Attacks with Pruning

El resultado ayuda a mejorar la seguridad de los Prompts que se van a realizar, pero aún se pueden mejorar las protecciones contra estos ataques de Prompt Injection, y lo vemos en los siguientes papers.

SecAlign: Defending Against Prompt Injection with Preference Optimization

El objetivo de este paper es hacer más robusto el análisis del Prompt de entrada ya marcado, haciendo un alineamiento de seguridad en su análisis. Es decir, se trata de entrenar el modelo de análisis de datos para detectar los ataques dentro de las etiquetas, con datos reales y sintéticos que puedan ayudar al modelo a procesar correctamente el Prompt y detectar intentos de ataques

Figura 11: Optimización de SecAlign con DPO

En este caso, como podéis ver, el modelo es entrenado con datos en los que se le dice cuál es la respuesta deseable y cuál la no deseable, para que él pueda saber si lo ha hecho bien o no. Estas técnicas de DPO "Direct Preference Optimization" ayudan a entrenar el modelo para que aprenda las estructuras de los ataques de Prompt Injection.

Figura 12: SecAlign: Defending Against Prompt Injection

with Preference Optimization

Todo el trabajo de SecAlign con los diferentes tipos de técnicas de Prompt Injection y Jailbreak, los tienes explicados en el paper, además del resultado de detección de los mismos sin protección, con las técnicas SOTA (State-Of-The-Art) en Prompting-Base Defense y en Fine-Tunning Defense y por último con SecAlign Fine Optimization.

Figura 13: Comparación de resultados

En la izquierda tenéis el bechmark de ApacaEval2 y en la segunda por los valores de Max ASR (Attack Success Rate) de las baterías de pruebas. 

Figura 14: AlpacaEval 2.0 Leader Board

Instructional Segment Embedding: Improving LLM Safety with Instruction Hierarchy

El último de los papers de los que os voy a hablar hoy - que ya ha quedado muy largo el post de hoy, tiene que ver con los ISE "Instructional Segment Embeddings", donde se ataca la falta de herencia a la hora de clasificar cuáles son los Prompts del Sistema, cuáles los Prompts del Desarrollador y cuáles los Prompts en Datos externos no confiables, lo que hace que se puedan atacar los servicios basados en LLMs.

Figura 15: Diferentes tipos de Prompts de entrada y Output

No tener claro la jerarquía de herencia entre unos y otros hace que los que vienen por Data pueden llegar a contradecir lo que ha venido desde el System,  o el Developer (USER en el ejemplo anterior), y esto lleva a que se puedan hacer ataques de Prompt Injection, Prompt Extraction o Harmful Requests.

Figura 16: Diferentes tipos de Prompts Attacks

Para corregir esta debilidad en el modelo, lo que propone el trabajo de Instructional Segment Embedding: Improving LLM Safety with Instruction Hierarchy es no tener los mismos tipos de tokens para construir los Prompts, sino que se puedan diferenciar con una jerarquía los diferentes tokens con los que va a trabajar el LLM.

Figura 17: Instructional Segment Embedding

Improving LLM Safety with Instruction Hierarchy

Como se puede ver en la imagen, se crean diferentes tipos de embeddings para los diferentes tipos de niveles de datos de entrada que tiene que procesar el modelo LLM, ayudando a que se puedan procesar con diferentes niveles de prioridad.

Figura 18: Instructional Segment Embeddings

Con esta etiquetado, el paper presenta resultados experimentales que en los benchmarks de Alpaca los resultados son muy positivos. 

Final Thought

Al final, todos estos papers llevan a una conclusión de la que he hablado muchas veces en mis charlas, que no es más que el modelo de Seguridad por Diseño en los LLMs hace falta, y por eso estamos viendo tantos trabajos en ese área y, como veremos en un post posterior, ya tenemos propuestas en esa línea. Os contaré más.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)