Red teaming de LLMs: estado del arte, frameworks y lecciones de campo

El red teaming de LLMs consiste en buscar vulnerabilidades en un sistema de IA mediante entradas adversariales simuladas, antes de que lo haga un atacante real.

Hoy un LLM casi nunca se despliega como el modelo crudo. Se despliega como un sistema completo: un modelo rodeado de recuperación de contexto (RAG), herramientas que puede invocar, memoria que persiste entre sesiones y capacidad de desencadenar acciones fuera de la ventana de chat. Por eso tenemos que delimitar bien el alcance y elegir vulnerabilidades y ataques que no apunten solo al LLM, sino al sistema en su conjunto: es ahí, en el sistema, donde hoy se concentra el riesgo.

Esa distinción ya está en los propios marcos de OWASP. El Top 10 for LLM Applications trata el modelo como algo que recibe una entrada y produce una salida. El Top 10 for Agentic Applications de 2026 recoge diez categorías de riesgo propias de los agentes que planifican, mantienen memoria, invocan herramientas y actúan con autoridad delegada: secuestro de objetivos, abuso de herramientas, envenenamiento de memoria y contexto o comunicación insegura entre agentes, entre otras. En otras palabras, cubre lo que pasa cuando el modelo deja de ser un generador de texto y se convierte en un actor con objetivos, credenciales y herramientas encadenadas a lo largo de varios pasos.

En paralelo, el AI Act, con obligaciones vigentes desde 2025, ha vuelto todo esto bastante menos opcional para las organizaciones que ponen sistemas de IA en el mercado o desarrollan los suyos para uso interno.

Este artículo recorre el estado del arte de la disciplina: qué marcos de referencia existen y para qué sirve cada uno, qué se ataca y en qué capa, qué frameworks open source hay disponibles hoy y cómo se comparan, y cómo se ejecuta una campaña e interpretan sus resultados.

¿Qué dice la industria?

Empecemos por los marcos de referencia más relevantes.

El Top 10 de OWASP para aplicaciones LLM, en su edición 2026, trae dos cambios que marcan bien hacia dónde va la tendencia del riesgo.

Excessive Agency (LLM03) sube tres puestos, el mayor salto de la lista, y no es casualidad. Con los agentes ya en producción, una invocación de herramienta mal controlada, sin los guardrails adecuados, puede desencadenar una cadena de acciones automáticas antes de que nadie llegue a tiempo de pararla.

Hidden Context Exposure (LLM08) sustituye a System Prompt Leakage y amplía el alcance. Ya no hablamos solo del prompt de sistema, sino de todo lo que tu aplicación mete en la ventana de contexto sin intención de exponerlo: instrucciones de desarrollo, políticas recuperadas de un almacén de configuración, salidas de servicios de perfil, los esquemas de todas las herramientas que expones. El contexto oculto no es un límite de seguridad. Todo lo que acabe ahí hay que asumirlo como potencialmente visible.

MITRE ATLAS es otra de las patas. Nos da las tácticas y técnicas adversariales específicas de sistemas de IA y, igual que ATT&CK en el mundo tradicional, nos permite estructurar qué queremos ejercitar en cada campaña y mapear cada hallazgo a una taxonomía común. Su gran novedad reciente es la tanda de técnicas centradas en agentes de finales de 2025: el mismo desplazamiento «del modelo que responde al agente que actúa» que vemos en OWASP, pero contado desde el lado del atacante, desde la amenaza y no desde el control.

Para la parte de control está NIST AI RMF. Con su perfil de IA generativa, es lo que nos permite encajar el red teaming de sistemas LLM dentro de los programas de gestión de riesgo que la organización ya tiene.

Un detalle que conviene aprovechar aquí para terminar de encajar todas las piezas es el apéndice que incluye el documento OWASP Top 10 for LLM Apps 2026 (Appendix A: Related Framework Mappings) que mapea cada entrada contra nueve marcos distintos, entre ellos la lista agéntica, ATLAS, ATT&CK, CWE y el propio NIST AI RMF. Eso nos deja meter los riesgos de LLM en el modelo de amenazas que ya manejamos, en vez de gestionarlos como un compartimento estanco.

Hasta aquí todo genial. Estos marcos nos dicen qué buscar y dónde poner el foco. Pero, ¿cómo evaluamos la seguridad de nuestras aplicaciones LLM?

¿Cómo se ataca una aplicación con LLM?

La forma más útil de organizar la superficie no es por herramienta, sino por capas y vectores. Y esa organización tiene una consecuencia práctica: nos ayuda a entender quién puede arreglar cada hallazgo y en qué plazo.

Capa 1: el modelo

