Perfiles de Agente Hermes: Ejecuta Múltiples Agentes de Forma Segura

Hola, soy Lena. Tenía una pregunta que seguía posponiendo. Finalmente intenté responderla.

Hace unas semanas, estaba cambiando entre dos agentes Hermes en la misma máquina: uno que configuré para experimentos personales y otro relacionado con un pequeño proyecto de cliente. Por accidente compartían el mismo directorio de configuración. Al principio no me di cuenta. Luego, una memoria de sesión del agente personal apareció en una conversación en la que no debería haber estado. Me detuve por un largo tiempo después de ver eso. Los agentes en realidad no estaban separados. Solo parecía que lo estaban.

Fue entonces cuando empecé a leer más cuidadosamente sobre lo que los perfiles de agentes Hermes realmente hacen, no el comando superficial, sino qué se aísla y qué no. Esto es lo que he reunido hasta ahora. No creo tener la imagen completa todavía, pero las piezas que tengo me parecen valiosas para escribirlas.

Estoy escribiendo esto para las personas que ya han pasado de ejecutar un solo agente a ejecutar varios. Ese momento en que te das cuenta de que necesitas más de uno también es el momento en que comienzan la mayoría de los problemas de aislamiento. Los valores predeterminados que funcionaron para un agente no funcionan para dos, y fallan de maneras silenciosas que no notas hasta que algo ya ha cruzado un límite.

Lo que los perfiles Hermes realmente aíslan

Un perfil, según lo entiendo ahora, es un alcance con nombre que contiene todo lo que una instancia de agente necesita para comportarse como sí misma: su configuración, memoria, sesiones, habilidades registradas, estado del gateway y variables de entorno. Cuando cambias de perfil, no solo estás cambiando una configuración: estás intercambiando todo el contexto en el que el agente opera. Esa distinción importa más de lo que inicialmente pensé.

Configuración, memoria, sesiones, habilidades, estado del gateway, variables de entorno

Volví a mirar esta lista más detenidamente, y lo que me sorprendió es cuánto estado vive en este alcance. Si has usado variables de entorno en alguna herramienta CLI seria, el patrón se siente familiar. Cada perfil lleva su propio:

• Configuración — selección de modelo, temperatura, modificaciones al prompt del sistema, permisos de herramientas
• Memoria — contexto a largo plazo que el agente ha acumulado con el tiempo
• Sesiones — hilos de conversación activos, incluidas las que se pueden reanudar
• Habilidades — capacidades registradas y sus credenciales de alcance
• Estado del gateway — reglas de enrutamiento, registros en el servidor MCP, políticas de red
• Variables de entorno — claves API, endpoints, secretos

Lo que quiero destacar: esto es un límite de seguridad, no solo organizativo. Cuando OWASP describe cómo reforzar arquitecturas de agentes, aislar la memoria y el contexto entre sesiones es una de las primeras defensas mencionadas. Los perfiles son la forma en que Hermes implementa esa idea para cada agente. Leí esa hoja de trucos dos veces antes de que esto hiciera clic para mí.

Todavía no estoy seguro de entender completamente cómo el estado del gateway se propaga entre perfiles en algunos casos particulares, por ejemplo, cuando dos perfiles registran el mismo servidor MCP con diferentes ámbitos. Eso es algo que quiero investigar más. Mi suposición actual es que el registro es por perfil, pero el grupo de conexiones subyacente puede no serlo, lo que importaría si estás haciendo algo con estado en el nivel del gateway. No lo he confirmado. Dejo la pregunta abierta.

Crear y gestionar múltiples perfiles

Cuando intenté esto por primera vez, lo complicé demasiado. El flujo básico resultó ser más simple de lo que esperaba, pero las convenciones que construyes alrededor importan más que los propios comandos.

Nombres, comandos alias, cambio, exportación e importación

La convención en la que me he establecido —y esto es solo mi hábito, no una regla— es <context>-<role>: personal-research, work-coding, client-acme-prod. Nombrar importa más de lo que pensaba inicialmente. Cuando tienes seis perfiles y estás cansado, un perfil llamado test2 es un incidente futuro esperando ocurrir. Ya cometí ese error. El día que accidentalmente ejecutes un comando destructivo en test2 pensando que era el sandbox, es el día en que comienzas a tomar en serio el nombramiento de perfiles.

