Você roda um gateway do Discord num servidor compartilhado e a máquina tem cinco perfis do Hermes instalados: um default de uso geral, um perfil restrito para as crianças, dois perfis de desenvolvedor. Ao iniciar o gateway, ele sobe os adapters e cron jobs de todos os perfis de uma vez. Pior: uma mensagem que deveria ser roteada para o perfil restrito chega enquanto esse perfil está indisponível — e o gateway a executa silenciosamente sob o default. Para um perfil restrito, isso não é degradação graciosa; é cruzar a fronteira de capacidades. O PR #83400, mesclado em 11 de agosto de 2026, fecha exatamente essa lacuna: gateway.multiplex_profile_allowlist permite declarar quais perfis o seu gateway compartilhado atende, e o roteamento que erra o conjunto servido agora falha fechado (fail closed) — a mensagem é rejeitada, nunca rebaixada silenciosamente.

Uma chave de configuração para definir o conjunto servido

Adicione a allowlist ao config.yaml:

gateway:
  multiplex_profiles: true
  multiplex_profile_allowlist:
    - worker
    - guest

Com essas quatro linhas, este gateway inicia e atende apenas default, worker e guest — qualquer outro perfil instalado no host não é iniciado nem exposto por este gateway.

A semântica exata da allowlist

As regras (documentação oficial multi-profile-gateways.md) valem a pena ser percorridas uma a uma, porque todos os casos extremos são tratados:

• default é sempre servido — você nunca precisa listá-lo;
• Sem valor = comportamento histórico: atender todo perfil nomeado válido no host;
• Lista vazia [] = atender apenas default;
• Os nomes são normalizados e deduplicados; entradas inválidas ou perfis não instalados são ignorados com um aviso; um valor não-lista malformado falha com segurança para somente-default, não em um crash;
• O conjunto servido também controla os prefixos de API e webhook /p/<profile>/, o status em runtime, a elegibilidade de profile_routes e quais perfis o scheduler de cron em processo executa;
• Um perfil nomeado fora da allowlist não é iniciado por este gateway — mas ele ainda pode rodar seu próprio gateway standalone. “Não servido pelo gateway compartilhado” não significa “inutilizável”.

Fail closed: rejeite, não rebaixe silenciosamente

Esta é a parte da mudança relevante para segurança. Antes, o risco era: profile_routes roteava explicitamente um canal para um perfil restrito, mas se esse perfil estivesse indisponível (não instalado, quebrado, fora do conjunto servido), o tráfego caía silenciosamente no default. A regra agora é invertida:

• Um roteamento explícito corresponde, mas seu perfil de destino está não instalado ou fora da allowlist → o gateway rejeita a mensagem e registra a rota e o perfil de destino em log — ele nunca executa o default para ela;
• Tráfego que não corresponde a nenhuma rota mantém o comportamento histórico (vai para o default);
• profile_routes só se aplica quando multiplex_profiles: true.

Cenário real: um perfil restrito em um gateway compartilhado

O caso de uso clássico é um bot compartilhado pela família: um bot do Discord em que os canais normais rodam no default e o canal das crianças roda num perfil restrito. Configure em duas camadas:

1. Camada do gateway: multiplex_profile_allowlist lista apenas default + kids-safe, e profile_routes envia o canal das crianças para kids-safe;
2. Camada do perfil: o endurecimento vive no próprio config.yaml do perfil restrito — habilitando apenas o conjunto de ferramentas de que ele precisa, sem herdar as credenciais do default, e assim por diante. Perfis são casas de configuração isoladas, então esse isolamento é feito nessa camada de qualquer forma.

Uma fronteira que vale deixar clara: a documentação oficial lembra que roteamento de perfil mais allowlist não é uma sandbox de segurança completa. Quando você precisar de uma fronteira rígida em nível de sistema operacional (digamos, código que precisa rodar em um ambiente isolado), use processos separados ou isolamento de contêiner — não espere que o roteamento em nível de configuração sirva de rede de segurança.

A conclusão

multiplex_profile_allowlist é uma mudança pequena que resolve uma dor real de gateways compartilhados: você tem perfis instalados para propósitos diferentes, mas o gateway costumava atendê-los a todos indiscriminadamente — e degradar silenciosamente quando uma rota errava. Agora você pode declarar exatamente a quem este gateway atende e transformar essa degradação em rejeição. Para o conceito completo de multi-instância de perfis, veja nosso guia multi-perfil; o roteamento de perfis em um setup do Feishu é coberto neste artigo; as superfícies de comandos vivem nas páginas de referência hermes-gateway e hermes-profile.