Pular para o conteúdo
← artigos
atualizado Hermes AgentAI Agent SecurityOpenClawSelf-Hosted AIAgent Runtimes

O Hermes Agent é seguro? O agente nunca deve guardar o token

Um agente sempre ativo com shell é um colega com root. O que realmente deu errado rodando o Hermes Agent em produção, os controles que pegaram o problema, como ele se compara ao OpenClaw e um checklist para antes de dar shell a qualquer agente.

Um agente sempre ativo com shell é um colega com acesso de root: nunca dorme, lê tudo que você apontar para ele e vai imprimir um segredo no log sem pensar duas vezes, se nada impedir. Segurança para esse colega é basicamente duas perguntas: o que ele consegue alcançar, e o que ele consegue imprimir. O modelo por trás disso importa muito menos que as duas coisas.

Eu rodo o Hermes Agent em produção, na minha própria VPS. Todo incidente abaixo aconteceu de verdade comigo. Todo controle abaixo eu confirmei no código-fonte, não na página de marketing.

O Hermes Agent é seguro?

Ele tem controles de verdade, e o próprio código deixa claro quais deles não são uma barreira de segurança. Prompts de aprovação travam comandos arriscados em qualquer superfície de mensagem, um arquivo de parada de emergência consegue parar todo trabalho novo, e um proxy de saída mantém as credenciais fora do sandbox do Docker. Nada disso torna o Hermes seguro por padrão. Torna o Hermes seguro quando configurado corretamente, o que é uma afirmação diferente, e é na diferença entre as duas que todo incidente abaixo aconteceu.

Trate-o pelo que ele é: um colega com shell, não um brinquedo em sandbox. Dê a ele a própria máquina ou container, credenciais com escopo reduzido, e nunca uma chave que você não consegue rotacionar.

O que realmente deu errado quando rodei o Hermes Agent

Nada disso é teórico. Quatro incidentes separados, quatro lições separadas, rodando Hermes e Paperclip em produção desde junho.

Incidente, causa, correção

Três dos quatro são meus para corrigir. A pegadinha do WebSocket é um comportamento do navegador que nenhum dos dois runtimes controla.
O que aconteceuCausa raizCorreção
Tokens de API apareceram num log de sessãoUm dump do config.yaml dentro de uma sessão do Hermes imprimiu eles direto no logRotacionei os tokens
O dashboard web travou em conectandoO Chrome não reenvia o basic auth num upgrade de WebSocket. A mesma pegadinha atingiu a própria UI do OpenClaw.Um segundo router do Traefik com token, separado do basic auth
Uma execução falhou com permission denied no agent.logMeus próprios diagnósticos, rodados como root dentro do container, deixaram arquivos de root dentro de .hermeschown de volta para o usuário do serviço
Um token de provedor foi parar num serviço que nunca usou eleMinha ferramenta de auth propaga tokens para todo serviço gerenciado, mas cada app decide por conta própria qual env var lêTratar propagação e consumo como duas perguntas separadas, não uma só
Três dos quatro são meus para corrigir. A pegadinha do WebSocket é um comportamento do navegador que nenhum dos dois runtimes controla.

O padrão nos quatro: o agente não vazou nada por ser esperto. Uma ferramenta imprimiu o que foi instruída a imprimir, um navegador descartou um header que nunca ia reenviar, um diagnóstico rodou com o usuário errado, e um token chegou numa máquina que não tinha uso para ele. Segurança de agente falha, na maior parte das vezes, no encanamento, não no modelo decidindo se comportar mal.

A lição de segunda ordem da correção do WebSocket merece atenção. A rota alternativa usou um token na query string da URL, ?token=, que já é uma versão menor do mesmo problema: tudo que vai numa URL acaba em access logs, histórico do navegador e headers de referrer. Uma correção para um vazamento pode abrir, sem querer, um vazamento mais estreito. Confira o que você loga antes de subir o patch, não depois.

Os controles de segurança do Hermes Agent, direto do código

Quatro mecanismos fazem o trabalho de verdade, e o próprio código do Hermes deixa claro qual deles é só cosmético.

