Ejecutas un único gateway de Discord en un servidor compartido y la máquina tiene cinco perfiles de Hermes instalados: un default de uso general, un perfil restringido para los niños y dos perfiles de desarrollo. Arrancas el gateway y este levanta de golpe los adapters y los cron jobs de todos los perfiles. Peor aún: un mensaje que debía enrutarse al perfil restringido llega mientras ese perfil no está disponible — y el gateway lo ejecuta tranquilamente bajo default. Para un perfil restringido eso no es una degradación elegante; es cruzar la frontera de capacidades. El PR #83400, fusionado el 11 de agosto de 2026, cierra exactamente esta brecha: gateway.multiplex_profile_allowlist te permite declarar a qué perfiles sirve tu gateway compartido, y el enrutamiento que no acierta con el conjunto servido ahora fail closed — el mensaje se rechaza, nunca se degrada en silencio.

Una clave de configuración para definir el conjunto servido

Añade la allowlist a config.yaml:

gateway:
  multiplex_profiles: true
  multiplex_profile_allowlist:
    - worker
    - guest

Con esas cuatro líneas, este gateway solo arranca y sirve default, worker y guest — cualquier otro perfil instalado en el host no se arranca ni se expone a través de este gateway.

La semántica exacta de la allowlist

Merece la pena repasar las reglas (documentación oficial de multi-profile-gateways.md) una a una, porque todos los casos límite están cubiertos:

• default siempre se sirve — nunca necesitas listarlo;
• Sin definir = comportamiento histórico: sirve a todos los perfiles nombrados válidos del host;
• Lista vacía [] = sirve solo a default;
• Los nombres se normalizan y deduplican; las entradas inválidas o los perfiles que no están instalados se omiten con un aviso; un valor malformado que no sea una lista falla de forma segura a solo-default, no a un crash;
• El conjunto servido también controla los prefijos de API y webhooks /p/<profile>/, el estado en runtime, la elegibilidad de profile_routes y a qué perfiles hace tick el scheduler de cron dentro del proceso;
• Un perfil nombrado fuera de la allowlist no lo arranca este gateway — pero puede seguir ejecutando su propio gateway independiente. «No servido por el gateway compartido» no significa «inutilizable».

Fail closed: rechaza, no degrades en silencio

Esta es la parte del cambio relevante para la seguridad. Antes, el riesgo era: profile_routes enrutaba explícitamente un canal a un perfil restringido, pero si ese perfil no estaba disponible (no instalado, roto, fuera del conjunto servido), el tráfico volvía silenciosamente a default. La regla ahora está invertida:

• Una ruta explícita coincide, pero su perfil de destino no está instalado o está fuera de la allowlist → el gateway rechaza el mensaje y registra la ruta y el perfil de destino — nunca ejecuta default para él;
• El tráfico que no coincide con ninguna ruta conserva el comportamiento histórico (va a default);
• profile_routes solo se aplica cuando multiplex_profiles: true.

Escenario real: un perfil restringido en un gateway compartido

El caso de uso clásico es un bot compartido en familia: un bot de Discord donde los canales normales corren en default y el canal de los niños corre en un perfil restringido. Se configura en dos capas:

1. Capa de gateway: multiplex_profile_allowlist lista solo default + kids-safe, y profile_routes envía el canal de los niños a kids-safe;
2. Capa de perfil: el hardening vive en el config.yaml propio del perfil restringido — habilitando solo el conjunto de herramientas que necesita, sin heredar las credenciales de default, etc. Los perfiles son hogares de configuración aislados, así que ese aislamiento se hace en esta capa de todos modos.

Un límite que conviene dejar claro: la documentación oficial recuerda que el enrutamiento de perfiles más una allowlist no es un sandbox de seguridad completo. Cuando necesitas una frontera dura a nivel de sistema operativo (por ejemplo, código que debe ejecutarse en un entorno aislado), usa procesos separados o aislamiento por contenedores — no esperes que el enrutamiento a nivel de configuración lo respalde.

La conclusión

multiplex_profile_allowlist es un cambio pequeño que resuelve un dolor real de los gateways compartidos: tenías perfiles instalados para distintos fines, pero el gateway servía a todos indiscriminadamente — y degradaba en silencio cuando una ruta fallaba. Ahora puedes declarar exactamente a quién sirve este gateway y convertir esa degradación en un rechazo. Para el concepto completo de multiinstancia de perfiles, consulta nuestra guía de multiperfil; el enrutamiento de perfiles en una configuración de Feishu se cubre en ese artículo; las superficies de comandos viven en las páginas de referencia de hermes-gateway y hermes-profile.