Aquí viven los ataques directos al modelo. Prompt injection directa, con los jailbreaks clásicos (DAN, role-play), los ataques a nivel de token (Unicode, homoglyphs), el many-shot jailbreaking y la policy puppetry. Y los ataques multi-turn, donde el atacante no fuerza el fallo en un solo mensaje sino que escala poco a poco a lo largo de una conversación (Crescendo es el ejemplo canónico).

La mayoría de lo que sale en esta capa es contenido: el modelo dice algo tóxico, sesgado o que no debería. Es útil como línea base, pero rara vez es accionable para quien construye la aplicación: depende del modelo base y mejora cuando el proveedor lo actualiza, no cuando tú tocas tu código.

Capa 2: la aplicación

Aquí está casi todo el riesgo interesante hoy.

Prompt injection indirecta, donde la inyección no la mete el usuario: llega en un documento que el RAG recupera, en el resultado de una herramienta o en el correo o el ticket que un agente procesa sin sospechar. Exfiltración de contexto, que es la cara ofensiva del Hidden Context Exposure de OWASP. Y los fallos de control de acceso de toda la vida trasladados a las APIs del agente: BOLA, BFLA, invocación de herramientas fuera de su ámbito, exfiltración a través de MCP.

Un fallo de «el modelo generó contenido tóxico» y un fallo de «un atacante leyó el prompt de sistema a través de un documento del RAG» no son el mismo tipo de problema. El primero no lo arreglas tú en la mayoría de los casos: depende del modelo base y se corrige cuando el proveedor lo actualiza. El segundo sí es tuyo, y se corrige con validación de entrada, control de acceso, sandboxing de herramientas y filtrado de salida. Cuando llegue el triaje, esta distinción es la que separa lo accionable de lo informativo.

¿Qué cambia cuando el objetivo es un agente?

Cuando el sistema invoca herramientas, arrastra memoria y encadena acciones, la superficie se dispara y cambia lo que hay que instrumentar. Ya no basta con capturar el texto que devuelve el modelo: hay que capturar qué herramienta invocó, con qué argumentos y con qué resultado. Excessive Agency es justo el punto donde la lista LLM empuja hacia la agéntica (GoalTheft, RecursiveHijacking y el abuso de invocación de herramientas viven en esa capa), y el mapa que aplica ahí es la lista agéntica (ASI).

¿Con qué herramientas cuento?

Los LLM son estocásticos. El mismo ataque puede fallar en una ejecución y funcionar en la siguiente. Eso hace que el red teaming con pruebas manuales en este caso, aunque nos ayude con una buena base de reconocimiento inicial, no baste.

Necesitamos volumen para que el resultado aporte todo su valor, y ese volumen implica automatización. Para eso están los frameworks y herramientas.

El ecosistema open source está razonablemente maduro. Veamos cinco herramientas que cubren la mayoría de escenarios.

garak podríamos usarlo para el primer barrido. Es principalmente un escáner: apuntas a un modelo, lanzas un conjunto amplio de sondas y obtienes un mapa de por dónde flojea. El resultado es un informe de cobertura rápida.

PyRIT es el más flexible y el que mejor escala a los escenarios raros. Orquestadores multi-turn, soporte multimodal de verdad y una arquitectura pensada para que sustituyas piezas. También es el que más tiempo pide antes de la primera ejecución útil.

promptfoo es el más adoptado y el que mejor entra en un pipeline. Integración nativa en CI/CD, un catálogo amplio de plugins y una comunidad enorme: según sus propios datos, más de 350.000 desarrolladores lo han usado y unos 130.000 son activos mensuales.

Jailbreaker es la más reciente y la que cambia el ángulo. La publicó SpecterOps a mediados de 2026 y no es un framework para componer en Python, sino una plataforma con interfaz de operador. Levantas el stack con Docker, apuntas a un objetivo, eliges una técnica o toda la familia y ejecutas. La herramienta guarda la configuración, el prompt generado, la respuesta, la traza y la puntuación del juez en el mismo sitio, y deja lanzar matrices de experimento sobre un dataset de intenciones para comparar resultados entre modelos o entre versiones de un system prompt. Su registro de técnicas incluye inyección directa e indirecta, roleplay, ofuscación por codificación e idioma, extracción de system prompt e iterativas como PAIR, TAP, Crescendo, AutoDAN y GPTFuzz. Separa los roles de objetivo, atacante y juez, y el juez admite una rúbrica propia sobre una escala de 1 a 10. Para el triaje lo más útil es que ejecuta un baseline junto al ataque, con lo que distingues si el fallo lo introduce la técnica o si el modelo ya se comportaba así. Es un proyecto joven y sin releases etiquetadas, así que encaja mejor como apuesta a seguir que como pieza consolidada.