Cambiar de perfil debería ser un solo comando. Exportar e importar te permiten mover perfiles entre máquinas, lo cual probé una vez en un portátil nuevo. El paquete de exportación incluye la configuración pero excluye los secretos en bruto —tienes que reinyectarlos en el extremo receptor. Creo que ese es el valor predeterminado correcto, aunque también es la parte que más confunde a la gente. Algunas personas con las que he hablado esperaban que los secretos migraran con el perfil y se sorprendieron cuando su agente importado no pudo autenticarse.

Un pequeño detalle que noté: aliasar los comandos comunes de cambio de perfil a nivel del shell hizo esto mucho menos doloroso. Si estás cambiando tres o cuatro veces al día, la fricción se acumula —y la fricción es lo que hace que la gente omita el cambio y reutilice el perfil equivocado.

Casos de uso reales para los perfiles

Aquí es donde tuve que detenerme y pensar sobre quién realmente necesita esto. No todos los que manejan un agente necesitan perfiles. Pero si alguna de estas descripciones coincide contigo, creo que sí los necesitas.

Personal vs trabajo, programación vs investigación, producción vs pruebas

El caso más claro es ​personal vs trabajo​. Memoria diferente, habilidades diferentes, credenciales diferentes. No quieres que tu agente de proyecto de fin de semana tenga acceso a la base de datos de tu empleador, y no quieres que tu agente de trabajo recuerde tu lista de compras. La separación mental también es real: cambiar de perfil es un pequeño ritual que me ayuda a cambiar de contexto, no solo de configuración.

El segundo caso es ​programación vs investigación​. Un agente de programación se beneficia de permisos de herramientas agresivos — escritura de archivos, ejecución de shell, acceso a repositorios. Un agente de investigación no necesita nada de eso, y otorgarle esos permisos solo aumenta la superficie de ataque sin necesidad. Aquí es donde el principio de menor privilegio se vuelve práctico en lugar de abstracto: cada perfil recibe solo los permisos que realmente necesita, y nada más. Solía otorgar permisos de manera amplia porque era más fácil. Ya no lo hago.

El tercer caso es ​producción vs pruebas​, el cual la mayoría subestima hasta que algo sale mal. Un agente de pruebas nunca debería estar a un solo golpe de tecla de las credenciales de producción. La guía de Microsoft sobre gobernanza de agentes lo enmarca como aislamiento de datos a nivel de proyecto para prevenir la contaminación cruzada entre contextos de agentes. Los perfiles son cómo eso se vuelve aplicable en una sola estación de trabajo, sin tener que crear máquinas virtuales o contenedores separados para lo que debería ser una separación ligera.

Recientemente comenzó a aparecer un cuarto caso que no esperaba: ​estable vs experimental​. Un perfil estable con habilidades probadas y configuraciones conocidas, y un perfil experimental donde pruebo nuevas herramientas, variaciones de prompts o cambios de modelo. El perfil experimental falla regularmente. El estable no, porque nada tiene permitido tocarlo casualmente. Esta separación me ha ahorrado más tiempo de depuración de lo que esperaba.

…no es exactamente lo que esperaba, pero cuanto más trabajo con perfiles, más siento que son la unidad básica de operación segura de un agente, no un extra opcional.

Errores comunes con los perfiles

He cometido la mayoría de estos. Algunos los noté rápidamente. Otros me tomaron semanas.

Compartir credenciales entre perfiles. Este es el más común y el más peligroso. Las personas crean un perfil separado pero reutilizan la misma clave API en todos ellos. Los perfiles están aislados; las credenciales no lo están. Si un perfil se ve comprometido, todos los perfiles que compartan la clave también se verán comprometidos. El tutorial de seguridad de agentes de IA de IBM es directo al respecto: los permisos excesivos y las credenciales compartidas son un modo principal de falla en los sistemas de agentes. La solución no es llamativa: claves separadas por perfil, limitadas al mínimo que cada perfil necesita.

Expectativas incorrectas sobre la continuidad de la sesión. Cambiar de perfil termina la sesión activa. Algunas personas asumen que las sesiones las siguen a través de perfiles. No es así. Si necesitas continuidad, quédate en un perfil. Si necesitas aislamiento, cambia de perfil y acepta que estás comenzando un nuevo contexto de conversación. He visto personas luchar con esta suposición durante semanas antes de internalizarla.

Configuraciones de herramientas mezcladas. Cargar la misma habilidad en varios perfiles con diferentes alcances. La habilidad se comporta de manera diferente según el perfil en el que se esté ejecutando, lo que hace que la depuración sea realmente confusa. Sugeriría tratar las habilidades como limitadas a un perfil desde el principio, incluso si eso significa algo de duplicación. La duplicación es barata. Depurar una habilidad que se comporta de manera inconsistente entre perfiles no lo es.

