Resumo
O Hermes Agent para suporte de TI interno se encaixa melhor do que o Hermes para atendimento ao cliente, porque seus usuários são colegas que você pode colocar em uma lista de permitidos. Ele brilha como ajudante pessoal do administrador de TI: verificações de saúde via cron, triagem de alertas do Datadog ou Grafana e comandos reais em um servidor por SSH.
O problema aparece quando você o abre para a empresa toda. O acesso é concedido um ID de usuário por vez, a divisão entre administrador e usuário só limita comandos com barra, e a aprovação de um comando arriscado volta para o funcionário que perguntou, não para a TI. A solução são dois perfis: um perfil "it-desk" somente leitura para todos, com o terminal desligado, e um perfil "ops" que só os administradores alcançam.
Se você prefere dispensar o servidor, a eesel responde às dúvidas de TI dos funcionários no Slack a partir do seu Confluence, atua como primeiro respondente no Jira Service Management e só deixa os seus administradores de TI aprovarem ações.
Por que olhei o Hermes para TI interno
Eu construo agentes de IA na eesel, e ultimamente a pergunta "não dá para usar o Hermes?" vem mais de equipes de TI do que de equipes de suporte. Faz sentido. Uma equipe de TI já roda servidores, vive no Slack ou no Teams e geralmente há um engenheiro que não se importa com um arquivo YAML.
Estou do outro lado disso há algum tempo. A eesel atua como primeiro respondente na central de TI interna da InDebted, onde uma equipe de TI de 5 a 10 pessoas atendia pedidos de mais de 250 funcionários em cinco mercados. Ela desviou 15% dos problemas e continuou treinando com pedidos passados rumo a uma meta de 55%. O Head of IT deles disse sem rodeios:
"We use it to be the first responder to our Helpdesk tickets in Jira. It essentially acts just like an agent would."
Jason Loyola, Head of IT, InDebted
Esse trabalho me ensinou onde está de fato o risco em TI interna, e não são os desconhecidos. É o colega prestativo que pede ao bot para "só reiniciar". Então li a documentação do Hermes de ponta a ponta com uma pergunta na cabeça: o que acontece quando 200 funcionários podem falar com um agente que tem um terminal?
O que o Hermes Agent oferece a uma equipe de TI
O Hermes Agent é o agente de código aberto e auto-hospedado da Nous Research. Tem licença MIT, 251,503 estrelas no GitHub e a versão mais recente é a v0.21.5, publicada em 24 de setembro de 2026.
Meu review do Hermes Agent cobre o produto inteiro, e meu apanhado de agentes de IA de código aberto o coloca ao lado dos pares. Para trabalho de TI, quatro peças importam.
- Sete backends de terminal. O Hermes pode executar comandos localmente, no Docker, por SSH ou no Modal, Daytona, Vercel Sandbox ou Singularity (Configuration). O backend SSH mantém um shell persistente em um servidor remoto, e a documentação o chama de "Recommended for security" porque o agente não consegue modificar o próprio código (Tools).
- Um gateway de mensagens. Slack, Microsoft Teams, Google Chat, e-mail e mais de 20 outros canais (Messaging Gateway), que é como a maioria das equipes já opera o ITSM no Slack.
- Cron e webhooks. Tarefas agendadas e webhooks de entrada de ferramentas como GitHub, GitLab e Jira, com verificação de assinatura HMAC (Webhooks).
- Servidores MCP. Um catálogo curado de
65servidores revisados, desativados por padrão (MCP catalog). Se MCP é novidade para você, minha explicação sobre o servidor MCP de agente de IA cobre o básico.
Então é um kit de ferramentas de verdade para uma equipe de TI. A questão em aberto é quem pode usá-lo.
Dois trabalhos, um agente
A maioria dos planos de "Hermes para TI" que vejo mistura dois trabalhos muito diferentes.
O trabalho 1 é o de ajudante do administrador de TI. Dois ou três administradores mandam mensagem direta ao agente, que executa verificações em servidores, faz triagem de alertas e relata o que encontrou. Quem aprova um comando arriscado aqui é um administrador que o entende.
O trabalho 2 é a porta de entrada dos funcionários. Todos na empresa perguntam em #it-help "por que minha VPN caiu?". É o trabalho que as pessoas imaginam quando falam de IA para help desks de TI internos. O agente é o mesmo e as ferramentas também, mas o risco é muito diferente.
Todo exemplo de TI na documentação do Hermes é do trabalho 1. Pesquisei em todo o dump da documentação por "helpdesk", "IT support" ou "employee" e tive zero resultados. O que os exemplos mostram é um operador cuidando das próprias operações, coisas como triagem de alertas para um canal de plantão, verificações de uptime e alertas de disco.
Trabalho 1: Hermes como ajudante do administrador de TI (isso funciona)
Aqui o Hermes ganha seu lugar. Alguns dos padrões documentados se aplicam a uma equipe de TI quase sem mudanças:
- Verificações de saúde do servidor agendadas. O guia Team Telegram Assistant inclui um prompt que verifica a cada 6 horas o uso de disco com
df -h, a memória comfree -he o status dos contêineres comdocker ps, entregue em um canal da equipe. - Cron só de script, sem chamada ao modelo.
hermes cron create "*/15 * * * *" --no-agent --script disk-alert.sh --deliver telegramroda um script simples e envia a saída (Script-only cron). É barato, e você não gasta tokens em uma verificação de disco. - Triagem de alertas a partir do monitoramento. A página Automation Blueprints tem um webhook de triagem de alertas que pede uma recomendação de escalonamento de P1 a P4 e termina com "This goes to the on-call channel."
- Falhas silenciosas. "A recurring job that keeps failing with the same error alerts you once, not on every run" (Cron). Se você já silenciou um canal de alertas barulhento, vai apreciar isso.
Do lado das ferramentas, o catálogo já traz o stack de monitoramento que a maioria das equipes de TI usa: Datadog, Grafana, Sentry, Better Stack e Cloudflare, todos via OAuth. Combine isso com o backend SSH e você tem um agente que lê um alerta, verifica a máquina e depois diz o que acha que está errado.
Dois padrões de segurança também ajudam. Tarefas de cron negam comandos perigosos por padrão (cron_mode: deny), então uma tarefa agendada não consegue dar systemctl restart em nada a menos que você mude isso (Security). As verificações de comandos perigosos também rodam nos backends local e ssh, e é exatamente aí que o trabalho de TI acontece.
É a configuração que os usuários de homelab descrevem. Um comentarista do Hacker News roda exatamente assim, com uma etapa de aprovação e um caminho de volta:
"I use Hermes at home. [...] it's a sysadmin for my homelab. It has a read-only mcp server to check the k8s status and has it's own ssh access to fix stuff after I approve it per session. It's magical. Each morning I get a small update whether the backup ran, if pods are stuck or behaving weirdly etc... Since the entire homelab is GitOps I can always reverse a change made by the agent."
Repare em quem aprova ali: a mesma pessoa que é dona dos servidores. Se você é uma equipe de TI pequena com um engenheiro que curte esse tipo de coisa, o trabalho 1 é um bom uso para uma ferramenta gratuita.
Trabalho 2: Hermes como porta de entrada dos funcionários (onde complica)
Quando você abre o mesmo agente para todos, quatro coisas na documentação passam a importar. Nenhuma é um bug, deixo claro. O Hermes foi projetado como agente de operador, e essas são as emendas por onde esse projeto aparece.
1. O acesso é concedido um ID por vez
Toda lista de permitidos de chat é uma lista de IDs individuais: IDs de membro do Slack, IDs de objeto do Azure AD no Teams, endereços de e-mail no Google Chat (Environment variables). Não encontrei um curinga de domínio como *@company.com, e também não há uma configuração para todo o tenant ou workspace.
Os únicos botões de "todos", como SLACK_ALLOW_ALL_USERS e TEAMS_ALLOW_ALL_USERS, aparecem como "(dev only)" na referência. Acesso por grupo existe, mas só para funções do Discord. O outro caminho é o pareamento por mensagem direta: cada funcionário recebe um código e um administrador o aprova manualmente com hermes pairing approve. Para 200 pessoas, são 200 aprovações, e depois cada nova contratação.
Single sign-on existe, mas só para o painel web, por meio do seu próprio provedor OpenID Connect (Web Dashboard). Também não há SCIM, então quando você desliga alguém no Okta, essa pessoa não é removida do bot.
2. O nível de usuário limita comandos, não ferramentas
O Hermes tem uma divisão entre administrador e usuário, e é tentador supor que ela limite o que usuários comuns podem fazer. O que ela limita, na verdade, são os comandos com barra. Usuários comuns recebem os comandos que você listar em user_allowed_commands, mais /help e /whoami (Slash commands).
O chat comum não é restrito de forma alguma, o que significa que qualquer funcionário permitido pode pedir ao agente qualquer coisa que as ferramentas dele permitam, terminal incluído. Esbarrei na mesma parede do lado do cliente no meu post sobre Hermes para atendimento ao cliente.
3. As aprovações vão para quem perguntou
Se você é líder de TI, este é o que eu sublinharia duas vezes. Quando o Hermes quer executar um comando sinalizado, como systemctl restart, chown -R root ou sed -i em um arquivo em /etc/, ele pede aprovação no mesmo chat: "the agent sends the dangerous command details to the chat and waits for the user to reply" (Security).
A configuração approvals tem mode, timeout, cron_mode e algumas outras opções, mas nenhuma lista de aprovadores e nenhuma forma de enviar o cartão a um administrador de TI ou a um canal separado. No Teams, o cartão tem quatro botões: Allow Once, Allow Session, Always Allow, Deny (Teams). Quem em um chat em grupo pode clicar neles, a documentação não diz.
"Always Allow" também persiste. Comandos aprovados são salvos em config.yaml e "silently approved in all future sessions" (Security). Então basta um clique de um funcionário com pressa, e esse comando fica pré-aprovado para todos.
4. A memória é compartilhada e não há log de auditoria do chat
A memória integrada é um MEMORY.md (2.200 caracteres) e um USER.md (1.375 caracteres) por perfil, carregados em toda sessão que esse perfil executa (Memory). Em um bot de TI compartilhado, isso significa que o que o agente salvar durante o chat de um funcionário vai aparecer na sessão do próximo. A proteção que a documentação oferece é memory.write_approval: true, que deixa em espera cada gravação vinda do chat para um administrador revisar com /memory pending.
Um desenvolvedor que testou uma configuração multiusuário foi além:
"we need a container per user, because, without modifications, if multiple users talk to the same Hermes instance then they can access each other's conversations by asking the agent."
A documentação do Hermes lista o isolamento entre sessões como uma de suas oito camadas de segurança, então trate isso como a experiência de um desenvolvedor, não como uma falha documentada. Ainda assim, é a primeira coisa que eu testaria antes de um canal onde as pessoas perguntam sobre redefinição de senha entrar no ar.
Sobre auditoria, a página de monitoramento do gateway diz que ele não é "analytics, audit logs, or detailed execution traces" (Gateway monitoring). A lista de verificação de segurança manda "check ~/.hermes/logs/". Se sua equipe de TI precisa prestar contas a um auditor de SOC 2, é uma lacuna que você mesmo teria de preencher.
Conectando o Hermes ao Slack, Teams e Google Chat
Cada app de chat tem um formato diferente, e essas diferenças acabam decidindo onde você pode hospedar o gateway.
| Slack | Microsoft Teams | Google Chat | |
|---|---|---|---|
| Conexão | Socket Mode (WebSocket) | Webhook HTTPS público, porta 3978 | Pull do Cloud Pub/Sub |
| Precisa de URL pública | Não | Sim, com certificado TLS real | Não |
| Permissões de administrador necessárias | Instalar o app do Slack | Registro do app pela Teams CLI no seu tenant | Administrador do workspace para publicar o app |
| Lista de permitidos por | ID de membro do Slack | ID de objeto do Azure AD | Endereço de e-mail |
| Em canais | Responde quando @mencionado, em uma thread | Responde quando @mencionado | Responde na thread, uma sessão por thread |
Fontes: Slack, Teams, Google Chat.
O Slack é o mais fácil. O Socket Mode "works behind firewalls, on your laptop, or on a private server." Para TI, as duas configurações que importam são channel_skill_bindings, que carrega uma skill sempre que uma sessão começa em um canal como #it-help (as threads herdam), e allowed_channels, que faz o bot ignorar todos os outros canais mesmo quando @mencionado. Uma peculiaridade que vale conhecer: mensagens diretas estão isentas de allowed_channels.
O Teams dá mais trabalho. "Teams delivers messages by calling a public HTTPS webhook," então o gateway precisa de um endpoint acessível e "Teams rejects self-signed certificates." O registro passa pelo @microsoft/teams.cli da Microsoft ("no Azure portal needed"), que entrega um ID de cliente, um segredo e um ID de tenant. Há um aviso na documentação que eu levaria ao pé da letra: sem TEAMS_ALLOWED_USERS, "anyone who can find or install your bot can interact with it."
Há também um listener do Microsoft Graph (msgraph_webhook), mas hoje ele alimenta principalmente o pipeline de resumos de reuniões do Teams (Graph webhook). Ele não dá ao Hermes acesso ao diretório de usuários nem ao gerenciamento de dispositivos, então não espere que redefina senhas ou consulte o Intune. Meu guia sobre automatizar o suporte no Microsoft Teams olha o caminho do Teams com mais amplitude.
Quais ferramentas de TI o Hermes alcança
O catálogo MCP é onde as equipes de TI costumam se surpreender. Ele é forte em monitoramento, mas fraco em identidade e gestão de serviços.
O Jira Service Management tem uma lacuna escondida. A entrada da Atlassian no catálogo descreve "Jira issues and Confluence pages" e conecta por OAuth. O servidor MCP Rovo da Atlassian tem de fato um grupo de ferramentas de JSM, mas essas quatro ferramentas são de alertas de plantão e escalas, e só aparecem com autenticação por token de API que um administrador da organização precisa habilitar. Pelo caminho OAuth do catálogo, o Hermes vê uma solicitação apenas como um work item comum do Jira. Não há ferramenta para tipos de solicitação, filas, SLAs ou aprovações. Meu post sobre o Claude para JSM percorre o mesmo servidor em detalhe.
O ServiceNow não tem entrada no catálogo. O próprio servidor MCP do ServiceNow está incluído no Now Assist e nos SKUs AI Native, e seu servidor Quickstart traz quatro ferramentas de leitura e resumo. No lado do código aberto, o caminho é um servidor da comunidade que você mesmo configura em mcp_servers. Veja meu guia da integração MCP do ServiceNow.
Identidade e dispositivos são faça você mesmo. Não há entradas de Okta, Entra, Intune, Jamf ou administração do Google Workspace. As skills da comunidade no skills.sh são pequenas: a principal skill de ServiceNow tem 135 instalações, a de Freshservice 118, a de Jamf 4. A exceção é a skill persona-it-admin do próprio Google, com 28,951 instalações (skills.sh). Lembre-se de que qualquer uma delas é código de terceiros que a Nous não revisou.
Se o seu stack é Jira, Confluence e Datadog, o Hermes cobre bastante. Se é ServiceNow, Okta e Intune, planeje tempo real de desenvolvimento. Meu apanhado de IA para gestão de serviços de TI cobre ferramentas feitas para esse segundo stack.
Como configurar o Hermes com segurança para TI interno
O padrão que eu adotaria é dividir os dois trabalhos em dois perfis. No Hermes, um perfil é um agente totalmente separado, com configuração, memória, skills e tokens de bot próprios, e um gateway pode atender vários (Profiles).
Um desenvolvedor no Hacker News chegou à mesma ideia, embora para um risco diferente:
"My solution to the problem, which I am implementing as a Hermes plugin + custom iOS / macOS app, is simple: an airlock architecture. One Hermes profile runs with local FS access and no internet access, inside an Apple container, and one Hermes profile runs with internet access and no FS access, inside an Apple container."
Veja como eu montaria, passo a passo.
1. Rode o gateway em uma máquina própria
A documentação é direta sobre isso: "For maximum security, run the gateway on a separate machine or VM. Set terminal.backend: ssh" (Security). E nunca exponha o painel sem autenticação. A documentação do Docker descreve "the June 2026 MCP-config persistence campaign", em que scanners alcançaram painéis expostos e "drove the agent into planting an SSH-key backdoor" (Docker).
2. Desligue o terminal no perfil dos funcionários
No perfil it-desk, adicione terminal e code_execution a agent.disabled_toolsets. A documentação diz que um toolset listado ali é sempre removido, "even if a platform's saved config still lists it" (Configuration). Sem terminal, o problema de "a aprovação vai para o solicitante" some em grande parte, já que não sobra nada perigoso para aprovar.
Isso deixa o trabalho de ler e encaminhar: responder a partir da sua base de conhecimento interna no Confluence ou Notion, consultar um issue do Jira, abrir um ticket. Isso cobre a maior parte do volume de "como configuro a VPN?", e encaminhar o resto é simples triagem de tickets.
3. Prenda-o a um canal e a uma skill
Defina allowed_channels como #it-help e vincule esse canal a uma skill de TI com channel_skill_bindings. Use também strict_mention, para que em uma thread longa o bot fique quieto até alguém chamá-lo de novo. A documentação cita exatamente esse caso: "a long tech-support thread where the bot helped at the start and you'd rather it stay silent unless explicitly pinged again" (Slack).
4. Deixe as gravações de memória em espera
Defina memory.write_approval: true no perfil it-desk para que o chat de um funcionário não reescreva silenciosamente o que o agente depois diz a todos os outros.
5. Trave o perfil ops
O perfil ops recebe o backend SSH, approvals.mode: manual e uma lista de permitidos só com os seus administradores de TI. Além disso, adicione uma lista approvals.deny para comandos que você nunca quer ver executados pelo chat, e evite "Always Allow" para qualquer coisa que toque /etc/ ou um serviço. A lista de bloqueio rígida recusa rm -rf /, fork bombs e gravações diretas em disco independentemente de tudo, então isso já está coberto.
6. Teste antes de os funcionários verem
O Hermes não ajuda nesta etapa. Não há forma integrada de reproduzir os tickets de TI do mês passado pelo agente e ver o que ele teria respondido. O que você vai precisar é de um canal de testes, uma lista de perguntas reais do passado e alguém que leia cada resposta antes de #it-help entrar no ar.
Quanto o Hermes custa a uma equipe de TI
A licença não custa nada. Rodar é outra história.
| Item de custo | O que você paga | Fonte |
|---|---|---|
| Software Hermes Agent | $0, licença MIT | FAQ |
| Tokens do modelo via Nous Portal | Nível gratuito (só modelos gratuitos), Plus $20/mo por $22 de crédito, Super $100/mo por $110, Ultra $200/mo por $220 | Nous Portal |
| Ferramentas hospedadas (busca, navegador, voz) | Por uso, do mesmo saldo | Nous Portal |
| Servidor ou VM do gateway | Sua conta de nuvem; o Teams ainda precisa de um domínio público e TLS | Teams |
| Atlassian Rovo MCP | Grátis em todos os planos do Atlassian Cloud | Atlassian |
| Tempo de engenharia | Listas de permitidos, perfis, skills, conexão MCP, revisões | Sua equipe |
O Nous Portal também permite conectar um plano elegível do ChatGPT para inferência, com ferramentas e hospedagem cobradas à parte. Meu post sobre alternativas ao Hermes detalha as camadas com mais profundidade.
A última linha é a que nunca aparece em uma fatura. Alguém precisa cuidar da lista de permitidos, aprovar códigos de pareamento de novos contratados, revisar a memória em espera e manter o gateway atualizado. Para o trabalho 1, isso é tranquilo, porque o administrador é o usuário. Para o trabalho 2, vira um pequeno produto interno que agora você mantém. Um cliente que decidiu não construir o próprio resumiu bem a troca:
"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."
an engineering lead at a crypto-hardware company, on why they bought instead of building
Hermes vs eesel para suporte de TI interno
Veja como os dois se comparam no que um líder de TI costuma perguntar primeiro.
| Hermes Agent | eesel | |
|---|---|---|
| O que é | Agente auto-hospedado de uso geral | Colega de help desk com IA pronto para usar |
| Onde os funcionários perguntam | Slack, Teams, Google Chat, e-mail, 20+ outros | Slack, Google Chat, Microsoft Teams (sob solicitação) |
| Quem pode aprovar ações arriscadas | Quem estiver conversando | Só Owners e Editors do workspace, identificados pelo e-mail do Slack |
| Configuração de acesso | Listas de permitidos por ID de usuário ou códigos de pareamento | Instalar o app; ele pergunta antes de entrar em canais |
| Fontes de conhecimento | Servidores MCP e skills que você conecta | Confluence, Notion, Google Drive, arquivos |
| Ticketing | Jira via Atlassian MCP; ServiceNow por conta própria | Primeiro respondente do Jira Service Management |
| Executa comandos em servidores | Sim, via SSH | Não; chama APIs REST via Network Access |
| Teste com tickets passados | Não integrado | Simulação com tickets passados |
| Preço | Software gratuito mais tokens, hospedagem e tempo de desenvolvimento | 100 créditos grátis; a partir de $299/mo por 500 créditos |
Fontes: documentação de Internal Operations da eesel, aprovações da eesel, preços da eesel.
Para ser franco sobre os limites da eesel: ela não executa comandos de shell nos seus servidores, e isso é proposital. É um colega de service desk, não um sysadmin. Se você quer um agente que entre por SSH em uma máquina e reinicie o nginx, esse é o trabalho 1 do Hermes, não o propósito da eesel. A eesel também não tem hoje integração com ServiceNow ou Freshservice (meu apanhado de IA para Freshservice cobre esse stack), e o Teams é ativado sob solicitação, não por autoatendimento.
Você deve rodar o Hermes para TI interno?
Sim, para o trabalho 1. Se você tem uma equipe pequena de TI ou operações e um engenheiro que curte isso, o Hermes como ajudante só para administradores é uma boa ferramenta, e gratuita. Rode com o backend SSH e aprovações manuais, Datadog ou Grafana via MCP e cron só de script para as verificações chatas.
Com cuidado, para um it-desk somente leitura. Se o seu conhecimento está no Confluence e seus tickets no Jira, um perfil sem terminal preso a #it-help pode responder às perguntas de "como faço". Só reserve orçamento para a manutenção da lista de permitidos e para os testes que ninguém quer fazer.
Não, para uma porta de entrada de funcionários com terminal. Até o Hermes conseguir rotear aprovações para um administrador, eu não deixaria 200 funcionários conversarem com um agente que pode executar systemctl. Isso não é uma crítica ao Hermes. Ele foi feito para o operador, e a documentação diz isso.
Se você ainda está avaliando opções, minhas listas de ferramentas de IA para suporte de TI e chatbots de suporte interno cobrem ferramentas feitas para a porta de entrada, e minha lista de sistemas de tickets no Slack cobre o lado do ticketing.
eesel para suporte de TI interno
Se o que você realmente quer é o trabalho 2, um help desk de TI que os funcionários possam consultar no Slack sem que ninguém rode um servidor, é isso que o colega de help desk da eesel faz. Ele responde a partir do seu Confluence, Notion e Google Drive com a fonte linkada, e quando não encontra algo, diz isso.
A parte que mais importa para este post são as aprovações. Cada ação é definida como Auto, Requer aprovação ou Desativada, e quando uma execução começou no Slack, o cartão de aprovação cai naquela thread. Só Owners e Editors do workspace podem aprovar, identificados pelo e-mail do perfil do Slack (documentação de aprovações). O funcionário que perguntou não pode aprovar o próprio pedido.
Para TI com tickets, a eesel trabalha dentro do Jira Service Management: ela pega as novas solicitações, responde ao solicitante ou deixa uma nota interna, e atribui, etiqueta e move issues. E antes de tocar em qualquer solicitação real, você pode rodá-la contra tickets passados e ler cada resposta que ela daria.
E se a sua equipe gosta do terminal tanto quanto os usuários do Hermes, a CLI da eesel roda o mesmo colega a partir de um shell. eesel approvals lista as ações pendentes, eesel chat "how do I reset a password?" testa uma resposta, e todo comando imprime JSON, de modo que o Claude Code ou o Codex podem conduzir sua configuração. Precisa que ela alcance um banco de dados interno de ativos? O Network Access permite que ela chame uma API REST enquanto as credenciais ficam fora da vista da IA.
Você pode experimentar a eesel de graça com 100 créditos, sem cartão. Conecte o Slack e o Confluence, faça a ela as suas dez perguntas de TI mais comuns e veja o que volta.