Los agentes autónomos de seguridad están mejorando en la detección de vulnerabilidades, pero nadie tiene una forma adecuada de medir su eficacia. Cuando se apunta un agente a un objetivo realista, lo que devuelve es un informe escrito por el propio agente: prosa segura, una lista de hallazgos y ninguna manera de saber cuáles de ellos ocurrieron realmente. Entonces, alguien con experiencia en seguridad debe sentarse a verificar cada afirmación contra el objetivo. ¿Qué hallazgos son reales, cuáles son duplicados, cuáles son inventos y, la pregunta que nadie tiene tiempo de responder, qué nunca intentó el agente? Eso representa un día de trabajo experto por cada ejecución. Multiplíquelo por tres modelos, cuatro variantes de prompts y diez repeticiones, y la cola de revisión es más larga que el experimento.
XRanges for AI, creado por CTF.ae, existe para ese bucle. Implementa aplicaciones objetivo realistas con instrumentación integrada en cada servicio, registra lo que el agente realmente hace dentro de ellas y califica cada ejecución en vivo según cuatro señales independientes. Este recorrido cubre cómo funciona, cómo se ve una ejecución desde el despliegue hasta la comparación y dónde ha sido sometido a pruebas de estrés.
El problema del bucle de retroalimentación
Los equipos que desarrollan agentes autónomos de pentesting o bug bounty tienden a compartir un flujo de trabajo. Construyen un objetivo que parece una empresa real, ejecutan el agente y leen el resultado. El problema está en el resultado.
Un agente que dice haber explotado una falla de control de acceso puede haberla explotado, puede haber pasado por alto una pista de ella o puede haberla inventado. El informe se lee idénticamente en los tres casos. Además, un informe solo enumera lo que el agente encontró. No dice nada sobre las cuarenta características que el agente nunca abrió, la API que nunca enumeró y el segundo error que acecha en el mismo endpoint donde encontró el primero. Luego está el agente que elimina una tabla o revoca todas las claves de API en su camino hacia un hallazgo. Ningún cliente aceptaría ese resultado, y nada en una lista de hallazgos lo registra.
La revisión manual puede con una ejecución. No puede con la matriz de experimentos que realmente necesita un equipo de ingeniería de IA, que implica muchos modelos, muchas configuraciones, muchas repeticiones, comparadas honestamente.
Qué es XRanges for AI
XRanges for AI es un espacio de trabajo único para toda la evaluación. Tiene dos mitades.
La primera es una biblioteca de objetivos de referencia. Cada uno es una aplicación completa, no un conjunto de desafíos tipo rompecabezas: una empresa multiservicio con su propia lógica de negocio, datos sembrados, trabajos en segundo plano y tráfico de usuarios simulado, construida en varios lenguajes y frameworks porque así es como se construye el software real. Cada objetivo contiene 20 o más vulnerabilidades inyectadas, desde fallas de un solo paso hasta cadenas que cruzan fronteras de servicios, incluidos zero-days encontrados por los propios investigadores de CTF.ae. Nada de esto existe en corpus públicos de entrenamiento, lo cual importa cada mes más.
La segunda mitad es la capa de instrumentación. Cada servicio en cada objetivo emite telemetría estructurada a través de OpenTelemetry. La instrumentación está escrita a mano, por ingenieros de seguridad de aplicaciones y de software, para ese objetivo específico. El registro HTTP genérico pasaría por alto la mayor parte de lo que importa. La plataforma, en ai.xranges.com, ingiere la telemetría por despliegue y la convierte en cuatro puntuaciones que se actualizan mientras el agente aún trabaja.
Las cuatro señales
Cada despliegue se califica según cuatro mediciones elegidas para ser independientes entre sí. Un agente no puede mejorar una manipulando otra, y esa independencia es el punto clave.
- – Cobertura: responde si el agente exploró el objetivo. Cada característica de cara al usuario es un punto de cobertura, expresado como una acción de negocio en lugar de una URL: registró una cuenta, navegó por ofertas de empleo, abrió una conversación compartida, ejecutó código en una evaluación. Un punto de cobertura solo es alcanzable mediante uso normal, nunca a través de un exploit, por lo que la puntuación es una medida limpia de cuán a fondo trabajó el agente la superficie legítima. Los puntos no alcanzados son los puntos ciegos del agente, listados por nombre. La mayoría de los equipos encuentra esa lista más útil que la puntuación.
- – Límites: responde si el agente respetó las reglas de participación. Cada objetivo viene con reglas de guardia como "no debe eliminar contenido de contratación" o "no debe revocar claves de API". Una violación se registra en el momento en que ocurre, con el contenedor y la marca de tiempo. Cero violaciones es la expectativa. Cualquier otra cosa es un hallazgo sobre el agente, no sobre el objetivo, y generalmente uno más urgente.
- – Explotado: responde qué vulnerabilidades explotó realmente el agente. Cada vulnerabilidad se define como una cadena de muerte de fases ordenadas, desde el primer contacto con la superficie vulnerable hasta una señal de explotación que solo se activa en caso de éxito. Debido a que cada fase se detecta desde dentro del objetivo, la plataforma sabe qué paso completó el agente y dónde se estancó, independientemente de lo que el agente escribió en su informe. Una cadena de control de acceso de tres pasos que se detuvo en el paso dos se muestra exactamente así: dos de tres, con marcas de tiempo.
- – Integridad: responde si el objetivo sobrevivió. Las verificaciones de integridad se ejecutan cada minuto y confirman que la aplicación sigue siendo funcionalmente correcta: datos sembrados presentes, servicios que responden con el contenido correcto, confianza entre servicios intacta. Una verificación fallida es una penalización independientemente de la causa. Detecta al agente que encontró un error al romper el entorno que lo rodea.
Las cuatro se resumen en una puntuación, y la puntuación es el número menos interesante de la página. El desglose es donde está el trabajo.
Una ejecución, de principio a fin
Un objetivo se despliega como un entorno aislado de múltiples contenedores en aproximadamente noventa segundos. La plataforma ejecuta hasta mil despliegues a la vez, por lo que los ingenieros de IA, los ingenieros de software y el equipo de infraestructura pueden ejecutar sus propios experimentos sin hacer cola detrás de los demás.
Luego, el agente se ejecuta contra el endpoint de despliegue por sí solo. La plataforma nunca se interpone entre el agente y el objetivo. Observa desde dentro.
Mientras el agente trabaja, la línea de tiempo registra lo que realmente hizo, mapeado a la funcionalidad del negocio: previsualizó una oferta de empleo, envió una solicitud empresarial, generó una clave de API. Los ingenieros que quieren el material sin procesar pueden leer el flujo de OpenTelemetry directamente y consultarlo con un lenguaje de consulta de registros que maneja expresiones regulares y filtros de atributos. Cuando el agente informa algo que no está en el catálogo de vulnerabilidades del objetivo, la línea de tiempo lo resuelve. A veces es un falso positivo. A veces el agente encontró un error real que nadie plantó, lo cual ha sucedido más de una vez.
La reevaluación no significa un segundo laboratorio. Las vulnerabilidades se pueden activar o desactivar, o parchear en su lugar, en un despliegue en ejecución. Algunos parches se aplican en tiempo de ejecución. Otros requieren un reinicio de un minuto o dos. En cualquier caso, el agente vuelve a probar contra el mismo entorno con el mismo estado.
Cada despliegue también lleva metadatos personalizados: nombre del modelo, versión del agente, variante de prompt, el ingeniero que lo ejecutó. Los despliegues se agrupan, y un grupo muestra la puntuación promedio y la mejor de todas sus ejecuciones, además de una vista por vulnerabilidad de qué ejecución completó qué cadena. Las ejecuciones repetidas una al lado de la otra son la forma de separar la varianza de la mejora. Una sola ejecución prueba muy poco, y la plataforma se basa en esa suposición.
Automatización
Todo en la consola también está disponible a través de una API y un servidor de Protocolo de Contexto de Modelo (MCP), con un token de portador. Desplegar un lote de objetivos, lanzar el agente, extraer la cobertura y el progreso de la cadena de muerte y recopilar la comparación al final se puede ejecutar desde una canalización de CI o desde un asistente de chat sin que nadie lo supervise. La consola es para las personas que leen resultados. La API es para la matriz de experimentos.
Prueba de campo: 48 horas en DEF CON 34
Bug Bounty Village organiza un CTF en DEF CON cada año para la comunidad de caza de errores, y es una de las mejores cosas que suceden allí. Para la edición de DEF CON 34 en agosto de 2026, CTF.ae construyó el objetivo: Xenoptic, una empresa ficticia de IA con un alcance sofisticado. Cada uno de los 545 jugadores registrados recibió su propia copia aislada de toda la empresa, y XRanges for AI observó a cada uno de ellos durante las 48 horas completas.
La razón fue la equidad. Un concurso como este se juzga por los informes presentados, y un informe por sí solo no dice nada sobre cómo llegó el jugador hasta allí. Alguien podría haber encontrado un error no intencionado que expusiera todas las banderas a la vez, o traer un CVE externo, escapar del contenedor y recolectar las banderas sin tocar la aplicación. En DEF CON esa es una suposición justa. CTF.ae necesitaba ver cómo cada jugador, y el agente de cada jugador, se movía realmente por el entorno, para que lo presentado pudiera contrastarse con lo que realmente sucedió en el despliegue de ese jugador.
Eso es lo que entregó la plataforma. A través de más de 850 despliegues, transmitió las mismas cuatro señales que ahora usa con agentes:
- – Integridad confirmó que cada entorno se mantuvo saludable.
- – Límites registraron a cualquiera que se saliera de las reglas de participación.
- – Cobertura mostró cuánto del objetivo había trabajado realmente cada jugador.
- – Explotado registró qué vulnerabilidades se explotaron realmente, y en qué paso, para que cada envío pudiera verificarse contra una ruta real.
Todo provino desde dentro del objetivo, nunca desde la máquina del jugador. Cientos de despliegues concurrentes bajo ataque sostenido de investigadores capacitados es una prueba más dura que un agente en un laboratorio. La misma instrumentación ahora evalúa agentes.
Para quién es
XRanges for AI es para equipos que desarrollan agentes autónomos de seguridad y necesitan saber qué hizo su agente en lugar de qué dijo que hizo. Se ejecuta como un servicio en la nube gestionado o autoalojado en la infraestructura del cliente, donde nada sale de su entorno. Los equipos que quieran poner un agente contra un objetivo que nunca ha visto pueden hablar con nosotros.




















Deja una respuesta