Puede que esté leyendo demasiado en este último punto, pero ya me ha ocurrido dos veces, así que lo señalo.

Cómo los perfiles cambian las decisiones de implementación y gobernanza

Esta es la parte que todavía estoy resolviendo, y quiero ser honesto en que mi comprensión aquí está incompleta.

Cuando se toman en serio los perfiles, dejan de ser una herramienta de organización personal y se convierten en un primitivo de gobernanza. Un equipo puede requerir que los perfiles de agentes en producción usen configuraciones específicas de gateway. Un auditor puede preguntar qué perfil generó una acción determinada y obtener una respuesta real en lugar de un encogimiento de hombros. Esto se alinea con cómo el Marco de Gestión de Riesgos de IA del NIST trata la responsabilidad: cada acción debe ser rastreable a un alcance definido de autoridad. Los perfiles te dan ese alcance sin tener que inventarlo.

La actualización de NIST 2025 sobre IA agentiva va más allá. El borrador del Perfil de IA para Ciberseguridad trata a los despliegues de agente único y multiagente como categorías de riesgo distintas, cada una con sus propios requisitos de aislamiento. Los perfiles son una manera concreta de cumplir esos requisitos sin necesidad de implementar infraestructura separada para cada agente. Para equipos pequeños, eso importa: la mayoría de las personas no tienen el presupuesto ni el tiempo para ejecutar entornos aislados por agente, pero sí pueden ejecutar perfiles aislados por agente.

No estoy listo para hacer afirmaciones fuertes sobre lo que esto significa para configuraciones autoalojadas o despliegues de equipos más grandes. Solo lo he probado a pequeña escala, y no lo he ejecutado el tiempo suficiente para ver qué falla con mayor carga. Pero la dirección parece correcta: la identidad y el aislamiento deberían vivir a nivel del agente, no a nivel de la máquina. Cuando eso es cierto, los agentes se convierten en bloques de construcción componibles en lugar de procesos monolíticos que necesitan ser confiables en su totalidad.

Preguntas frecuentes

¿Los perfiles comparten algún estado en absoluto?

El límite del perfil está pensado para ser firme. El único lugar donde verás solapamiento es en el binario de Hermes subyacente en sí: misma versión, mismos valores predeterminados globales, pero todo lo que tiene estado está limitado al perfil, según lo que he observado.

¿Puedo ejecutar dos perfiles simultáneamente?

Sí, en sesiones de terminal separadas. No interfieren entre sí, según lo que he visto. He ejecutado tres al mismo tiempo por períodos cortos sin problemas evidentes.

¿Cuál es la opción más segura por defecto para un nuevo perfil?

Permisos mínimos, sin credenciales de producción, sin claves de API compartidas. Agrega capacidades solo cuando realmente las necesites. Este es un consejo aburrido, pero es el consejo que desearía haber seguido antes.

¿Cada proyecto debería tener su propio perfil?

…No lo sé. Para experimentos pequeños, probablemente no. Para cualquier cosa que toque producción, datos reales de clientes o credenciales sensibles, sí. El costo de crear un perfil es bajo. El costo de no tener uno cuando lo necesitabas a veces es muy alto. Ahí lo dejaré por ahora. Seguiré observando cómo se comporta esto a medida que agrego más perfiles. Algo está ocurriendo en cómo está comenzando a madurar la infraestructura de agentes, y todavía no veo completamente su forma.

Publicaciones anteriores:

👉 Si aún no tienes claro cómo se comporta la memoria de Hermes entre contextos, lee: Límites y compensaciones de la memoria de Hermes explicados

👉 Para un análisis más profundo sobre cómo evitar riesgos ocultos al extender agentes con herramientas externas: Cómo usar MCP de forma segura con Hermes Agent

👉 Si estás ejecutando múltiples agentes en diferentes entornos, este desglose ayuda:Hermes Agent vs EvoMap: Diferencias en la Arquitectura de Memoria

👉 Para entender cómo las capacidades del agente difieren del conocimiento almacenado (crítico para el diseño de perfiles):Habilidades del Agente vs Activos de GEP: Lo que Realmente Persiste

👉 Y si estás pensando en la evolución a largo plazo del agente más allá de los perfiles:EvoSkills: Habilidades de Agentes Autoevolutivas en la Práctica