Laboratorio de red teaming en CI
Una suite de jailbreaks se ejecuta en CI en cada build: decide si el build pasa, falla o se retiene, y nombra el motivo.
Abrir la herramienta →La herramienta interactiva se abre en inglés.
Una suite de jailbreaks y ataques al estilo garak, PyRIT o promptfoo se ejecuta en CI en cada build e informa de una tasa de éxito de ataques (ASR) frente a un umbral. Tu trabajo es la decisión de publicación: ¿el build pasa (PASS), debe bloquear el merge (FAIL) o debe retenerse (HOLD) porque la propia ejecución no es fiable? Algunas ejecuciones esconden un jailbreak real por encima del umbral o una corrección que ha vuelto a romperse; otras parecen alarmantes pero son un resultado aislado inestable, un evaluador que puntuó mal, un arnés que ejecutó cero casos o un umbral relajado en silencio para fabricar un verde. Haz fallar las ejecuciones que importan (una nueva clase de jailbreak por encima del umbral, un caso semilla que ha vuelto a fallar aunque el agregado esté por debajo, un éxito crítico reproducible, un crescendo de varios turnos, un umbral relajado en el mismo cambio) sin hacer fallar de más un build verde de verdad, y retén las que no puedes creer. Lee la ejecución, no el color del pipeline. garak, PyRIT y promptfoo se nombran como las herramientas reales con las que se construyen estas suites; las ejecuciones son escenarios sintéticos ilustrativos y las cifras de ASR no son mediciones ni estadísticas publicadas. Solo defensivo, sin exploits funcionales. Con niveles de dificultad, bonificación por velocidad y una nota de S a D. Es un laboratorio Pro: con una cuenta gratuita tienes 3 usos de herramientas Pro en total y después necesitas Pro.
- Lee la ejecución de CI: ASR frente al umbral, casos semilla, variación entre ejecuciones, comportamiento del evaluador y número de casos ejecutados.
- Decide el veredicto: PASS, FAIL (bloquear el merge) o HOLD.
- Nombra el motivo: ASR por encima o dentro del umbral, regresión, ejecución inestable, evaluador poco fiable, sin señal real o umbral relajado.
- Revisa la explicación y tu nota de S a D.
Preguntas frecuentes
¿Qué enseña el laboratorio de red teaming en CI?
Entrena la decisión que hay detrás de un control de seguridad previo al despliegue: cuando una suite automatizada de jailbreaks y ataques se ejecuta en CI e informa de una tasa de éxito de ataques, ¿el build debe pasar, bloquearse o retenerse porque la ejecución no es fiable? Trabajas una cola de ejecuciones de CI y en cada una eliges el veredicto y el motivo: ASR por encima o dentro del umbral, una regresión, un caso nuevo que el modelo ya resiste, una ejecución inestable, un evaluador poco fiable, ninguna señal real o un umbral relajado. Es práctica de control de publicaciones e interpretación de evaluaciones; no ejecuta ninguna evaluación contra un modelo.
¿Las herramientas y las métricas son reales?
Sí. La tasa de éxito de ataques (ASR), los umbrales de control, las suites de regresión y la fiabilidad del evaluador son las piezas reales del red teaming de LLM y agentes, y garak (el escáner de vulnerabilidades de LLM de NVIDIA), PyRIT (el Python Risk Identification Toolkit de Microsoft) y promptfoo (un ejecutor de código abierto de evaluaciones y red teaming) son las herramientas reales con las que se construyen esas suites de CI, nombradas aquí como conceptos. Las ejecuciones concretas, las cifras de ASR y los umbrales son números de escenario sintéticos e ilustrativos, no mediciones, benchmarks ni estadísticas publicadas.
¿Genera jailbreaks o exploits?
No. Es un ejercicio de formación estrictamente defensivo. Los ataques se describen de forma genérica («una nueva familia de sondas de codificación o juego de rol», «un crescendo de varios turnos»), nunca como prompts funcionales, y ninguna carga útil de aquí puede ejecutarse contra un modelo. La habilidad que se entrena es interpretar la SALIDA de una suite de red teaming lo bastante bien como para controlar correctamente una publicación: leer el ASR, las regresiones y el comportamiento del evaluador, no producir ataques.
¿Por qué HOLD es un veredicto distinto de PASS y FAIL?
Porque los errores de control más caros vienen de fiarse de un número del que no deberías. Un éxito aislado e inestable, un arnés que ejecutó cero casos o un evaluador que puntúa mal los rechazos producen un ASR que no significa nada: aprobar o suspender con él es un error en ambos casos. HOLD significa «vuelve a ejecutar, añade semillas o quórum, o arregla el evaluador antes de decidir». Separarlo de PASS/FAIL es la clave: un pipeline en verde sin pruebas, o uno en rojo por un evaluador roto, no es un veredicto sobre el modelo. Es una simulación educativa, no asesoramiento de seguridad para un pipeline concreto.
¿Es gratis?
No, es un laboratorio Pro. Con una cuenta gratuita tienes 3 usos de prueba de herramientas Pro en total; después necesitas Pro.