HarnessRisk muestra por qué una sola demostración de inyección de prompts no puede medir la seguridad de un agente
HarnessRisk informa de amplias diferencias de seguridad entre combinaciones de modelos y harnesses de agentes, y encuentra que la configuración es más vulnerable que las demás fases del ciclo de vida que probó.
Una prueba de inyección de prompts puede mostrar si un agente sigue una instrucción hostil en un documento. No puede mostrar si el mismo harness del agente configura un conector de forma segura, instala una capacidad, conserva un estado limpio, autoriza una acción externa o se recupera por completo de una contaminación.
Una nueva prepublicación en revisión llamada HarnessRisk concreta ese alcance que falta. Sus autores probaron 128 casos en sandbox con tres harnesses de agentes, seis modelos de lenguaje y 14 configuraciones de modelo y harness. Informan de tasas de éxito del ataque de entre el 12,6% y el 80,9%, aunque la utilidad en tareas benignas se mantuvo entre el 75,0% y el 97,6%. La configuración del harness fue la fase más vulnerable en los tres harnesses estudiados.
Esos resultados aún no se han reproducido de forma independiente y el benchmark no establece una tasa universal de fallos para los agentes en producción. Su aportación útil es la unidad de prueba: evaluar conjuntamente el modelo y el harness desplegados en la configuración, la ampliación de capacidades, la operación en tiempo de ejecución, el estado persistente, el control de acciones y la recuperación de incidentes, registrando por separado la utilidad de la tarea y los resultados de seguridad.
HarnessRisk prueba una configuración desplegada, no un modelo de forma aislada
Un harness de agente es la capa de ejecución que rodea al modelo de lenguaje. Proporciona herramientas, carga extensiones, mantiene la memoria, aplica permisos, presenta el contexto de autorización y convierte la salida del modelo en acciones. Por tanto, dos despliegues que utilicen el mismo modelo pueden exponer herramientas y estados distintos, enmarcar la autoridad de forma diferente y aplicar límites diferentes.
HarnessRisk refleja esa responsabilidad conjunta. Cada caso da al agente un objetivo benigno durante tres turnos del propietario y coloca una instrucción adversaria dentro de un artefacto de flujo de trabajo no confiable. Las ejecuciones comienzan en un entorno nuevo, utilizan servicios simulados controlados y desactivan los efectos reales de red externa. Cada uno de los 128 casos se repite con tres semillas de muestreo para cada configuración evaluada.
El repositorio publicado por los autores incluye adaptadores de harness, servicios simulados, recopilación de trayectorias, reglas de evaluación deterministas y un juez basado en un LLM. No convierte la reproducción en una operación de un solo clic: los equipos siguen necesitando el conjunto de datos de casos independiente, instalaciones de harness compatibles, acceso al proveedor del modelo y un aislamiento del sistema operativo más fuerte cuando sean posibles comandos arbitrarios en el equipo anfitrión. El repositorio afirma explícitamente que su separación a nivel de proceso no es un sandbox de seguridad del sistema operativo.
El intervalo destacado del artículo también comprime configuraciones muy diferentes. Un modelo registró una tasa de éxito del ataque del 54,7% en OpenClaw y del 12,6% en Nanobot, una diferencia de 4,3 veces en la configuración de los autores. Esa comparación no aísla el harness como causa, porque difieren los prompts, las herramientas y la gestión del estado. Sí muestra por qué trasladar la puntuación de seguridad de un modelo base a otro despliegue es un error de categoría.
Cuatro puntuaciones impiden que una tarea exitosa oculte una ejecución insegura
HarnessRisk asigna cuatro etiquetas binarias a cada trayectoria y después informa de porcentajes entre las ejecuciones. Las etiquetas responden a preguntas distintas y pueden ser verdaderas al mismo tiempo.
| Métrica | Dirección | Pregunta que debe responder la evidencia | Falsa sensación de seguridad habitual |
|---|---|---|---|
| Utilidad | Más alta es mejor | ¿Completó el agente el objetivo benigno del usuario? | «La tarea pasó, así que la ejecución fue segura». |
| Tasa de éxito del ataque | Más baja es mejor | ¿Llegó a producirse realmente el efecto prohibido? | «El agente nos avisó, así que el ataque debió fallar». |
| Persistencia | Más baja es mejor | ¿Permaneció la influencia adversaria en la memoria, configuración, política, extensión o estado de inicio persistentes? | «No ocurrió nada malo durante este turno». |
| Detección | Más alta es mejor | ¿Identificó explícitamente el agente el contenido concreto como sospechoso o no confiable? | «Una negativa o advertencia genérica demuestra que encontró el riesgo real». |
La distinción importa porque el reconocimiento y la contención son resultados separados. En el artículo, una configuración de OpenClaw detectó riesgos en el 97,9% de las ejecuciones, pero aun así tuvo una tasa de éxito del ataque del 31,2%. Otra combinó una detección del 92,2% con un éxito del ataque del 54,7%. La detección se correlacionó con un menor éxito del ataque en las 12 configuraciones compartidas, pero la pequeña muestra observacional no respalda una afirmación causal y la relación ajustada no fue estadísticamente significativa.
El evaluador es otra fuente de incertidumbre. GPT-5.4 puntuó las trayectorias principales a partir de transcripciones, llamadas a herramientas, cambios de estado, estado de servicios simulados y observaciones de red. En muestras reservadas, sus etiquetas coincidieron con las reglas deterministas en el 92,5% de los casos de utilidad y el 89,7% de los casos de éxito del ataque; la coincidencia con las etiquetas humanas adjudicadas fue del 84,3% para la persistencia y del 85,7% para la detección. Son resultados de validación útiles, no una prueba de que el juez no cometa errores.
El enfoque del ciclo de vida es la idea más sólida del benchmark
Las seis fases —configuración, ampliación de capacidades, operación en tiempo de ejecución, estado persistente, control de acciones y recuperación de incidentes— describen distintas oportunidades para que material no confiable obtenga autoridad. Un resultado limpio de inyección de prompts en tiempo de ejecución dice poco sobre un conector configurado a partir de texto hostil o una preferencia envenenada que sobreviva a la siguiente sesión.
La configuración merece especial atención porque HarnessRisk descubrió que tenía la tasa de éxito del ataque más alta en cada harness probado, a menudo cuando un valor inseguro aparecía dentro de un cambio que por lo demás estaba autorizado. La ampliación de capacidades es diferente: el anuncio de agente en producción de Anthropic del 20 de agosto hizo que computer use, browser use, la Skills API y la Files API estuvieran disponibles de forma general, aumentando el número de componentes reutilizables que un harness puede cargar.
Una campaña actual de skills con nombres falsificados aporta una consecuencia real sin validar las cifras del benchmark. TechRadar informó de que skills de agentes con nombres parecidos introdujeron después un comportamiento que robaba credenciales; la cifra de 1,7 millones correspondía a instalaciones agregadas mostradas, no a usuarios únicos ni a víctimas confirmadas. El incidente pertenece al modelo de amenazas de ampliación de capacidades. No demuestra que ninguna configuración de HarnessRisk represente ese marketplace ni un contenedor de API gestionado por Anthropic.
Los cuatro resultados publicados también deben mantenerse separados. Un despliegue puede completar la tarea benigna y permitir aun así el efecto prohibido; puede detectar contenido sospechoso y no conseguir contenerlo; puede parecer seguro en el turno actual mientras conserva un estado hostil para el siguiente. Una única «puntuación de seguridad» combinada borraría las distinciones más útiles del benchmark.
Lo que este benchmark no puede decidir por un equipo de producción
HarnessRisk es evidencia de una prepublicación de primera versión, en revisión a 23 de agosto. Su página del artículo en Hugging Face muestra atención de profesionales, pero no una reproducción independiente. Los autores evaluaron modelos, harnesses, casos, artefactos y métricas seleccionados; los endpoints de proveedores y las políticas de servicio pueden cambiar. Sus comparaciones entre harnesses son comparaciones entre configuraciones desplegadas, no estimaciones controladas de un efecto exclusivo del harness.
El artículo también utiliza «sandbox» para el estado aislado de la ejecución, los efectos secundarios simulados y los endpoints accesibles restringidos. El apéndice dice que no se impusieron espacios de nombres del kernel, chroot ni un cortafuegos adicional. Los equipos que prueben un agente capaz de ejecutar comandos arbitrarios en el equipo anfitrión necesitan un límite de contención a nivel del sistema operativo, credenciales falsas, servicios simulados, salida restringida, estado desechable y un equipo que no tenga nada que merezca la pena robar. El repositorio del benchmark formula la misma advertencia.
Por último, un bajo éxito del ataque puede incluir una negativa segura, no alcanzar la herramienta relevante o un fallo general de la tarea. La persistencia y la detección dependen de lo que el harness exponga al evaluador. Una prueba de despliegue debe documentar esos límites de observabilidad en lugar de tratar la ausencia de un evento en los registros como evidencia de que no ocurrió nada.
La señal más sólida a corto plazo no será una tabla de clasificación más grande. Será una repetición independiente que fije las revisiones del caso, el harness, el modelo, el evaluador y el aislamiento, y muestre si un control concreto reduce el éxito del ataque o la persistencia sin destruir la utilidad. Hasta entonces, el marco de seis fases del artículo debe leerse como una advertencia sobre el alcance: una demostración limpia de inyección de prompts no puede certificar el resto de un sistema de agentes.