PROMISQROUTE para GPT-5: Un ataque de downgrade forzando el Routing para hacer Jailbreak

Hoy no sé si te trata de un bug o de una debilidad que ayuda a explotar los bugs, pero desde luego es un Security Issue en la arquitectura de GPT-5 que ha sido publicado esta semana bajo el nombre de PROMISQROUTE, que ha es el acrónimo elegido con para el ataque, bajo la descripción de "Prompt-based Router Open-Mode Manipulation Induced via SSRF-like Queries, Reconfiguring Operations Using Trust Evasion." Sí, ha quedado un poco forzado, pero yo fui que el que denomino a un proyecto FOCA (Fingerprinting Organizations with Colleted Archives), así que no voy a quejarme para nada del nombre elegido.

Figura 1: PROMISQROUTE para GPT-5 - Un ataque de

downgrade forzando el Routing para hacer Jailbreak

Lo que es cierto es PROMISQROUTE, sea vulnerabilidad o debilidad, permite evitar los Guardrails de GPT-5, haciendo que una aplicación conectada a GPT-5 pueda ser degradada a modelos más inseguros con los que se pueda hacer un ataque de Jailbreak. Es decir, a pesar de estar conectado a GPT-5, puedes acabar sufriendo un Jailbreak de GPT-4 porque te han hecho un downgrade con PROMISQROUTE.

Figura 2: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso, 

La magia de todo esto es que GPT-5 es un modelo muy costoso, que no tiene sentido utilizar en todo tipo de Prompts, por lo que la arquitectura con la que se ha diseñado GPT-5 hace un enrutado, un routing del Prompt hacia el modelo más eficiente en cada casa, lo que permite ahorrar costes y ganar en eficiencia en muchas ocasiones.

Figura 3: Arquitectura de modelos en ChatGPT-5

El gráfico superior muestra una arquitectura - inferida, así que no tomes como que es 100% fiable - la estructura de modelos que tiene GPT-5 para resolver las Prompts. Esta arquitectura de modelos permite hacer una gestión eficiente de los recursos tanto en costes como en tiempo de repuesta, como en resolución de las peticiones.

Figura 4: Tier 2 para la Selección de Modelos

Así, cuando llega un Prompt, la arquitectura procesa a tres niveles el Prompt, eligiendo en la Capa 2 el mejor modelo para resolver el Prompt enviado por el usuario, así que se analiza la petición que envía el usuario y se elige uno de los modelos de la Figura 3 para que la resuelva.

Figura 5: Selección de Modelo en función de la tarea

No es lo mismo una tarea sencilla y creativa, que una resolución compleja que exija un modelo de Deep Reasoning como GPT-5 Thinking, que seguro que da la mejor respuesta. Esto lo decide el proceso de Routing en la Capa 2 analizando la petición del usuario. La estimación de distribución de cargas de los diferentes modelos, según el uso de los usuarios se estima así.

Figura 6: Estimación de la distribución de enrutamiento

En el interfaz de ChatGPT esto lo puedes ver con las opciones de GPT-5 que tienes, donde si eliges AUTO dejas que sea el Router el que seleccione el modelo para atenderte, mientas que si pones GPT-5 Thinking estás forzando el modelo concreto de GPT-5 con los Guardrails que trae.

Figura 7: Modo de funcionamiento de ChatGPT 5

Pero si el Router está en AUTO y te asignan un GPT-4o los Guardrails que funcionan son los de este modelo, y eso implica que si hay un Jailbreak conocido para él, entonces funciona. El truco entonces, si una App o Service está conectado a GPT-5 en modo AUTO, está en forzar que use un modelo anterior del que se conoce una técnica de Jailbreak, y así conseguir saltarse las protecciones.

Un ejemplo practico de PROMISQROUTE

En este primer ejemplo, com podéis ver, se pide un Prompt que implica un análisis, así que aunque está en modo AUTO, la arquitectura de ChatGPT enruta hacia el modelo de Deep Reasoning de GPT-5 Thinking y los Guardrails detectan el Harmful Mode y bloquean el Prompt Malicioso.

Figura 8: ChatGPT 5 ha enrutado a GPT-5 Thinking y bloquea el Prompt

