EvoMap
Cómo usar MCP con Hermes Agent de manera segura

Cómo usar MCP con Hermes Agent de manera segura

27 de abril de 2026
230 visualizaciones
hermes-agent mcp security tool-permissions prompt-injection developer-tools

Cómo Usar MCP con Hermes Agent de Forma Segura

Hola, soy Lena. No planeaba escribir sobre MCP esta semana. Solo intentaba conectar un segundo servidor de herramientas a una instancia de Hermes Agent que he estado ejecutando, y en algún momento entre editar la configuración y ver actualizar la lista de herramientas, me detuve.

El agente ahora tenía acceso a cuatro servidores que no había tenido diez minutos antes. Realmente no había pensado en lo que cada uno podía leer. Volví a los documentos. Luego volví a la configuración. Ahí es donde dejaré la introducción por ahora — porque esa pequeña pausa es básicamente de lo que trata todo este artículo.

Esto no es una introducción a MCP. Si estás aquí, probablemente ya sabes qué es el protocolo. Lo que quiero escribir es lo que he estado aprendiendo sobre usar MCP con Hermes Agent sin entregarle al agente más de lo que pretendía.

Lo que realmente agrega MCP a Hermes Agent

Acceso a herramientas externas sin herramientas nativas de Hermes

Hermes viene con un conjunto fijo de capacidades integradas. MCP es la manera de extender ese conjunto sin escribir una nueva herramienta nativa. Apuntas a Hermes a un servidor —local o remoto— y la lista de herramientas de ese servidor aparece junto con las integradas. Desde la perspectiva del agente, casi no hay diferencia.

Ese "casi" importa. Las herramientas integradas viven dentro del propio modelo de permisos de Hermes. Las herramientas MCP viven detrás de una frontera de protocolo, y lo que realmente hacen en tu máquina o en tu red depende completamente del servidor en el que confiaste.

Por qué MCP es una capa adaptadora, no una función mágica

Sigo recordándome esto. MCP no hace que una herramienta sea más segura ni más inteligente. Estandariza cómo se describe una herramienta al agente, y cómo las llamadas y respuestas se mueven de ida y vuelta por JSON-RPC 2.0. Eso es todo.

Así que cuando algo sale mal con una herramienta MCP en Hermes, el error casi nunca está en MCP. Está en el servidor al que te conectaste, en las credenciales que está usando, o en la suposición de que "el agente hará lo correcto para llamar". Tuve que aprender eso dos veces.

Cuándo usar MCP y cuándo no

Buenas opciones, malas opciones y superficies de herramientas sobreexpuestas

Donde MCP realmente tiene sentido en una configuración de Hermes:

  • Trabajo de lectura intensiva sobre sistemas externos — obtener problemas, consultar registros, buscar documentación, explorar archivos a los que un agente no puede acceder nativamente.
  • APIs internas en las que ya confías, envueltas en un pequeño servidor MCP que controlas.
  • Integraciones únicas donde escribir una herramienta nativa de Hermes sería excesivo.

Donde lo pensaría dos veces:

Si un flujo de trabajo es raro, sensible o de corta duración, MCP probablemente no sea la forma adecuada para él. Construyéndolo como un script y llámalo explícitamente.

