Un solo benchmark de seguridad no dice si tu agente es seguro

¿Qué es esto?

Es un metaestudio de 2026 que toma como objeto de análisis los propios benchmarks de seguridad de agentes, en lugar de proponer uno más. En “Taxonomy and Consistency Analysis of Safety Benchmarks for AI Agents” (arXiv:2605.16282, cs.CY), investigadores de McGill, Kean y la Universidad Zayed catalogan 40 benchmarks conductuales de seguridad de agentes publicados entre abril de 2023 y marzo de 2026, más cinco artefactos adyacentes (evaluadores y conjuntos de datos), y plantean una pregunta engañosamente simple: si dos equipos evalúan el mismo agente en dos benchmarks distintos de “seguridad de agentes”, ¿llegan a la misma conclusión?

La respuesta es no. El resultado central del artículo es que la elección del benchmark puede pasar a un modelo de parecer seguro a parecer inseguro, porque estos benchmarks miden cosas sutilmente distintas bajo la misma etiqueta. Para quien se apoya en una afirmación tipo “seguro en el benchmark X”, ahí está todo el asunto: una puntuación aislada casi no significa nada sin saber qué benchmark, qué estresó realmente y cómo puntuó.

Cómo funciona

Los autores construyen una taxonomía de seis ejes de cómo un benchmark evalúa realmente a un agente y codifican los 40 benchmarks según ella. Los seis ejes son: la fuente de presión adversaria (¿el peligro viene de un usuario malicioso, de un documento inyectado o de la propia planificación defectuosa del agente?), la fidelidad del entorno (sandbox textual vs. herramientas en contenedor vs. sistema real), el alcance de capacidades del agente (solo texto vs. ejecución real de herramientas y código), el método de puntuación, la granularidad de la evaluación de seguridad (resultado final vs. comportamiento paso a paso) y el acoplamiento seguridad-utilidad (¿mide rechazos aislados o el compromiso frente a completar la tarea?).

Codificar el corpus así expone lo concentrado que está el panorama. En fidelidad de entorno, 34 de 40 benchmarks corren en sandbox, cuatro están en contenedor y solo uno toca un entorno real, de modo que la “seguridad” reportada se mide en el escenario menos parecido a producción. El artículo también halla que el campo prueba masivamente amenazas impuestas desde fuera (peticiones dañinas, inyección de prompts) mientras subprueba los riesgos internos del agente, como un agente autónomo que persigue por sí mismo un plan peligroso, y sostiene que la robustez prácticamente no se evalúa.

Para probar que el desacuerdo es real y no un artefacto, los autores realizan una comprobación de consistencia cruzada sobre cuatro benchmarks muy usados (AgentHarm, AgentDojo, InjecAgent y ODCV-Bench), sobre los modelos con datos completos, con intervalos de confianza del 95 % y una prueba de concordancia W de Kendall. Resultado: W = 0,10 (p = 0,94) — estadísticamente, ninguna evidencia de que los cuatro benchmarks ordenen los modelos igual. Las correlaciones por pares también son inestables, sin que ningún par sobreviva a la corrección por comparaciones múltiples.

Por qué importa

Las afirmaciones de seguridad de agentes se están volviendo moneda de compra. “Aprueba AgentHarm”, “puntúa X en AgentDojo” y frases similares aparecen cada vez más en fichas de modelo, presentaciones comerciales y decisiones internas de go/no-go. Este trabajo muestra que esos números no son intercambiables y a menudo ni siquiera están correlacionados, así que tratar uno de ellos como el veredicto de seguridad es un error: un modelo puede liderar un ranking y quedar cerca del fondo de otro que estresa una amenaza distinta.

También importa por el sesgo de sandbox. Si el número tranquilizador salió de un entorno textual restringido, y estás a punto de desplegar el mismo modelo con acceso real a herramientas, alcance de red y ejecución de código, el benchmark midió un problema estrictamente más fácil que el tuyo. En el corpus, las evaluaciones de alta fidelidad reportan una seguridad sistemáticamente distinta —y a menudo peor— que las de sandbox. La brecha entre “seguro en el benchmark” y “seguro en tu despliegue” es justo donde ocurren los incidentes.

Defensas

El artículo es una contribución de medición; su valor práctico está en cómo consumes y ejecutas las evaluaciones de seguridad de agentes.

• Nunca confíes en una única puntuación de benchmark. Triangula varios benchmarks con modelos de amenaza explícitamente distintos (daño dirigido por el usuario, inyección indirecta y desalineación autónoma) y espera que los rankings discrepen: esa discrepancia es información, no ruido.
• Ajusta la fidelidad del entorno a tu despliegue. Un resultado en sandbox, solo texto, no se traslada a un agente con herramientas reales y ejecución de código. Reevalúa en condiciones parecidas a producción antes de creer una etiqueta de “seguro”.
• Prueba la robustez explícitamente. Como la robustez adaptativa y adversaria es el eje menos cubierto, añade tu propio red teaming adaptativo en vez de suponer que un benchmark estático la capturó.
• Evalúa el riesgo interno del agente, no solo los ataques inyectados. Incluye escenarios donde el fallo sea el propio plan del agente, no una carga externa: esa clase está sistemáticamente subprobada.
• Exige un reporte mínimo. Al leer o publicar un resultado de seguridad, exige que se declaren el modelo de amenaza, la fidelidad del entorno, el alcance de capacidades, el método de puntuación, la granularidad y el compromiso seguridad-utilidad. El artículo propone precisamente esos estándares mínimos de reporte, que permiten distinguir números comparables de incomparables.

Estado

Elemento	Referencia	Nota
Taxonomía y análisis de consistencia (este trabajo)	arXiv:2605.16282	40 benchmarks codificados en 6 ejes; W de Kendall = 0,10 (p = 0,94) en 4 benchmarks — sin concordancia de ranking
Encuesta de seguridad agéntica	arXiv:2510.06445	Taxonomía de tres pilares (aplicaciones/amenazas/defensas) sobre 160+ artículos; mapea el panorama más amplio
Patrones de diseño para asegurar agentes LLM	arXiv:2506.08837	Marco defensivo complementario: patrones de arquitectura para acotar agentes frente a la inyección de prompts