Si veis en la Figura 8 anterior, GPT-5 detecta el Harmful Mode porque el Router ha asignado GPT-5 Thinking para resolver ese Prompt bloquea la petición, mientras que en la figura siguiente, en modo AUTO, GPT-5 es afectado por el Jailbreak y ejecuta el Prompt Malicioso saltándose la detección del Harmful Mode sólo porque se ha forzado una respuesta rápida con PROMISQROUTE.

Figura 9: PROMISQROUTE en GPT-5 hace downgrade y

ejecuta el Jailbreak porque ha enrutado a GPT-4

Para forzar el enrutado hacia modelos anteriores, es decir, para hacer el Downgrade de modelos en GPT-5 lo que propone PROMISQROUTE es utilizar peticiones en el Prompt que metan la importancia de velocidad para que el tiempo de respuesta sea relevante, lo que evita los modelos pesados como el modelo de Deep Reasoning GPT-5 Thinking. 

Figura 10: El Prompt de PROMISQROUTE no funciona si se fuerza GPT-5 Thinking

Si seleccionamos el uso de GPT-5 Thinking vemos que el Prompt de PROMISQROUTE no funciona, por lo que afecta sólo cuando está en modo AUTO. Si esto es así, utilizar Prompts como los siguientes permiten forzar el enrutamiento hacia modelos anteriores y conseguir evitar los Guardrails de GPT-5.

Figura 11: Prompts de PROMISQROUTE para forzar el downgrade

Al final, como podéis ver, no es un método de Jailbreak, y tampoco creo que sea una vulnerabilidad, sino una "Weakness" que, conocida, ayuda a seleccionar el punto menos protegido de una aplicación o un servicio que esté utilizando en su arquitectura GPT-5 con el routing AUTO. Muy curioso.

Figura 12: Keep quick, Keep quick. Versión más rápida de PROMISQROUTE

Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Taxonomía de Fallos de Seguridad en Agentic AI: Memory Poisoning Attack con Cross-Domain Prompt Injection Attack (XPIA)

El equipo AI Red Team de Microsoft publicó hace unas semanas un interesante White Papper en el que recoge un Taxonomía de Fallos de Seguridad en la implementación de Agentic AI dentro de las empresas que pueden afectar al Safety & Security de la compañía. El documento no sólo recoge dicha taxonomía sino que además añade una lista de medidas y controles que pueden implementarse para corregir dichos riesgos.

Figura 1: Taxonomía de Fallos de Seguridad en Agentic AI.

Memory Poisoning Attack con Cross-Domain Prompt Injection

Attack (XPIA)

El White Paper, titulado "Taxonomy of Failure Mode in Agentic AI Systems" puedes descargarlo desde el sitio web de Microsoft, y además contiene un interesante caso de estudio que vamos a ver a continuación, ya que es un ataque a un Agentic AI implementado sobre una arquitectura RAG con Memory que es muy ilustrativo.

Figura 2: White Paper "Taxonomy of Failure Mode in Agentic AI Systems"

La taxonomía de los fallos de controles de riesgos que puedan afectar al Safety & Security del sistema los han recogido en esta tabla, donde puede que te sorprenda alguna de la clasificaciones, pero que a lo largo del white paper recorren para explicarlas bien.

Figura 3: Taxonomía de Safety & Security Risks en Agentic AI

En la tabla, como puedes ver, hay una lista de nuevos ataques que se abren con la existencia de plataformas de Agentic AI, como el compromiso de Agentes AI, la Inyección de un  Agente AI malicioso en la plataforma, la Suplantación de Agentes AI, la manipulación de flujo de orquestación de los (Hijacking) Agentes AI, hacer Jailbreak a Agentes AI o la provisión maliciosa de nuevos Agentes AI infectando Templates o System Prompts manipulados. 

Figura 4: Gestión de la seguridad de sistemas Agentic AI

Todos estos nuevos ataques llevan a problemas que pueden afectar también al Safety de la compañía y las personas, y a que haya que implementar nuevos roles de seguridad dentro de las organizaciones que están implantando plataformas de Agentic AI, como podéis ver en la imagen anterior.

Cross-Domain Prompt Injection Attack (XPIA) para hacer un Memory Poisoning

En el white paper viene un caso de estudio muy interesante de lo que sería un Indirect Prompt Injection, que en la nomenclatura del documento que ha puesto el equipo de Microsoft es Cross-Domain Prompt Injection Attack o XPIA, y que lo que hace es un envenenamiento malicioso de la Memory del Agente AI, lo que sería un Memory Poisoning Attack.

Figura 5: Arquitectura de Agentic AI para procesar el correo

