LanzamientoAnálisis · En radarX: @NousResearch→ original

Hermes Agent incorpora la búsqueda de vulnerabilidades en código con el plugin oficial Security

Nous Research ha incorporado a Hermes Agent el plugin oficial Security, que busca vulnerabilidades en el código. El agente determina primero qué puede alcanzar un atacante y en qué datos de entrada confía el código. Después reparte el trabajo entre subagentes en paralelo y contrasta cada problema detectado con el código. Para los equipos sin un especialista dedicado a seguridad, ofrece una forma práctica de realizar una primera revisión del repositorio.

Procesado por IA desde X: @NousResearch; editado por Hamidun News
Hermes Agent incorpora la búsqueda de vulnerabilidades en código con el plugin oficial Security
Fuente: X: @NousResearch. Collage: Hamidun News.
Escuchar artículo
Ficha técnica y cifras clave
ParámetroDatos
Fuente originalX: @NousResearch ↗
Editor jefe
Dato clave #1El autor del plugin es @mark_s y se trata de un lanzamiento oficial
Primero, el modelo de amenazasa qué puede acceder un atacante y en qué confía el código
Dato clave #3Los subagentes trabajan en paralelo y se verifica cada hallazgo

Cualquiera que haya entregado código a un LLM con la instrucción «busca vulnerabilidades» sabe cómo termina la historia. El modelo devuelve una larga lista de «posibles problemas», la mitad de ellos inventados o imposibles de alcanzar desde un punto de entrada real. Revisar ese informe lleva más tiempo que buscar los fallos por cuenta propia. Nous Research intenta resolver precisamente este problema: Hermes Agent ya cuenta con un plugin oficial llamado Security, desarrollado por @mark_s.

Qué sabemos sobre el funcionamiento del plugin

Según el anuncio, Hermes comienza con una fase de reconocimiento en lugar de lanzarse directamente a buscar fallos. Primero, el agente traza un mapa de los componentes del proyecto a los que puede acceder un atacante y de los datos de entrada en los que confía el código. Es la lógica habitual del modelado de amenazas. Una vulnerabilidad en una función inaccesible desde el exterior y ese mismo fallo en el manejador de una petición pública tienen consecuencias económicas distintas.

A continuación, el código se reparte entre subagentes que trabajan en paralelo. Cada uno examina su sección, de modo que un repositorio grande no queda limitado a la ventana de contexto de un solo modelo. A juzgar por el anuncio, el tercer paso es el más importante: el agente contrasta cada problema detectado con el código antes de incorporarlo al informe. El final de la publicación está cortado, por lo que la fuente no permite saber exactamente qué ocurre después de esa verificación.

Por qué el enfoque parece razonable

Imaginemos un servicio web típico. Tiene un endpoint que recibe del usuario un nombre de archivo y lo lee del disco. Un prompt de revisión demasiado básico podría señalar una docena de apariciones de open en distintos archivos. El procedimiento descrito en el anuncio funciona de otra manera. Primero identifica que el parámetro procede de una entrada no confiable. Después, el agente sigue su recorrido y solo entonces informa de una posible vulnerabilidad de recorrido de directorios. El hallazgo queda vinculado a un flujo de datos concreto, lo que facilita su verificación por una persona.

Los subagentes en paralelo resuelven aquí un problema de ingeniería. Auditar un monolito de forma secuencial lleva mucho tiempo y llena rápidamente la ventana de contexto. Dividir el trabajo en secciones acelera el proceso y reduce el riesgo de que el modelo pierda detalles a mitad del análisis.

Qué seguimos sin saber

La publicación es breve y su alcance, modesto: unas 15.000 visualizaciones. Por eso es importante no atribuirle más de lo que demuestra. La fuente no aporta datos sobre la tasa de falsos positivos, los lenguajes compatibles, el coste de ejecutar el plugin en un repositorio grande ni su comparación con analizadores estáticos. Tampoco incluye ejemplos de vulnerabilidades reales detectadas. Por ahora, se trata de un enfoque anunciado, no de un resultado demostrado.

También existe un riesgo común a todos los agentes de auditoría: la verificación «contra el código» sigue estando a cargo de un modelo. Este puede confirmar con seguridad un hallazgo erróneo o pasar por alto uno real. Una herramienta así no sustituye al SAST, a las pruebas de penetración ni a la revisión humana.

Qué hacer en la práctica

Si ya utilizas Hermes Agent, conviene probar el plugin en un servicio pequeño cuyos puntos débiles conozcas. Introduce de antemano un par de problemas conocidos y comprueba si el agente los encuentra y cuánto ruido añade. Es la forma más rápida de evaluar su calidad sin dar por bueno el anuncio.

Para los equipos sin un especialista dedicado a seguridad, una función razonable para este tipo de herramienta es realizar una primera revisión antes de un lanzamiento o de una auditoría completa. Debería detectar los problemas evidentes y plantear hipótesis indicando de dónde surgen. Para responsables de producto y fundadores, la conclusión es sencilla: los agentes de revisión de seguridad están pasando de generar listas a seguir un proceso de «reconocimiento, reparto del trabajo y verificación». Esas tres capacidades deberían servir para comparar las soluciones competidoras.

La llegada de un plugin oficial del equipo de Nous también apunta a otra tendencia. El ecosistema de Hermes Agent crece gracias a las extensiones, además de al propio modelo. Las pruebas independientes mostrarán hasta qué punto resulta útil este plugin concreto; una publicación en X no basta para demostrarlo.

Historia

Preguntas frecuentes sobre la noticia

¿Qué se sabe sobre Qué sabemos sobre el funcionamiento del plugin?

Según el anuncio, Hermes comienza con una fase de reconocimiento en lugar de lanzarse directamente a buscar fallos. Primero, el agente traza un mapa de los componentes del proyecto a los que puede acceder un atacante y de los datos de entrada en los que confía el código. Es la lógica habitual del modelado de amenazas. Una vulnerabilidad en una función inaccesible desde el exterior y ese mismo fallo en el manejador de una petición pública tienen consecuencias económicas distintas.

¿Qué se sabe sobre Por qué el enfoque parece razonable?

Imaginemos un servicio web típico. Tiene un endpoint que recibe del usuario un nombre de archivo y lo lee del disco. Un prompt de revisión demasiado básico podría señalar una docena de apariciones de open en distintos archivos. El procedimiento descrito en el anuncio funciona de otra manera. Primero identifica que el parámetro procede de una entrada no confiable. Después, el agente sigue su recorrido y solo entonces informa de una posible vulnerabilidad de recorrido de directorios.

¿Qué se sabe sobre Qué seguimos sin saber?

La publicación es breve y su alcance, modesto: unas 15.000 visualizaciones. Por eso es importante no atribuirle más de lo que demuestra. La fuente no aporta datos sobre la tasa de falsos positivos, los lenguajes compatibles, el coste de ejecutar el plugin en un repositorio grande ni su comparación con analizadores estáticos. Tampoco incluye ejemplos de vulnerabilidades reales detectadas. Por ahora, se trata de un enfoque anunciado, no de un resultado demostrado.

ZK
Zhemal Khamidun — CPO de Alpina Digital, product manager de AlpinaGPT. Crea productos de IA desde 2019. Hamidun News es un proyecto personal que creció hasta ser un agregador en producción con más de 6.000 lectores.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
¿Qué te parece?
Cargando comentarios…