O que fica entre o agente e o estrago

  1. 1

    Aprovação em toda superfície

    Um comando de terminal arriscado para e pergunta, com o mesmo texto no Telegram, na CLI ou em qualquer outro gateway: "Hermes wants to run a command that needs your OK", junto com o motivo que disparou o alerta e um timeout depois do qual o comando não roda.

  2. 2

    ESTOP, um arquivo sentinela

    hermes pause escreve um arquivo em $HERMES_HOME/ESTOP. Enquanto ele existir, o cron scheduler, o kanban dispatcher e os novos turnos de gateway pulam qualquer trabalho novo. Trabalho já em andamento nunca é interrompido. hermes resume remove o arquivo.

  3. 3

    Um proxy de saída para o backend Docker

    O próprio código do Hermes chama isso de um 'host-side credential firewall'. Ele monta os argumentos de mount, env e host que fazem um sandbox passar por ele, e protege exatamente as superfícies de configuração (env repassado, args extras) que, de outra forma, poderiam enfraquecê-lo ou contorná-lo.

  4. 4

    Mascaramento da saída

    Um módulo dedicado remove strings sensíveis de tudo que o agente imprime, no prompt de aprovação, na ferramenta de terminal e na entrega para um gateway. Isso reduz o raio de estrago de um vazamento. Não evita um vazamento.

Guardas de escrita em arquivo também existem. A docstring do próprio Hermes para elas é a citação abaixo.

Every guard here is defense-in-depth, NOT a security boundary: the terminal tool runs as the same OS user and can read/write anything.

Essa linha é do agent/file_safety.py, no código-fonte do Hermes, não de um post de blog sobre o Hermes. É a frase mais honesta de todo o codebase. Uma guarda de arquivo para um modelo que respeita um erro de ferramenta. Não faz nada contra um modelo que recorre ao bash em vez disso, porque a ferramenta de terminal é o mesmo usuário do sistema operacional de qualquer jeito.

Mais dois controles estruturais importam aqui. Os profiles do Hermes dão a você “múltiplas instâncias isoladas do Hermes”, cada uma com seu próprio HERMES_HOME, config e banco de estado, o que é como você evita que um agente comprometido leia a memória ou as credenciais de outro agente na mesma máquina. E o backend de execução escolhido (local por padrão, ou Docker, SSH, Singularity, Modal, Daytona ou Vercel Sandbox) é o controle real de raio de estrago: um agente que roda os comandos dele num sandbox descartável perde muito menos do que um que roda tudo na própria máquina onde vive.

Credenciais atrás de um proxy, nunca na mão do agente

O agente nunca deve guardar um token que ele conseguiria imprimir. O padrão que funciona é um proxy que guarda a credencial, com uma config que só aponta o agente para o proxy.

O meu próprio mcp-pooler faz exatamente isso para tráfego MCP (o protocolo que deixa um agente puxar dados e chamar ferramentas em serviços como Slack, Jira ou um repositório Git). Ele guarda um único bearer token upstream, configurado uma vez como variável de ambiente no próprio pooler, e cada agente de vida curta na ponta conversa com o endpoint do pooler, que não exige credencial nenhuma. O agente não consegue vazar o token upstream porque o agente nunca recebe ele. A troca está explícita no próprio README do pooler: esse endpoint na ponta não tem autenticação própria e deve rodar numa rede privada, nunca exposto à internet. Um proxy que esconde uma credencial não é motivo para pular o isolamento de rede.

A mesma lógica vale para toda fonte que um agente lê, não só para o gateway na frente delas. Limite as fontes MCP do Slack e do Google Workspace a somente leitura sempre que a lista de ferramentas permitir, e trate o cliente OAuth ou o bot token de cada uma como algo que você emitiu e pode revogar, nunca algo emprestado de outro sistema. Uma fonte Git é a mesma pergunta de novo: um token com escopo para um repositório só vaza muito menos do que um com escopo para a conta inteira.

O OpenClaw é seguro? Mesma pergunta, defaults diferentes

OpenClaw e Hermes partem do mesmo padrão: comandos rodam no host. O Hermes vem com o backend local selecionado, e o OpenClaw roda ferramentas no host a menos que você ative o sandboxing. A própria documentação do OpenClaw é direta sobre essa escolha, oferecendo Docker, Podman, SSH, OpenShell ou Crabbox como sandboxes opcionais, e afirma sem rodeios que até o sandbox “is not a perfect security boundary”. O heartbeat dele desperta o agente por conta própria a cada 30 minutos por padrão, o que é um recurso para um assistente pessoal e, ao mesmo tempo, uma janela de ataque mais larga para qualquer coisa que você não pretendia dar a ele.