Para que se entienda el ataque y todas las implicaciones, tenemos un sistema de Agente AI, como el que se ve en la imagen anterior, que está procesando el correo electrónico de una persona, y para ello cuenta con una arquitectura RAG donde almacena todo conocimiento del buzón del usuario, y una Memory donde va recordando lo que va aprendiendo, y tres acciones a realizar.

Procesar y ejecutar una acción asociada al correo electrónico, rechazar el mensaje o, si no puede procesarlo, notificar al usuario. Es decir, como un sistema de reglas avanzado usando un Agente AI. Para configurarlo, se ha diseñado un System Prompt como el que podéis ver aquí, en el que se le ha definido hacer uso de la Memory tanto para decider la acción, como para recordar cosas que sean útiles para su gestión, por lo que debe actualizar la Memory también.

Figura 6: System Prompt del Agente AI de correo

Una vez esto, un atacante envía un correo malicioso con una orden para actualizar la Memory del Agente AI de gestión de los e-mails, en el que se le solicita que haga un reenvió de los mensajes, referentes a un determinado tema o que vengan de una determinada persona, a una dirección de e-mail de un atacante.

Figura 7: Envío de un e-mail con el XPIA 

Esto lo que provoca es que, el Agente AI, siguiendo su System Prompt, recuerde este comando y actualice su Memory, lo que hará que recuerde esa acción para procesar los mensajes de correo electrónico que lleguen a la plataforma. Es decir, tendremos un Memory Poisoning Attack con éxito.

Figura 8: Memoria del Agente AI envenenada con acción maliciosa

Este ejemplo se puede hacer con cualquier otra acción, como podemos ver en este ejemplo donde el XPIA para hacer el Memory Poisoning llega para mensajes relativos a un determinado tema, pidiendo además confirmación al remitente.

Figura 9: XPIA para envenenar la Memory del Agentic AI

Y por supuesto, como la acción queda registrada en al Memory, cuando se da esta circunstancia, se envían los mensajes a la dirección inyectada, y una confirmación al remitente del mensaje de XPIA, con lo que monitoriza todo lo que está pasando dentro de ese buzón de correo relativo a este tema.

Figura 10: Envío de los correos por el Agente AI

Por supuesto, este ataque se puede utilizar para los ataques de robo de facturas en los que utilizábamos robos de Tokens OAuth, y pueden ser un serio peligro para las personas que estén utilizando estos Agentes AI para gestionar el correo electrónico.

Protecciones y Conclusiones

Comprobar la seguridad de los Agentes AI es fundamental, y hay que establecer muchas medidas para esto. Por supuesto utilizar las Guardrails AI para fortificar estas plataformas, como el caso de Llama Prompt, Llama Guard o Llama Firewall.

Figura 11: Demo de Llama Firewall en LlamaCON 2025

Además, hay que asegurarse de seguir todas las guías de diseño seguro de Agentes AI, haciendo especial hincapié en la instrumentalización, el registro de logs, y la generación de alertas. Estamos hablando de tecnologías muy nóveles que aún estamos descubriendo. 

Figura 12: Arquitectura de CaMeL con P-LLM, Q-LLM & Capabilities

Tenemos propuestas para diseñar agentes como Jatmo, StruQ, SecAlign & Instructional Segment Embedding o el caso de Google CaMeL para diseñar de forma segura Agentes AI, pero todavía nos queda mucho camino que recorrer en este sentido, así que... ponte las pilas que hay mucho que securizar.

PD: Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: Inteligencia Artificial (Hacking & Security): Links, Posts, Talks & Papers

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cómo saltarse los AI Guardrails con Invisible Characters & Adversarial Prompts para hacer Prompt Injection & Jailbreak Smuggling

Hoy vuelvo a hablaros de este tema que es de vital importancia para lo que estamos construyendo, pues estamos desarrollando muchos servicios con LLMs en el Backend, y las técnicas de Jailbreak y Prompt Injection no están ni mucho aún superadas por los equipos de seguridad, lo que está llevando a que todos los investigadores estén estudiando este tema. 

Figura 1: Cómo saltarse los AI Guardrails con

Invisible Characters & Adversarial Prompts para

hacer Prompt Injection & Jailbreak Smuggling