DeepTeam es el que resulta cómodo cuando quieres campañas estructuradas sin construir el andamiaje a mano. Tiene un catálogo grande de vulnerabilidades, ataques que se aplican como transformaciones y un flujo claro que va de la vulnerabilidad al ataque, de ahí al objetivo y de ahí a la evaluación. El precio es que la evaluación va atada a su propia capa de LLM como juez: mientras garak trae detectores más deterministas y PyRIT te deja enchufar clasificadores, una Content Safety API o tus propios scorers, DeepTeam evalúa siempre con deepeval, su motor de LLM-as-judge. Es justo lo que lo hace cómodo y rápido, pero conviene recordar este punto de cara al triaje.

Y como esa balanza entre flexibilidad y comodidad es justo lo que buscamos para montar una campaña estructurada, vale la pena mirarlo de cerca.

DeepTeam

DeepTeam se apoya en deepeval (de Confident AI) y traslada su modelo de evaluación al terreno del red teaming. La forma más rápida de entenderlo es quedarse con su flujo de trabajo que consta de cuatro piezas encadenadas.

Vulnerabilidad → Ataque → Callback (objetivo) → Evaluación → RiskAssessment

La vulnerabilidad es qué quieres probar: fuga del prompt de sistema (PromptLeakage), fuga de PII (PIILeakage), toxicidad, sesgo y, en el catálogo más reciente, vulnerabilidades agénticas como ExcessiveAgency o GoalTheft. La web habla de más de 120 vulnerabilidades repartidas en varias categorías; como siempre, la cobertura nominal no es cobertura efectiva, así que conviene comprobar contra la documentación qué está realmente implementado antes de prometérselo a nadie, sobre todo en la parte agéntica, que es la más nueva.

El ataque es cómo lo pruebas. En DeepTeam los ataques son transformaciones que se aplican sobre el intento base que genera el simulador. En single-turn tienes PromptInjection, Multilingual, ROT13, Leetspeak o Base64, entre otros; en multi-turn, los interesantes: Crescendo, LinearJailbreaking, TreeJailbreaking, Sequential o BadLikertJudge. La distinción single/multi no la marca el objetivo, la marca el ataque que configuras.

• El simulador genera el ataque y se fija por vulnerabilidad, no de forma global. Esto es un punto importante ya que cada una trae su simulator_model por defecto en gpt-3.5-turbo-0125 y su evaluation_model en gpt-4o. Si no los pasamos de forma explícita, nos quedamos con esos valores y por ello, con un simulador bastante modesto por mucho que hayamos configurado otro modelo en otra capa. Si tienes que elegir dónde poner el modelo más potente, ponlo en el simulador: un simulador flojo genera ataques que puede que nunca disparen la vulnerabilidad y eso es difícil de detectar, mientras que los errores del evaluador los cazas en el triaje y puedes ir ajustando.

El callback envuelve tu sistema. Es una función que recibe el ataque, se lo pasa a tu objetivo (un modelo local con Ollama, una API, tu aplicación completa) y devuelve la respuesta. En single-turn su firma es mínima: recibe el input y devuelve un str. En multi-turn cambia: recibe también la lista de turnos previos y tu callback tiene que reinyectarlos en el objetivo, para que responda viendo toda la conversación y no cada turno aislado.

La evaluación la hace deepeval como LLM-as-judge, con un veredicto binario de pass/fail por intento. Todo lo que dijimos arriba sobre la varianza del juez vive aquí.

Sobre esto orquesta el RedTeamer, el componente donde controlamos cómo se ejecuta la campaña:

• attacks_per_vulnerability_type: cuántos intentos por vulnerabilidad. Es tu palanca de fiabilidad estadística. Con uno o dos, el resultado es anecdótico.
• max_concurrent: cuánta concurrencia. En multi-turn, más de la cuenta contamina el estado entre conversaciones.
• El propósito: el contexto que le das al simulador sobre qué constituye un ataque exitoso contra tu sistema en concreto.

Cuando el catálogo no llega, están las vulnerabilidades custom. Modelas una técnica que no está cubierta, Policy Puppetry por ejemplo, definiendo un criterio de evaluación (qué cuenta como éxito) y unos subtipos, más un prompt que guía al simulador. La estructura es sencilla pero la calidad del resultado depende casi por completo de lo específico que seas en ese criterio.

Una ventaja es que DeepTeam también se puede manejar por CLI con configuración en YAML, lo que hace que una campaña sea repetible y encaje en CI/CD. Ese equilibrio entre campañas estructuradas y repetibles, a cambio de una capa de evaluación que no eliges, es lo que lo convierte en un buen punto de entrada.

¿Cómo se ejecuta una campaña?