A segurança do OpenClaw, assim como a do Hermes Agent, é uma decisão de configuração, não uma propriedade que qualquer um dos dois projetos entrega pronta. Aprovação de execução existe nos dois. Nenhum dos dois usa sandbox por padrão; os dois deixam você escolher um sandbox na hora de configurar. Nenhum desses fatos diz se uma instalação específica é segura. As perguntas no checklist abaixo dizem.

Checklist de segurança para agentes de IA: antes de dar shell a um agente

O GenAI Security Project da OWASP batiza o padrão direto: LLM06:2025, Excessive Agency, o risco de um agente receber mais permissão, mais ferramentas ou mais autonomia do que a tarefa na frente dele precisa. Todo incidente deste artigo é uma variação desse mesmo risco, não uma falha exclusiva de um runtime.

Antes de dar shell a um agente

  • Obrigatório:
    Ele roda como o próprio usuário, no próprio sandbox ou container.Guardas de escrita em arquivo não são barreira de segurança. O usuário do sistema que a ferramenta usa é o que importa de verdade.
  • Obrigatório:
    Toda credencial que ele toca está atrás de um proxy ou é um token com escopo que você mesmo emitiu.O agente nunca deve guardar um segredo que poderia imprimir. Se precisar guardar um, que seja o menor segredo possível que funcione.
  • Obrigatório:
    Ações arriscadas param e perguntam, na superfície que você de fato lê.Um prompt de aprovação que ninguém vê não é um gate de aprovação. Alinhe a superfície com onde você está.
  • Obrigatório:
    Você tem um kill switch que para trabalho novo sem matar o que já está em andamento.O arquivo ESTOP do Hermes é um jeito de fazer isso. Conheça o seu antes de precisar dele.
  • Obrigatório:
    Publicar, enviar e deletar passam por um humano, por design, não por acidente.Meus próprios agentes nunca ganharam acesso de escrita aos canais onde eu publico. Eles produzem. Eu publico.
  • Obrigatório:
    Você sabe o que ele loga, e você já leu um arquivo de log, não só o relato do próprio agente sobre o que aconteceu.Um dump de config, uma query string de URL, um stack trace: todos esses lugares escondem um segredo à vista de todos.
Cada item responde uma das duas perguntas: o que ele alcança, e o que ele imprime.

Segurança do Hermes Agent, respostas rápidas

O Hermes Agent é seguro?

Ele vem com controles de verdade: prompts de aprovação em toda superfície de mensagem, um arquivo ESTOP que para trabalho novo, e um proxy de saída que mantém as credenciais fora do sandbox do Docker. O próprio código afirma que as guardas de escrita em arquivo são defesa em profundidade, não uma barreira de segurança.

Se uma instalação específica é segura depende do backend de execução, das credenciais que ela alcança e se ações arriscadas exigem um humano. Isso são escolhas de configuração, não defaults.

Contra o que a segurança do Hermes Agent realmente protege?

Principalmente falhas de encanamento, não o modelo decidindo se comportar mal: uma ferramenta imprimindo um segredo que foi instruída a imprimir, um diagnóstico rodado com o usuário errado, um token chegando num serviço que nunca precisou dele. Todo incidente que peguei em produção foi um desses, não o modelo agindo por conta própria.

O OpenClaw é seguro?

Assim como o Hermes, o OpenClaw roda comandos no host por padrão e deixa o sandboxing como opcional, entre Docker, Podman, SSH, OpenShell ou Crabbox. A própria documentação dele diz que o sandbox não é uma barreira de segurança perfeita. É um default honesto para você conhecer, não um veredito sobre uma instalação específica.

Como o Hermes Agent mantém as credenciais longe do agente?

Através de um padrão de proxy: um componente como o mcp-pooler guarda o bearer token upstream, e o agente só conversa com o endpoint do próprio proxy, que não carrega credencial nenhuma. Combine isso com escopos de somente leitura em fontes como Slack e Google Workspace sempre que a lista de ferramentas permitir.

O que é segurança de agentes de IA, na prática?

Duas perguntas, repetidas para cada ferramenta e cada credencial: o que esse agente alcança, e o que ele imprime. O GenAI Security Project da OWASP chama o modo de falha geral de Excessive Agency. Todo o resto, de sandboxing a prompts de aprovação a mascaramento de saída, é uma resposta específica para uma dessas duas perguntas.