Hoy os hablo de un paper publicado por la empresa Midgard donde se centran en hacer Attack Smuggling  o AI Guardrail Bypass, como quieras llamarlo. Al final, como os contaba en la charla de Hackin’ AI: Creando una IA… ¿Qué puede salir mal?, no hemos creado los modelos de Inteligencia Artificial pensando en Seguridad desde el Diseño, y ahora tenemos que arreglarlo.

Figura 2: Hackin’ AI: Creando una IA… ¿Qué puede salir mal? por Chema Alonso

Básicamente, el trabajo que os cuento trata de saltarse los filtros de seguridad que evalúan los datos de entrada vía Prompt y los datos de salida, vía respuesta, para detectar los ataques. El paper se llama "Bypassing Prompt Injection and Jailbreak Detection in LLM Guardrails" y lo tienes aquí.

Figura 3: Bypassing Prompt Injection and Jailbreak Detection in LLM Guardrails

La idea es sencilla. Se trata de probar primero cómo los AI Guardrails se comportan con diferentes técnicas de emitir tokens pero usando codificaciones invisibles, y Prompts Maliciosos, para ver si se puede hacer un bypass de la detección. Tienes un resumen del trabajo el blog post que ha publicado la compañía, titulado: "Outsmarting AI Guardrails with Invisible Characters and Adversarial Prompts"

Figura 4: Concepto de AI Guardrail

Los Guardarraíles de LLMS son esas herramientas como Llama Guard, Prompt Guard, Llama Firewall, CodeShield o AligmentCheck que están diseñados para controlar el Prompt que entra, y las acciones que se ejecutan para evitar los ataques de Prompt Injection o Jailbreak.

Figura 5: Demo de Llama Firewall en LlamaCON 2025

Una vez entendido cómo funcionan los AI Guardrails, la idea es enviar los Prompts Maliciosos utilizando Invisible Characters, y para eso hay que ver primero qué tipos de métodos existen para colar un token usando una de estas codificaciones y que el LLM objetivo se lo "coma".

Figura 6: Técnicas Character Injection para

pasar de contrabando el token "Hello"

Y ahora los resultados con los AI Guardrails. En este estudio han probado los siguientes, a saber: Azure Prompt Shield, Protect AI v1 & v2, Llama (Meta) Prompt Guard &Vijil Prompt, y los resultados en el Attack Surfare Rate con las diferentes técnicas anteriores son los que podéis ver con los Dataset de Prompt Injection.

Figura  7: Attacks Surface Rate Bypassing AI Guarrails con

Character Injection Techniques para Datasets de Pompt Injection

Y con las diferentes técnicas de Jailbreak, los resultados son igual de buenos, donde como puede verse para todos los AI Guardrails existe alguna técnica de Invisble Character que permite saltarse el 100 % de los casos.

Figura  8: Attacks Surface Rate Bypassing AI Guarrails con

Character Injection Techniques para pruebas de Jailbreak

Ahora lo mismo, pero introduciendo Datasets de Prompts Maliciosos que cambian el comportamiento del flujo de ejecución del LLM en los diferentes ataques. Ejemplos como el del juego de rol que utilizó yo desde hace un par de años. 

Figura 9: Detección de palabras que generan el bloqueo

del Prompt y búsqueda de su substitución con otro LLM.

En este caso, se han utilizado diferentes técnicas de pruebas para poder evaluar su funcionamiento contra los diferentes modelos de AI Guardrails usando Adversarial Machine Learning (AML) Evasion Techniques, basadas en reemplazo de palabras para saltarse un clasificador basado en algoritmos de Machine Learning, que es lo que hacemos en muchos de las aplicaciones de Ciberseguridad.

Figura 10: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Las técnicas de AML Evasion que se han utilizado para la prueba son las que tienes detalladas a continuación en la siguiente tabla.

Figura 11: Adversarial Machine Learning (AML) Evasion Techniques

Y los Attack Surface Rate para cada una de estas técnicas aplicado a los DataSets de Prompt Injection y Jailbreak, son los que tienes en las siguientes tablas, donde como se puede ver todos los AI Guardrails se ven afectados por estas técnicas.

Figura 12: Resultados de ASR para las técnicas de AML Evasion

