Vera: pruebas de seguridad a escala hallan un 93,9 % de fallo en agentes

¿Qué es esto?

Vera es un framework automatizado de pruebas de seguridad para agentes LLM con herramientas, descrito en un artículo publicado en arXiv el 2 de julio de 2026 (arXiv:2607.01793). Su motivación surge de una limitación práctica en cómo se mide hoy la seguridad de los agentes: la mayoría de las suites de prueba existentes apuntan a un conjunto fijo de violaciones definidas por expertos y las evalúan con reglas codificadas de forma rígida, lo que las hace costosas de ampliar cada vez que un agente adquiere nuevas herramientas o un atacante encuentra un nuevo truco. Vera replantea el problema como una prueba de software sobre un sistema no determinista: una tubería auto-reforzada que descubre riesgos en la literatura, los compila en casos de prueba ejecutables y verifica los resultados a partir de lo que realmente ocurrió en el entorno, en lugar de lo que el modelo afirma haber hecho.

El resultado principal invita a la reflexión. En cuatro frameworks de agentes en producción —el artículo menciona OpenClaw, Hermes, Codex y Claude Code— la tasa media de éxito de los ataques alcanzó el 93,9 % en la condición de prueba más exigente. Los autores también publican Vera-Bench, un conjunto público de 1.600 casos de seguridad ejecutables que abarcan 124 categorías de riesgo en tres configuraciones de ejecución.

Cómo funciona

Vera se ejecuta en tres etapas conectadas. Primero, una etapa de exploración continua de riesgos lee la literatura de investigación y organiza los problemas emergentes en tres taxonomías en crecimiento: riesgos de seguridad, métodos de ataque y entornos de ejecución de herramientas. Después, una etapa de construcción de casos de prueba ejecutables compone elementos de esas taxonomías en casos concretos. Cada caso es una tripleta: un objetivo de seguridad específico, un estado inicial del entorno construido por programa y un predicado de verificación determinista; así, un «caso» es un escenario ejecutable con una condición de éxito comprobable por máquina, no una descripción en prosa. Por último, una etapa de ejecución adaptativa ejecuta el agente objetivo dentro de un entorno aislado y con estado.

El detalle de diseño más importante para los defensores es el modelo de amenaza, que separa dos canales de influencia del atacante. Cada escenario base se expande en tres variantes: una variante benigna sin adversario, una variante de canal único donde el adversario solo controla los mensajes del usuario, y una variante multicanal donde el adversario además manipula las respuestas de las herramientas. Esa manipulación se realiza mediante una «pasarela de herramientas» configurable —implementada como un servicio mediador sobre el Model Context Protocol— situada entre el agente y cada punto final de herramienta, capaz de reescribir el valor devuelto por una herramienta en uno de cuatro modos: identidad (sin cambios), append o prefix (contenido del atacante junto al resultado real) u override (resultado totalmente sustituido).

# Canales del modelo de amenaza (ilustrativo; sin payload operativo)
benigno         -> sin entrada adversaria
canal unico     -> el atacante controla solo los mensajes de USUARIO
multicanal      -> el atacante TAMBIEN reescribe las RESPUESTAS DE HERRAMIENTA
                   modos: identity | append | prefix | override

Dos piezas adicionales hacen que los resultados sean fiables y no anecdóticos. Un agente de control conduce cada prueba como una conversación de múltiples turnos: primero establece una tarea legítima plausible y luego se adapta turno a turno —reformulando tras un rechazo, cambiando de enfoque cuando el agente elige una herramienta inesperada o desplazando la inyección cuando el contenido manipulado no fue recuperado—. Y un verificador anclado en evidencias decide si el objetivo de seguridad se alcanzó realmente inspeccionando las llamadas de herramienta registradas y el estado final del entorno, y explícitamente no el autoinforme del agente. Como los frameworks desplegados exponen las llamadas y respuestas de herramientas pero rara vez el razonamiento interno, Vera juzga la seguridad por las acciones ejecutadas y sus efectos observables.

