Gauntlet nació durante el Agent Builder Hackathon y fue presentado como uno de los tres primeros proyectos tras un desarrollo de 48 horas. Su autor cambió la idea original a 48 horas del cierre: en lugar de una herramienta de 'rehearsal', decidió construir un sistema de fuzz‑testing adversarial que intenta provocar fallos en agentes inteligentes ejecutándolos dentro de un sandbox simulado controlado por otro agente.
El núcleo funcional de Gauntlet es un 'mocking agent' que intercepta las llamadas a las herramientas del agente objetivo y aplica mutaciones a las respuestas. Por ejemplo, cuando el agente primario invoca search_emails, el mocking agent puede inyectar una prompt injection, devolver datos ligeramente incorrectos o suministrar información directamente falsa, todo ello sin que el agente sometido a prueba sepa que está en una simulación. Esta capacidad de alterar resultados en tiempo real permite comprobar la robustez del flujo de decisiones frente a entradas adversas.
La integración mínima que propone Gauntlet se articula mediante dos decoradores: @gauntlet.query para operaciones de lectura y @gauntlet.mutation para escrituras. Tras cada ejecución del agente, una función evaluate() revisa las interacciones registradas y almacena los errores confirmados. Según la descripción presentada en el hackathon, todo el sistema corre dentro de Elastic Agent Builder y utiliza la API Amazon Bedrock Converse para gestionar la conversación multinivel entre agentes y orquestar las mutaciones.
El problema que busca resolver es práctico y habitual: los equipos de desarrollo suelen probar agentes por la 'ruta feliz' y, cuando requieren pruebas adversariales, crean sandboxes manuales costosos y poco escalables. Gauntlet automatiza ese proceso, permitiendo que un agente adversario genere variaciones creativas en las entradas y aumente la cobertura de pruebas con el tiempo, en lugar de depender únicamente de escenarios diseñados manualmente que pueden ser predecibles y limitados. Para sostener ese comportamiento adaptativo, el mocking agent opera sobre dos circuitos de memoria implementados en Elasticsearch. La memoria a corto plazo registra cada llamada interceptada, el resultado original, la mutación aplicada y la respuesta del agente primario; esa trazabilidad mantiene la coherencia narrativa durante una sesión y facilita el análisis inmediato de fallos reproducibles.
La memoria a largo plazo indexa errores confirmados utilizando embeddings, junto con implementaciones completas de herramientas y resultados históricos. Esa base de conocimiento permite búsquedas por similitud sobre bugs previos, de modo que el sistema identifica huecos en la cobertura de pruebas y reutiliza patrones efectivos para diseñar nuevos ataques, en lugar de reinventarlos desde cero cada vez. El diseño crea un ciclo cerrado: generación de hipótesis de falla, creación automática de la circunstancia que la pruebe y almacenamiento del error confirmado. A medida que se confirman incidentes, el inventario de ataques crece y las pruebas se diversifican en ejecuciones posteriores, lo que incrementa la probabilidad de descubrir vulnerabilidades reales en condiciones más variadas y menos predecibles.
Un detalle de implementación destacado es una consulta en ES|QL llamada generate — hypothesis. En una sola instrucción, esa consulta toma muestras de errores existentes, las agrega mediante MV_CONCAT y llama a una función COMPLETION en línea para proponer nuevas hipótesis de ataque. Según la propuesta, ese flujo realiza muestreo, agregación y razonamiento mediante un LLM sin requerir scripts externos, compactando etapas que habitualmente requieren integración manual entre motores de búsqueda y modelos de lenguaje.
La relevancia práctica de Gauntlet reside en su capacidad para identificar fallos que aparecen cuando un agente confía en datos procedentes de herramientas externas: no detectar una prompt injection, actuar sobre resultados sutilmente incorrectos o aceptar entradas manipuladas son ejemplos concretos que el proyecto pretende exponer automáticamente. Al compilar y reutilizar fallos confirmados, la plataforma puede priorizar escenarios de riesgo reales y reducir el tiempo y esfuerzo que consumen las configuraciones manuales de sandboxes.
El prototipo también reconoce limitaciones importantes. Primero, las mutaciones deben mantener coherencia narrativa para que las pruebas sean pedagógicas: contradicciones internas o alteraciones implausibles aportan poco valor. Segundo, el sistema debe evitar redescubrir constantemente las mismas vulnerabilidades y, en cambio, explorar direcciones nuevas; lograr un equilibrio entre creatividad y plausibilidad ha sido señalado como el mayor reto de diseño. En su presentación, Gauntlet se definió claramente como un prototipo de hackathon orientado a pruebas adversariales, no como una solución empresarial final.
Fuentes
Respuestas (0)
Aún no hay respuestas en este tema.