Después de ver todo este trabajo, la primera reflexión es que, viendo la avalancha de ataques de Prompt Injection y Jailbreak, y cómo las protecciones aún no están funcionando, es que estamos como cuando diseñamos los lenguajes de creación de aplicaciones web sin pensar en seguridad por diseño o cuando los sistemas operativos no tenían una arquitectura de seguridad desde su concepción. Ahora, vamos a pasar un largo tiempo sufriendo por esto, lo que nos va a llevar a muchos incidentes de seguridad que irán llegando poco a poco... veremos..

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Llama Protections: LlamaFirewall con PromptGuard 2, LlamaGuard 4, AlignmentCheck, CodeShield + AutoPatchBench & CyberSecEval 4

Ayer Meta lanzó oficialmente Llama 4 Behemoth, pero además puso sobre la mesa un montón de mejoras y anuncios de seguridad sobre los que ya tenía. No hace mucho yo os había hablado de CyberSecEval 3, Llama Guard 3, Code Shield y Prompt Guard, pues bien, ahora ha actualizado las versiones de todas esas medias de seguridad a CyberSecEval 4, Llama Guard 4, Prompt Guard 2, y se han añadido AligmentCheck, AutoPatchBench a CodeShield y LlamaFirewall, que os paso a contar aquí mismo. Mucho tema.

Figura 1: Llama Protections. LlamaFirewall con PromptGuard 2,

 LlamaGuard 4, AlignmentCheck, CodeShield + AutoPatchBench

& CyberSecEval 4

Como os podéis imaginar, las actualizaciones son muchas, así que os invito a que leáis en detalle los artículos de todos los productos, que han sido puestas online el mismo día que tuvo lugar la LamaCON 2025, así que tienes material para estudiar, donde además se anunciaron Llama API y Meta AI como aplicación, así que hay material para jugar.

CyberSecEval 4

Como ya os conté, CyberSecEval es una metodología de evaluación para tener un benchmark de todos los riesgos de ataque que puede sufrir un modelo LLM para tener bien medido el nivel de seguridad de la respuesta. Ha sufrido una actualización, y en la metodología han añadido las nuevas técnicas de Prompt Injection, Jailbreak, y nuevas amenazas que han ido descubriéndose.

Figura 2: CyberSecEval 4 en GitHub

Por supuesto, como os podéis imaginar, desde la salida de Llama 4 Maverick y Llama 4 Scout, y el reciente Llama Behemoth, tenían que actualizar los Benchmarks con ellos. Ahora la tienes disponible en GitHub, y tienes una guía de usuario de cómo utilizarla para poder ejecutar los Benchmarks.

Figura 3: CyberSecEval 4 Benchmarks

Como verás, se pueden obtener resultados de comportamiento contra todos los Datasets relativos a MITRE y False Refusal Rate, Prompt Injection, Explotación de Vulnerabilidades, ataques de Spear Phishing, Operaciones de Seguridad Ofensiva, etcétera.

Llama Guard 4

Actualización del modelo Llama Guard 4 que tiene como única función detectar si un Prompt es malicioso o no. Este LLM es ahora nativamente Multi-Modal y permite Pompts con imágenes, textos, etcétera, lo que ayuda a la detección de los Pompts Maliciosos.

Figura 4: Llama 4 Guard

Al igual que la versión anterior, está alienado con la taxonomía de ataques definida en  el paper de Introducing v0.5 of the AI Safety Benchmarkfrom MLCommons y puedes descargar el modelo desde la web de descargas de Llama.

Figura 5: Llama Guard 4 vía API. Ejemplo.

Además, con el anuncio de Llama API, ahora es posible consultarlo también via API y recibir la respuesta con una sola línea de código que puedas introducir en tus servicios digitales.

Prompt Guard 2

El equipo de seguridad de Llama también ha actualizado Prompt Guard a la versión 2, poniendo a disposición pública la herramienta diseñada para detectar ataques. Su objetivo no es únicamente detectar Prompt Maliciosos como Llama Guard, sino detectar un ataque de Prompt Injection, Jailbreak, Exfiltración de Datos, etcétera en un servicio basado en LLMs.

Figura 6: Prompt Guard 2

En la siguiente imagen se ven diferentes tipos de análisis de Prompt Injection y Jailbreak donde está evaluando si algunos de los Prompt son reconocidos como parte de ataques para tener un catalogación como "Safe" o el tipo de riesgo que es.

Figura 7: Prompt Guard 2 ejemplos

Con estas protecciones, el ASR (Attack Success Rate) se reduce drásticamente y probándolo contra el entorno de evaluación de Agentes AI de AgentDojo que tenéis en el paper "AgentDojo: A Dynamic Environment to EvaluateAttacks and Defenses for LLM Agents" los resultados son mucho mejores.