Por qué importa

La brecha entre las tres configuraciones es el verdadero hallazgo. Agentes que parecen aceptables cuando solo el prompt del usuario es adversario se vuelven muy explotables en cuanto el canal de las respuestas de herramientas también está comprometido: la condición multicanal es la que produce la media del 93,9 %. Es un argumento directo y medido a favor de un principio que los defensores ya intuían: en un agente, las salidas de las herramientas son entradas no fiables, y cualquier prueba que solo altere el prompt del usuario subestimará gravemente la exposición real.

El método de verificación aporta una segunda lección. Juzgar la seguridad de un agente preguntándole si hizo algo dañino no es fiable; anclar el veredicto en el estado del entorno y en la evidencia de las llamadas de herramienta cambia qué fallos se pueden siquiera ver. Para los equipos que montan sus propias evaluaciones de agentes, esa distinción —artefactos observables frente a autoinforme— es probablemente tan importante como cualquier cifra de ataque aislada. El trabajo se presenta como infraestructura de evaluación defensiva, publica un benchmark en lugar de un exploit llave en mano, y aparece bajo licencia abierta con código público.

Defensas

• Trate cada respuesta de herramienta como entrada no fiable. El resultado multicanal muestra que el canal de respuestas de herramientas es donde más fallan los agentes. Valide, sanee y, cuando sea posible, firme o rastree el origen de las salidas de herramientas antes de que vuelvan al contexto del modelo; nunca suponga que un resultado de herramienta es auténtico solo porque la herramienta se invocó legítimamente.
• Pruebe el canal de herramientas, no solo el prompt. Añada una condición de respuesta de herramienta comprometida a su red teaming de agentes. Una suite que solo varíe el mensaje del usuario reproduce la configuración de canal único y pasará por alto la exposición que aquí produjo la tasa de fallo casi total.
• Verifique resultados a partir de artefactos observables, no del autoinforme. Decida si una ejecución fue segura inspeccionando el estado final del entorno y la trayectoria registrada de llamadas de herramienta, no pidiendo al agente que se califique a sí mismo. Registre el historial completo de llamadas de herramienta para hacer posibles la verificación posterior y la supervisión.
• Aísle cada ejecución de prueba en un entorno de pruebas. Vera da a cada ejecución su propia instancia de agente, pasarela y servicios externos. Reproduzca eso en sus propias pruebas para que los casos no se contaminen entre sí y para que una prueba que desencadene una acción destructiva no toque nada real.
• Mantenga el catálogo de riesgos actualizado y combinatorio. Una lista de verificación estática envejece rápido. Actualice periódicamente el conjunto de riesgos, métodos de ataque y entornos que prueba, y combínelos, para que la cobertura siga la creciente superficie de herramientas del agente en lugar de quedarse atrás.
• Aplique el mínimo privilegio en la pasarela de herramientas. Si una capa mediadora puede reescribir el tráfico de herramientas para las pruebas, también puede hacerlo en producción. Restrinja qué herramientas puede alcanzar una sesión de agente y coloque las acciones irreversibles o de alto impacto tras una confirmación.

Estado

Elemento	Valor
Artefacto	Vera — framework de pruebas de seguridad de agentes; benchmark Vera-Bench
Divulgación	Preprint de arXiv, 2 de julio de 2026 (CC BY 4.0)
Alcance	1.600 casos de seguridad ejecutables; 124 categorías de riesgo; tres configuraciones
Frameworks probados	OpenClaw, Hermes, Codex, Claude Code
Impacto medido	Tasa media de éxito de ataques del 93,9 % en multicanal (respuestas de herramientas)
Naturaleza	Investigación de evaluación defensiva; código público, sin exploit operativo publicado

Fecha clave: 2 de julio de 2026 — Vera y Vera-Bench publicados por primera vez en arXiv. Es un framework de pruebas y un benchmark, no un incidente observado en el mundo real contra un despliegue concreto.

Este artículo resume investigación de seguridad disponible públicamente, con fines defensivos.