! [imagen] (https://uploads.evomap.ai/blog/0ee599137c7092e6.png)

Configurar MCP en Hermes de forma segura

Stdio vs servidores remotos

Dos transportes. No son intercambiables.

Stdio ejecuta el servidor MCP como un proceso hijo en tu máquina. Hermes se comunica con él a través de stdin/stdout. Es sencillo, de baja latencia y bueno para cosas como sistemas de archivos locales o herramientas de desarrollo. El contraprecio: estás ejecutando un binario en tu propia máquina, y la maquinaria OAuth/token realmente no se aplica aquí.

Remote (HTTP streamable) ejecuta el servidor en otro lugar y se comunica por HTTP. Aquí es donde la autorización realmente tiene fuerza. Según la [especificación oficial MCP], los servidores MCP en este modo ahora se clasifican como Servidores de Recursos OAuth, lo que significa que los tokens tienen un alcance y audiencia definidos en lugar de ser una clave de API genérica](https://modelcontextprotocol.io/specification/2025-11-25). Creo que empiezo a entender por qué la especificación de noviembre de 2025 se inclina tanto por esto: claves API estáticas únicas estaban creando silenciosamente la peor versión de cada problema.

Una regla aproximada a la que sigo volviendo: stdio para cosas que realmente necesitan ser locales, remotas para cualquier cosa que se comunique con un servicio de red real. Mezclar ambos en la misma configuración de Hermes está bien, pero los etiqueto claramente para no olvidar cuál es cuál.

! [imagen] (https://uploads.evomap.ai/blog/80762ecbd4db1799.png)

Filtrado por servidor, aislamiento ambiental, flujo de trabajo /reload-mcp

Tres hábitos que me han ahorrado tiempo real:

  1. Filtra la superficie de herramientas por servidor. Si un servidor expone 20 herramientas y el agente solo necesita 3, no cargues las otras 17. Hermes te permite permitir listas de nombres de herramientas por servidor. Esto no es paranoia: reduce directamente la superficie de inyección de prompts que mencioné antes.
  2. Aísla las variables de entorno. No vuelques todo tu entorno de shell en cada servidor MCP que generes. Pasa solo las variables que ese servidor específico necesita y referencia secretos mediante expansión (por ejemplo, "GITHUB_TOKEN": "$GITHUB_TOKEN") en lugar de codificarlos. Otros entornos de agente redactan automáticamente variables que coinciden con patrones como TOKEN, SECRET, PASSWORD antes de generar procesos MCP; Hermes no hará esto por ti por defecto, así que debes ser explícito.
  3. Usa /reload-mcp deliberadamente, no de manera reflexiva. Cuando cambies la configuración de un servidor, recárgalo, pero revisa la nueva lista de herramientas antes de seguir trabajando. Una recarga es el único momento en el que naturalmente vuelves a leer a qué tiene acceso el agente. Puede que esté sobreanalizando esto, pero saltarse esa verificación es cómo ocurren silenciosamente los aumentos de privilegios.

Patrones diarios de MCP que realmente funcionan

GitHub, bases de datos, APIs internas, stacks de navegador

Algunos patrones que he visto que funcionan:

Acceso de solo lectura estilo GitHub. Tokens de acceso fino y con alcance limitado. El agente puede leer issues, PRs y código, pero no puede hacer push ni merge. Las acciones de escritura pasan por un humano.

Bases de datos. Solo réplicas de lectura. Incluso así, mantengo los tiempos de espera de consultas cortos y los máximos de filas de resultados bajos; que los agentes escriban consultas pesadas accidentalmente es un modo de falla real, no teórico.

APIs internas. Envuélvelas en un pequeño servidor MCP interno. No reutilices un token de cuenta de servicio maestro; emite uno más limitado específicamente para el agente. Los profesionales que estudian MCP a gran escala han notado que una parte significativa de los servidores MCP en el mundo real dependen de secretos estáticos de larga duración como claves API o PATs, que es exactamente el patrón más probable de filtrarse. Ese número se me quedó grabado.

Stacks de navegador. Son las integraciones con mayor radio de impacto. Un servidor MCP de navegador puede navegar, hacer clic y enviar formularios. Los mantengo desactivados a menos que los necesite activamente, y luego los apago de nuevo.

El hilo conductor de todo esto es mínimos privilegios por servidor, no por agente. Cada servidor MCP es una decisión de confianza separada.

Errores comunes de MCP en Hermes

Valores predeterminados inseguros, superficies gigantes de herramientas, suposiciones de configuración obsoletas

Cosas que he hecho mal, o que he visto hacer mal a otros:

  • Confiar en que "configuración predeterminada" significa "configuración segura." Generalmente significa "más fácil de demostrar." Vale la pena una auditoría de configuración en cualquier cosa copiada de un blog, incluyendo este — los valores predeterminados están escritos para el camino más sencillo, no para el más seguro.
  • Conectarse primero, definir el alcance después. La versión honesta es: definir el alcance después usualmente significa nunca. Establece los alcances cuando agregues el servidor.
  • Asumir que la descripción de una herramienta es lo que hace. Las descripciones de herramientas son instrucciones. Viven en el contexto del agente y moldean el comportamiento. Una descripción maliciosa o mal redactada puede cambiar los resultados de formas que el usuario nunca ve.
  • Olvidar que existe la deriva de configuración. Un servidor que era seguro el mes pasado puede haber actualizado su lista de herramientas. Recarga, vuelve a leer, vuelve a decidir.

Todavía no estoy completamente seguro de cómo automatizar eso último. Probablemente valga la pena volver a él.

Preguntas frecuentes

¿Necesito ​MCP​​ si ​Hermes​​ ya tiene herramientas que funcionan?

No. Agrega MCP cuando hay una brecha real. Los nuevos servidores aumentan la superficie independientemente de si los usas o no.

Studio o remoto — ¿cuál es "más seguro"?

Pregunta equivocada. Studio ejecuta un binario localmente; remoto atraviesa una red. Cada uno tiene diferentes amenazas. Decide según dónde residan realmente los datos y credenciales.

¿Puedo simplemente confiar en un servidor oficial ​MCP​​?

"Oficial" significa que lo escribió el proveedor. No significa que la configuración que tú le diste sea segura. El alcance y los tokens siguen siendo tu responsabilidad.

¿Con qué frecuencia debo revisar las configuraciones de ​MCP​​?

Siempre que agregue, elimine o actualice un servidor — y un escaneo rápido mensual incluso cuando no lo haya hecho.

Probablemente seguiré observando cómo evoluciona esto. El protocolo todavía está en movimiento, la especificación se sigue ajustando y los patrones que ahora parecen obvios podrían parecer ingenuos en seis meses. Por ahora, lo que ha sido más útil no es un fragmento de configuración — es el pequeño hábito de pausar cuando la lista de herramientas crece. Ahí lo dejo.

Publicaciones anteriores:

Artículos relacionados

Cómo usar MCP con Hermes Agent de manera segura - EvoMap Blog