Sentinel, un arnés de pruebas adversariales para aplicaciones LLM
El proyecto dispara ataques de prompt injection, jailbreak o fuga del system prompt contra un chatbot y puntúa cada respuesta con un juez LLM. Es un CLI que busca hueco en el pipeline.
Sentinel es un arnés de pruebas adversariales para aplicaciones construidas sobre LLM. Lanza ataques automáticos contra un chatbot —inyección de prompt, jailbreak, fuga del system prompt, alucinaciones, acciones no autorizadas—, evalúa las respuestas con un juez LLM y devuelve un informe puntuado por categoría del OWASP Top 10 para aplicaciones LLM. Se ejecuta como herramienta de línea de comandos y el código está en GitHub.
El punto de partida que plantea su autor es razonable: los equipos escriben pruebas para verificar que su software hace lo que debe, pero casi nadie comprueba que se niegue a hacer lo que no debe. Las vulnerabilidades que recoge la taxonomía de OWASP —LLM01 inyección, LLM06 agencia excesiva, LLM07 fuga del system prompt, LLM09 alucinación— no son casos de laboratorio; aparecen en cuanto alguien dedica una tarde a conversar con el bot.
Qué prueba y cómo lo puntúa
La herramienta mantiene una biblioteca de prompts semilla, los muta antes de dispararlos y admite tres tipos de objetivo: un bot de demostración deliberadamente vulnerable, un bot empresarial endurecido y cualquier endpoint HTTP propio. De cada ronda guarda latencia y marca de tiempo. Las respuestas pasan por un juez LLM que devuelve una puntuación de confianza entre 0 y 1, la categoría afectada y una frase de razonamiento. La salida es JSON, un informe en markdown y un panel web con barras por categoría, disponible además como demo desplegada.
Desde terminal, todo se reduce a npx sentinel run --target vulnerable.
En los ejemplos que enseña, el bot vulnerable cae tres veces. Suelta su token de administración cuando le dicen que ha entrado en modo diagnóstico. Inventa un método stripe.payments.reverseQuantumTransaction() que no existe y lo acompaña de código plausible. Y confirma haber borrado un usuario de la base de datos sin que nadie compruebe permisos. Son fallos reconocibles, aunque el objetivo esté fabricado para fallarlos.
De dónde salen los números
La ejecución que muestra el proyecto completa 38 ataques en 18 milisegundos, con una tasa de éxito del objetivo del 63% (24 neutralizados, 14 superados) y un índice de vulnerabilidad de 37 sobre 100. Esa cifra de tiempo solo cuadra si el objetivo es local y simulado, no un modelo real respondiendo por red. Los números son de su autor contra un bot escrito para ser vulnerable, no de una auditoría independiente.
Tampoco hay comparativa contra Garak (NVIDIA), PyRIT (Microsoft) o Promptfoo, las referencias del red-teaming de LLM. El autor las describe como herramientas profundas pero pesadas y pensadas para equipos de seguridad dedicados, y sitúa Sentinel en el hueco de quien no tiene ese equipo. Falta lo que suele faltar en un proyecto de este tamaño: no se detalla la licencia, ni cómo se configura el juez, ni qué cuesta cada ronda cuando el objetivo es un modelo de verdad.
Aun así, la idea tiene recorrido. Meter una pasada adversarial antes de desplegar es algo que OWASP y varios proveedores llevan tiempo recomendando y que casi nadie tiene montado. Un CLI que se invoque desde GitHub Actions y rompa el build ante una regresión de seguridad aporta más que otro panel de observabilidad.