El flujo, con cualquiera de estas herramientas, es siempre el mismo y es iterativo.

Lo primero es acotar el alcance y conectar el callback a tu sistema. Trabaja contra una réplica de preproducción, con las mismas integraciones.

Primero lanza una campaña mínima a modo de smoke test que confirme que las tuberías están bien. Que los ataques llegan al objetivo, que las respuestas vuelven y se parsean, y que el modelo que está generando los ataques es el que crees. Es el momento más barato para cazar un callback que no pasa bien el contexto o un simulador que se quedó en el default, antes de que esos fallos contaminen una campaña larga.

Con eso en verde, la primera pasada real es una campaña single-turn de cobertura amplia: muchas vulnerabilidades, varios intentos por tipo. No busca profundidad, busca mapa. Nos indica qué categorías reaccionan y cuáles ni se inmutan, y de paso deja ver los falsos positivos evidentes del evaluador antes de invertir en pruebas más caras.

A partir de ahí se estrecha y se profundiza. Las campañas multi-turn son donde aparecen los hallazgos interesantes, así que conviene separarlas por intención en lugar de meterlo todo en una: una para las técnicas de escalada, otra para ampliar cobertura sobre las vulnerabilidades que sí reaccionaron. Y cuando una técnica no está en el catálogo, se modela en detalle como vulnerabilidad custom y entra en la misma tubería sin tratamiento aparte.

Cada ejecución se guarda para analizar y comparar. Después del triaje, cuando arreglas algo, reejecutas a modo de test de regresión para confirmar que está cerrado. Aquí conviene usar un detalle de DeepTeam: pasarle reuse_simulated_test_cases=True al RedTeamer para que reutilice los ataques ya generados en vez de simular otros nuevos. Así el retest lanza exactamente las mismas entradas contra el sistema parcheado, que es lo que hace válida la comparación; si dejas que regenere, el simulador es estocástico y estarías midiendo contra ataques distintos.

Finalmente, porque el evaluador es un LLM y su veredicto es probabilístico, no un scan determinista tipo SAST, hacemos el triaje de resultados en tres partes.

Descarta los falsos positivos del evaluador. El juez marca como fuga de PII una respuesta donde el modelo se inventó un nombre genérico, o da por exitoso un ataque porque la respuesta menciona el tema prohibido aunque sea para negarse. Revisa a mano los primeros hallazgos antes de creerte ningún porcentaje.

Separa lo accionable de lo informativo. Aparta lo que solo se arregla con una actualización del modelo base y quédate con lo que depende de tu aplicación, que es lo que de verdad puedes corregir.

Mira la tasa de éxito por repetición. Un ataque que funciona una de cada veinte veces sigue siendo una vulnerabilidad. En un sistema con diez mil conversaciones diarias, «una de cada veinte» son quinientos incidentes al día.

Para terminar, lecciones de campo

Elige con cuidado el modelo que genera los ataques. Algunos frameworks traen un modelo por defecto para la simulación y lo usan aunque hayas configurado otro globalmente. Comprueba en la primera ejecución qué modelo está escribiendo realmente los ataques; si es uno flojo, tus resultados también lo serán.

La calidad de un ataque custom es la calidad de su criterio de éxito. Los frameworks te dejan modelar técnicas fuera del catálogo, pero el simulador solo genera ataques efectivos si le dices con precisión qué cuenta como éxito contra tu sistema. Y ese contexto pesa más cuanto más cerca lo pones de la vulnerabilidad concreta que cuando lo dejas como descripción global de la campaña. Si los ataques salen genéricos, casi siempre es ahí donde falta detalle, no en la herramienta.

La fiabilidad depende de las repeticiones. Con una o dos por tipo de vulnerabilidad, el resultado es una anécdota. Sube el volumen hasta que los números empiecen a dar resultados significativos.

En multi-turn, controla la concurrencia. Las conversaciones simultáneas contra el mismo objetivo pueden contaminar el estado y darte resultados que no se reproducen. Paralelizar ahí ahorra menos tiempo del que cuesta depurar después.

La automatización da cobertura, pero el criterio sigue siendo tuyo. Las herramientas cubren superficie con volumen, que es lo que una persona no puede hacer a mano. El veredicto final, en cambio, no se automatiza: distinguir un hallazgo real, valorar su riesgo y fijar su prioridad sigue siendo cosa tuya.

Happy hacking!

Para profundizar

• OWASP Top 10 for LLM Applications 2026
• OWASP Top 10 for Agentic Applications (ASI) 2026
• MITRE ATLAS
• NIST AI Risk Management Framework
• Reglamento (UE) 2024/1689, AI Act
• DeepTeam · PyRIT · garak · promptfoo · Jailbreaker