Los detectores de inyección de prompts necesitan políticas de decisión, no solo mejores puntuaciones

¿Qué es esto?

Los detectores de inyección de prompts suelen evaluarse como clasificadores binarios. Sin embargo, una aplicación en producción debe tomar una decisión más concreta: permitir la entrada, bloquearla o escalarla a una persona o a un modelo más potente. Un preprint enviado a arXiv el 14 de octubre de 2026 (arXiv:2610.20907, «From Detection to Decision: Calibration and Deferral for Prompt-Injection Detection», de Qianlong Lan, Anuj Kaul, Vinothini Pandurangan e Indranil Sanyal) estudia directamente esa capa de decisión.

La conclusión para los defensores: un detector que produce probabilidades no es automáticamente un detector en el que se pueda confiar para filtrar el tráfico, sobre todo cuando ese tráfico difiere de los datos de entrenamiento.

Cómo funciona

Los autores evalúan cuatro sistemas con 47 611 ejemplos reservados de TensorTrust, BIPIA, NotInject y PIDS-Bench v3: un modelo de decisión probabilístico alojado (Jev), dos clasificadores Llama Prompt Guard 2 (22M y 86M de parámetros) y un LLM juez. Meta describe Prompt Guard 2 como un clasificador tipo BERT que solo devuelve las etiquetas «benign» o «malicious» y tiene una ventana de contexto de 512 tokens.

Se miden tres aspectos. Discriminación (AUROC): el LLM juez obtiene 0,897, Jev 0,871, Prompt Guard 2 86M 0,757 y el modelo de 22M 0,714. Calibración: las probabilidades nativas de Jev no fueron sistemáticamente mejores que las de Prompt Guard 2 tras el escalado por temperatura, que mejora las métricas de calibración sin cambiar la discriminación. Comportamiento de las políticas: construyen políticas permitir / bloquear / diferir en las que las entradas inciertas pasan a un revisor LLM congelado.

El resultado principal se refiere al coste. Para reducir la tasa de falsos negativos del sistema al 1 % o menos, toda combinación de filtro y revisor tuvo que escalar más del 91,8 % de las entradas, dejando solo un 7 a 8 % de gestión automática, con tasas de falsos positivos del sistema de alrededor del 40 al 46 % y una latencia media cercana a 3,7 a 3,9 segundos. Los autores afirman que las salidas probabilísticas por sí solas no establecen decisiones de seguridad fiables ante un cambio de distribución.

Limitaciones que el propio artículo enumera: el conjunto agregado tiene cerca de un 88 % de ataques y está dominado por BIPIA, Jev se probó como modelo alojado con un único prompt, las estimaciones son puntuales sin intervalos de confianza, y el estudio mide detección y enrutamiento, no el compromiso de extremo a extremo de un agente.

Por qué importa

Muchos equipos colocan un clasificador pequeño delante de un agente y tratan su puntuación como un control de seguridad. Este estudio muestra que la puntuación es solo la primera entrada de una política. Si la confianza del clasificador está mal calibrada en su tráfico, los umbrales elegidos con un benchmark público pueden bloquear a usuarios legítimos o dejar pasar ataques, y un revisor ajustado para fallar muy poco puede marcar casi todo. El coste operativo, y no solo la precisión, determina si el control es utilizable.

Defenses

• Mida la calibración y las tasas de error con su propio tráfico, no solo con benchmarks públicos, y repita la medición tras cambios de modelo o de prompt.
• Informe de los falsos positivos junto a los falsos negativos: un filtro que deja pasar pocos ataques pero bloquea en exceso será esquivado por los usuarios o desactivado por los operadores.
• Use una política de tres salidas (permitir, bloquear, diferir) y dimensione explícitamente el presupuesto de revisión, incluida la latencia, antes de fijar los umbrales.
• Pruebe por separado el punto de operación del revisor: uno calibrado para cero omisiones puede convertir todo el sistema en un filtro que bloquea todo.
• Examine los resultados por conjunto de datos o segmento de tráfico, porque las métricas agregadas pueden ocultar efectos de composición.
• Trate el detector como una capa más: combínelo con mínimo privilegio en las herramientas, confirmación de acciones sensibles y filtrado de salidas, para que una inyección no detectada no se convierta en una inyección exitosa.
• Con Prompt Guard 2, siga la guía de Meta: divida las entradas de más de 512 tokens en segmentos y considere un ajuste fino con datos propios de la aplicación.

Status

Elemento	Detalle
Tipo de fuente	Preprint de arXiv (cs.CR), aún sin revisión por pares
Envío	14 de octubre de 2026
Sistemas evaluados	Jev, Llama Prompt Guard 2 (22M, 86M), LLM juez
Vulnerabilidad / CVE	Ninguna; es un estudio de evaluación
Remediación	Operativa: calibrar, definir política de aplazamiento, apilar controles