Figura 8: Con el Benchmark de AgentDojo

Pero no solo ha habido actualizaciones de las versiones, sino que tenemos nuevas herramientas de seguridad, y nueva protecciones, como las que vamos a ver a continuación.

AlignmentCheck

Esta es una nueva característica de seguridad de Llama 4 que me ha gustado mucho, y que creo que va a ser un buen elemento mitigador para detectar los ataques cuando están teniendo éxito. Se trata de una revisión constante de lo que se está realizando en un instante concreto con el objetivo del Prompt original. 

Figura 9: AlignmentCheck es parte de las herramientas Guardarailes de Llama Firewall

Supongamos que le decimos a Llama 4 en un Prompt que resuma los documentos de una base de datos en una arquitectura RAG, y se pone a trabajar. En un instante de tiempo se encuentra en un documento un ataque de Prompt Injection que le pide que haga otra cosa, por ejemplo escribir los últimos Prompts que ha recibido, o lo que sea, en ese caso el flujo de ejecución del LLM habría sido secuestrado y estaría haciendo otra cosa que no tiene nada que ver con el Prompt Original que era resumir documentos.

Figura 10: Reducción de ataques con AligmentCheck

AlignmentCheck realiza durante toda la fase de ejecución del Prompt un control de alineamiento para ver si la acción que está ejecutando en ese momento está alineada con lo que se le pedía en el Prompt Original o no. Si no está alineada, detendrá el proceso y levantará un alerta. Básicamente es un "No sé qué ha pasado, pero algo ha pasado, pantalla azul". Esto es especialmente necesario en Llama 4, donde el Contexto se ha aumentado tanto, que es fácil encontrar muchos tokens de entrada que pueden atacar o confundir a un modelo de Llama.

CodeShield & AutoPatchBench

Continúa siendo una pieza fundamental para la seguridad del código que se escribe con Llama Code. Es una protección típica de los equipos de desarrollo de código, con verificación automática de búsqueda de vulnerabilidades con librerías de Análisis de Código Estático, que es lo que hace el equipo de Meta con su Insecure Code Detector (ICD), que se encarga de filtrar el código que genera la salida de Llama Code para verificar si se ha introducido un bug, y solicitar que se vuelva a generar.

Figura 11: CodeShield en GitHub

Esta verificación consiste en revisar la salida del código a lo largo de diferentes lenguajes de programación - un total de siete -, a saber: Rust, C, Python, PHP, Java, C++ y JavaScript, contra 50 tipos de debilidades (CWE: Common Weakness Enumeration) y aunque el resultado no es la panacea, ayuda a mejorar la calidad del código que genera. Pero la gran novedad ahora es el nuevo AutoPatchBench.

Figura 12: Flujo de generación de un Patch

Con AutoPatchBench, se trata de conseguir correcciones de Bugs por medio de Patches hechos por modelos LLMs de manera mucho más robusta. Así, el equipo de Llama Security ha estado trabajando en que, cuando se detecte un bug en un código, generado o detectado por un LLM, se pueda lanzar un proceso de generación de y validación de Patches robusto.

Figura 13: Comparativa de Seguridad de Patches

Esto permite tener mejores Patches, y un código mucho más robusto. Tenéis toda la información de esta nueva protección de seguridad en la web de AutoPatchBench.

Llama Firewall

Y todo esto nos lleva a la parte más importante de todas "Llama Firewall" que es la pieza de seguridad incluye a todas las demás y que protege la seguridad de los servicios y aplicaciones basados en MM-LLMs, y por supuesto en la familia Llama.

Figura 14: Llama Firewall en The Llama System

El paper, que lo podéis leer en el enlace que os dejo a continuación, explica cómo Prompt Guard, Llama Guard, Code Shield, AlignmentCheck y AutoPatchBench son parte de esta pieza de seguridad  que es Llama Firewall que trata de proteger en tiempo real todos los servicios que están basados en Llama.

Figura 15: Llama Firewall

Todas las explicaciones que he utilizado para este artículo vienen detalladas en el paper, y podéis acceder a más detalles que profundizan en lo que hace cada uno de los módulos. 

Figura 16: Módulos de Llama Firewall

Tengo un vídeo con una demo de Llama Firewall, pero ya será para otro día, que este artículo ya ha quedado bastante largo, y merece la pena que lo analices con calma.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)