Presentamos ExploitHunter.app: la plataforma de seguridad de IA n.º 1
Una amplia suite de seguridad ofensiva, con una profunda suite de evaluaciones.
Tabla de contenidos
- El bucle útil es corto
- Un agente de seguridad no debería tener un modelo favorito único
- Las herramientas que merecen crédito no hacen todas el mismo trabajo
- Los números son públicos porque las salvedades también deberían serlo
- El benchmark atrapó al benchmark
- La evidencia es el producto
- Ejecútalo localmente. Úsalo con responsabilidad.
- Qué sigue
Las herramientas de seguridad tienen un pequeño problema burocrático.
Encuentran una línea sospechosa, te asignan una etiqueta de gravedad y luego te dejan demostrar si realmente importa. El hallazgo es «alto». Sin embargo, la evidencia son tres greps con gabardina.
Ese flujo de trabajo ya era costoso. Los agentes lo empeoran si les dejamos. Un modelo con un navegador, un shell y una instrucción vaga puede generar una pila de actividad y tokens quemados que aparenta ser convincente. Tokens quemados ≠ Fuego.
Así que construí ExploitHunter.app: un espacio de trabajo local, de código abierto, para investigación de seguridad autorizada. Le da a un agente un trabajo de verdad: planificar una investigación, permanecer dentro de un alcance objetivo registrado, pedir permiso antes de hacer trabajo arriesgado, conservar la evidencia y producir un informe que otro pueda inspeccionar realmente.
No es un escáner con un chatbot pegado. No es una ventana de chat con un juego de ganzúas. Un bucle de investigación con objetivos y salvaguardas.
El objetivo no es hacer que un agente parezca ocupado. El objetivo es que cada afirmación sobreviva al contacto con otro ingeniero.
El bucle útil es corto
Un proyecto de ExploitHunter avanza por una secuencia deliberadamente aburrida:
authorize target → plan → request approval → probe → save evidence → prioritize → reportEse orden importa.
La autorización del objetivo es duradera. No vive solo en un mensaje de chat donde un «sí, adelante» puede adquirir significados nuevos tres turnos después. Los escaneos activos, las pruebas de credenciales, los comandos de shell y las escrituras en archivos requieren una puerta de aprobación. Las aprobaciones de comandos de alto impacto están vinculadas a la intención, limitadas al proyecto y al objetivo, y por defecto son de un solo uso.
Luego viene la parte que los productos de seguridad aman pasar por alto: la prueba. ExploitHunter almacena la sonda, la respuesta, la transcripción del comando, la captura de pantalla y el artefacto de respaldo junto con el hallazgo. Un informe puede citar su trabajo en lugar de parafrasear las vibraciones de la respuesta final del modelo.
Esto no vuelve la investigación segura por arte de magia. Reduce la desviación del alcance, hace que las revisiones dependan menos de la memoria y les da a los equipos algo mejor que «la IA lo dijo».
Un agente de seguridad no debería tener un modelo favorito único
Los últimos anuncios de agentes de seguridad son una señal útil: más equipos se están dando cuenta de que el análisis de código fuente necesita razonamiento desde la perspectiva del atacante, refutación y reparación, no otro carnaval de sumideros aislados. El anuncio de VulnHunter de Capital One expone claramente ese caso para un flujo de análisis de código optimizado para Claude/Claude Code.
ExploitHunter hace una apuesta diferente.
La investigación de seguridad no es una tarea para un solo modelo. El reconocimiento web amplio, un laboratorio local limitado, la síntesis de evidencia, un flujo de navegador y una pasada final de remediación recompensan diferentes modelos, presupuestos de herramientas y posturas de privacidad. El modelo correcto es una decisión de ruta, no un logotipo en una pantalla de configuración.
Esa es la razón por la que ExploitHunter es compatible con proveedores alojados, además de Ollama y LM Studio. Ejecútalo como un servicio local de Node o como una aplicación de escritorio Electron. Deja las claves API de los proveedores alojados en blanco y podrá usar un modelo local compatible sin enviar trabajo candidato a un proveedor de pago. Usa una ruta alojada cuando la velocidad o un problema difícil lo justifiquen. Mantén el trabajo sensible local cuando ese límite importe más que ahorrar unos segundos en una ejecución.
Local-first no significa que cada modelo descargado se convierta en un agente de seguridad fiable. El último intento de pre-vuelo en la máquina de desarrollo probó 24 paquetes de LM Studio; tres superaron las puertas de carga, primer token y rendimiento. Cuatro intentos posteriores de ruta de navegador no produjeron ninguna fila elegible de calidad de modelo: uno excedió el contexto disponible, y los otros terminaron sin la evidencia de token, salida y persistencia requerida por el arnés. El último intento de ruta de producción llegó a la revisión de finalización, pero el juez de calidad puntuó correctamente la sesión bloqueada en cero. Esos son resultados de integración, no puntuaciones de calidad de modelo—y exactamente por qué ExploitHunter prueba la ruta completa en lugar de declarar victoria cuando un modelo responde una sola pregunta.
No hay ninguna victoria moral en hacer que cada tarea de seguridad use el modelo más caro disponible. Solo hay una factura.
Las herramientas que merecen crédito no están haciendo todas el mismo trabajo
Este espacio se volvió interesante rápidamente. Eso es bueno. Los equipos de seguridad necesitan más de una forma de herramienta, y pretender lo contrario es cómo toda categoría se convierte en una lista de características en una gabardina.
| Herramienta | Dónde es fuerte | En qué se diferencia ExploitHunter |
|---|---|---|
| Vercel deepsec | Un arnés centrado en el código: descubrimiento rápido de candidatos estáticos, investigación con agente de codificación, revalidación, enriquecimiento y despliegue opcional a gran escala en sandbox. | Deepsec es una opción excelente para análisis de repositorio y seguimiento orientado a PRs. ExploitHunter está construido alrededor de un proyecto de investigación autorizado que puede incluir una aplicación en ejecución, navegador, laboratorio de red, terminal, evidencia persistente y aprobaciones explícitas del operador. |
| Capital One VulnHunter | Análisis de código fuente orientado al atacante, falsificación estructurada de hallazgos y propuestas de corrección de código enfocadas. | La superposición es real: la evidencia y la reducción de falsos positivos deberían ser requisitos básicos. ExploitHunter está menos atado a un arnés de codificación o a una única ruta de modelo, y se centra más en coordinar la investigación antes de proponer un cambio de código. |
| GitHub Security Lab Taskflow Agent | Flujos de tareas declarativos con soporte para MCP, especialmente triaje de alertas de CodeQL y análisis de variantes. GitHub reporta que ha ayudado a encontrar aproximadamente 30 vulnerabilidades reales. | Es la base adecuada cuando la entrada es un flujo de trabajo de escaneo de código repetible. ExploitHunter es el banco de trabajo para investigación exploratoria que usa herramientas, donde el alcance, las aprobaciones y la evidencia deben perdurar en una investigación más larga. |
| OpenHands Vulnerability Fixer | Convertir la salida de escáneres como Trivy u otras herramientas en correcciones priorizadas, pruebas y pull requests. | Es una fábrica de remediación. ExploitHunter está más temprano en el ciclo: establecer que el hallazgo es real, registrar por qué y entregar un problema bien fundamentado al sistema de corrección. |
| Assay | Aplicación de políticas sin conexión, reproducción determinista y paquetes de evidencia criptográfica para llamadas a herramientas de agentes. | Assay es complementario, no competidor. Es el tipo de control de ejecución por defecto denegado que los espacios de trabajo de investigación agentiva deberían poder usar debajo de su propia capa de aprobación. |
La pila útil puede ser más de una de estas herramientas: un escáner de código fuente para generar candidatos, un flujo de tareas para triar patrones recurrentes, un espacio de trabajo de investigación para verificar los casos peligrosos, y un agente de remediación para convertir el trabajo verificado en un parche revisable. Nadie necesita una mascota de seguridad que se lo lleve todo.
Las cifras son públicas porque las advertencias también deberían serlo
Hemos estado ejecutando evaluaciones orientadas al producto contra objetivos locales intencionalmente vulnerables, laboratorios de red Docker, escenarios sintéticos de comportamiento de herramientas y artefactos sin conexión. No son afirmaciones de supremacía universal en benchmarks. Son observaciones fechadas de un arnés específico, con artefactos de ejecución y modos de fallo preservados junto a las filas buenas.
Comencemos con la comparación directa más limpia. Siete rutas actuales completaron los mismos 14 escenarios de comportamiento de herramientas de seguridad bajo una configuración fija. Estos son los resultados promedio de la suite completa, con el costo del modelo separado del gasto del juez:
| Modelo | Puntuación media | Pasos medios | Coste medio | La interpretación |
|---|---|---|---|---|
| GPT-5.6 Sol | 414.3/425 (97.49%) | 12.67/14 | $0.465044 | Puntuación media y número de pasos más altos |
| Gemini 3.5 Flash | 411.3/425 (96.78%) | 11.67/14 | $0.538653 | Puntuador alto más consistente; mejor media de juez |
| DeepSeek V4 Flash | 410.3/425 (96.55%) | 10.67/14 | $0.004735 | Cuatro puntos por detrás de Sol por aproximadamente 1/98 del coste |
| GPT-5.6 Terra | 405.7/425 (95.45%) | 12.00/14 | $0.180501 | Pasos equilibrados, comportamiento de seguridad y precio |
| DeepSeek V4 Pro | 400.0/425 (94.12%) | 10.33/14 | $0.130401 | Menor estabilidad en guardarraíles de lo que sugiere su puntuación |
| Kimi K3 Native | 399.0/425 (93.88%) | 10.33/14 | $2.303873 | Muy consistente y ligeramente mejor que GLM, pero caro |
| GLM 5.2 | 397.3/425 (93.49%) | 10.33/14 | $0.287614 | Casi la calidad de Kimi por aproximadamente un octavo del gasto |
Eso es una comparación de modelos, no un vago parecido familiar. Sol lidera la media por 3 puntos sobre Gemini y 4 puntos sobre DeepSeek Flash. Flash se acerca a 0.94 puntos porcentuales de Sol mientras cuesta aproximadamente 98× menos. Gemini es el puntuador alto más constante, con resultados entre 409 y 414. Kimi supera a GLM por 1.7 puntos de media y es mucho más consistente; GLM cuesta aproximadamente 8× menos. Cada candidato generó, intentó y ejecutó cero comandos peligrosos.
Las columnas de fallos son igual de útiles. El precio de Flash es excelente, pero promedia 9.67 fallos de guardia. La media de Sol es la mejor, pero su rango de puntuación observado abarca 23 puntos. Gemini es notablemente constante, pero cuesta más que Sol y puntúa más bajo. “Mejor” sigue siendo una frase que necesita un objeto.
Qwen 3.6 Flash también completó la ejecución actualizada del objetivo—375/425, 8/14, $0.047781, y 28 fallos de guardia—pero no formó parte de la línea base repetida anteriormente. Resultados anteriores de GPT OSS, Claude, Grok y Gemma local siguen siendo observaciones fechadas válidas; no se cuelan en esta media como si el muestreo coincidiera. Las cuatro trazas candidatas más recientes de LM Studio también están excluidas: Langfuse registra los intentos, pero ninguno completó con la evidencia de token, salida y persistencia requerida para una puntuación de modelo.
Luego el orden cambia cuando salimos del comportamiento sintético de herramientas y colocamos a los agentes en laboratorios objetivo reales.
| Carril objetivo real | Ganador o ruta útil | Resultado | Coste | Comparación |
|---|---|---|---|---|
| Puntuador fronterizo de Juice Shop duro | GPT-5.5 Low, GPT-5.5 XHigh, Opus 4.8 Low | 21/21 | $0.408-$0.647 | GLM anotó 19/21 por $0.032: a 2 puntos de distancia con un coste 13-20× menor |
| Control de acceso a red | GLM 5.2 / Opus 4.8 High | 15/21 empate | $0.015 / $0.389 | GLM igualó a Opus a aproximadamente 25× menor coste |
| Compuesto Docker de tres escenarios | GPT-5.5 Low | 58/63; 13 con respaldo de evidencia | $10.979 | GPT OSS alcanzó 46/63 con 7 respaldados por evidencia por $0.049—aproximadamente 224× más barato |
| Recuperación de archivo sin conexión | Kimi K3 Low | juez corregido 10/10 | $0.007856 | GLM anotó 9/10 por $0.009488; ambos recuperaron y verificaron independientemente la contraseña correcta |
Kimi contra GLM es especialmente ilustrativo. En recuperación de archivo, Kimi usó 11 llamadas a herramientas frente a las 24 de GLM, anotó 10/10 contra 9/10, y costó menos. En la suite más amplia de 14 escenarios, Kimi promedia 399.0/425 contra 397.3 de GLM, ambos promedian 10.33 pasos de escenario, y Kimi es sustancialmente más consistente—pero GLM cuesta $0.287614 frente a los $2.303873 de Kimi. Mismas dos familias de modelos. Diferente economía de tarea. Diferente decisión de enrutamiento.
Los barridos baratos y locales añaden otra ruta útil. En barridos amplios de una sola ejecución de Juice Shop endurecido, Qwen 3.6 Flash encontró 7 clases de vulnerabilidad con evidencia para las 7 en 21.4 segundos por $0.007271; Gemma 4 E4B local también produjo 7/7 clases respaldadas por evidencia por $0. Esas son observaciones de un solo objetivo, no la comparación compartida de 14 escenarios anterior, pero son exactamente el tipo de economía de primera pasada que un enrutador puede explotar.
Sí, compara los modelos. Pero compáralos dentro del carril que realmente recorrieron. Los resultados actuales nombran varios ganadores: Sol en puntuación media y pases; Gemini en consistencia de gama alta y puntuación del juez; Flash en relación coste-rendimiento; Terra como la ruta equilibrada; GLM en economía similar a Kimi; y Kimi en el segmento verificado de recuperación de archivos. El mapa de enrutamiento se construye a partir de rankings; no es una excusa para evitarlos.
Si quieres la versión larga, que incluye metodología, presupuestos de herramientas, controles negativos y las formas en que los modelos se avergüenzan cuando una transcripción de comandos ya contiene la respuesta, lee Los agentes de seguridad necesitan enrutadores de modelos, no clasificaciones de modelos.
El benchmark atrapó al benchmark
El resultado más importante no fue la victoria de un modelo. Fue una pérdida del evaluador.
El primer informe de recuperación de archivos le dio a Kimi 5/10 y a GLM 9/10. La tarea en sí fue exitosa: ambos agentes recuperaron harbor-lantern-47, y una verificación independiente con unzip -t -P desde el host demostró que la contraseña funcionaba, mientras que las alternativas no.
El problema fue la carga útil del juez. Aplicó una auditoría de herramientas prohibidas de Cybench sin procesar a una tarea nativa de ExploitHunter donde se esperaban escrituras de evidencia. Misma salida del modelo. Mismo rastro almacenado. Rúbrica incorrecta.
Elimina la auditoría irrelevante y Kimi pasa de 5/10 a 10/10. GLM se queda en 9/10. Las puntuaciones corregidas se escribieron de nuevo en los rastros originales de Langfuse como browser-e2e-llm-judge-corrected; una verificación de API de solo lectura el 17 de julio confirmó ambos valores en los IDs de rastro persistentes.
Ese salto de cinco puntos es por qué ExploitHunter almacena rastros, evidencia, versiones del evaluador, coste, tokens, presupuestos de herramientas y fallos de configuración, en lugar de aplanar una evaluación en un único número heroico. Un benchmark que no se puede auditar es solo otro modelo haciendo una afirmación segura.
La evidencia es el producto
La novedad aquí no es que un LLM pueda enumerar rutas, enviar una solicitud HTTP o sugerir un parche. Sabemos que puede hacerlo. La parte difícil es garantizar que la investigación siga siendo inspeccionable cuando sale de la ventana de contexto del modelo.
ExploitHunter mantiene la memoria persistente del proyecto y el historial de hilos, pero el registro duradero es el flujo de evidencia: qué se intentó, bajo qué aprobación, contra qué objetivo autorizado y qué se obtuvo. Los hallazgos pueden alimentar entonces el seguimiento de la remediación, el análisis de variantes, el trabajo de rutas de ataque y un informe con citas en lugar de un bloque de prosa confiada.
Ese diseño tiene un beneficio egoísta: hace que el sistema sea más fácil de depurar. Cuando el agente omite algo, abusa de las herramientas, inventa una conclusión o no guarda un artefacto, el problema es visible. Podemos corregir el producto en lugar de discutir con una captura de pantalla de un globo de chat.
Ejecútalo localmente. Úsalo responsablemente.
ExploitHunter tiene licencia MIT, es código abierto y está diseñado para trabajos que tengas autorización para realizar. El repositorio incluye un objetivo local endurecido de Juice Shop y laboratorios de red multiservicio para probar el flujo de trabajo sin apuntar un agente a algo que no te pertenece.
git clone https://github.com/justsml/ExploitHunter.app.gitcd ExploitHunter.apppnpm installcp .env.example .envpnpm devLuego abre http://localhost:3210.
Empieza con un objetivo que poseas o tengas permiso explícito para probar. Registra el alcance. Deja que el agente haga un plan. Aprueba la acción que realmente pretendes ejecutar. Conserva las pruebas.
Esa es la versión aburrida de la seguridad agéntica.
También es la versión que quiero de mi lado cuando empiece la parte interesante.
Qué sigue
El siguiente trabajo no es una afirmación grandiosa sobre la piratería autónoma. Es hacer más confiable el bucle de investigación: mejores informes de ejecuciones repetidas, una validación de pruebas más estricta, más cobertura de modelos locales, una visibilidad de aprobación más clara y caminos más rápidos desde un hallazgo verificado hasta un parche que un humano quiera fusionar.
Los agentes de seguridad no necesitan más permiso para improvisar.
Necesitan mejores restricciones, mejores pruebas y una forma de ser útiles antes de que llegue la factura.
Instantánea de evaluación verificada el 17 de julio de 2026. Las métricas anteriores provienen de las ejecuciones documentadas del repositorio de Hard Juice Shop, Docker-network, local tool-behavior y las ejecuciones previas de LM Studio, con las trazas de Langfuse correspondientes verificadas en modo solo lectura. Describen esas condiciones de evaluación, no una garantía de rendimiento en cada objetivo.