LançamentoAnálise · No radarX: @NousResearch→ original

Hermes Agent ganha busca de vulnerabilidades em código com o plugin oficial Security

A Nous Research adicionou ao Hermes Agent o plugin oficial Security, que busca vulnerabilidades na base de código. O agente primeiro identifica o que um invasor consegue alcançar e em quais dados de entrada o código confia. Depois divide o trabalho entre subagentes em paralelo e confere cada problema encontrado no código. Para equipes sem um especialista dedicado à segurança, é uma forma prática de fazer uma primeira revisão do repositório.

Processado por IA de X: @NousResearch; editado por Hamidun News
Hermes Agent ganha busca de vulnerabilidades em código com o plugin oficial Security
Fonte: X: @NousResearch. Colagem: Hamidun News.
Ouvir artigo
Ficha técnica e números-chave
ParâmetroDados
Fonte originalX: @NousResearch ↗
Editor-chefe
Dado-chave #1O autor do plugin é @mark_s, e o lançamento é oficial
Primeiro vem a modelagem de ameaçaso que está acessível ao invasor e em que o código confia
Dado-chave #3Os subagentes trabalham em paralelo, e cada descoberta é verificada

Quem já entregou código a um LLM com a instrução “encontre vulnerabilidades” sabe como isso termina. O modelo gera uma longa lista de “possíveis problemas”, metade deles inventados ou impossíveis de alcançar a partir de um ponto de entrada real. Analisar esse relatório leva mais tempo do que procurar os bugs por conta própria. A Nous Research está tentando resolver exatamente esse problema: o Hermes Agent agora tem um plugin oficial chamado Security, desenvolvido por @mark_s.

O que sabemos sobre o funcionamento do plugin

Segundo o anúncio, o Hermes começa pelo reconhecimento, em vez de partir diretamente para a busca de bugs. Primeiro, o agente mapeia o que está acessível a um invasor no projeto e em quais dados de entrada o código confia. Essa é a lógica habitual da modelagem de ameaças. Uma vulnerabilidade em uma função inacessível externamente e a mesma falha no código que processa uma requisição pública têm consequências financeiras diferentes.

Em seguida, o código é dividido entre subagentes que trabalham em paralelo. Cada um examina sua própria seção, de modo que um repositório grande não fica limitado à janela de contexto de um único modelo. A julgar pelo anúncio, a terceira etapa é a mais importante: o agente confere cada problema encontrado no código antes de incluí-lo no relatório. O final da publicação está cortado, por isso a fonte não permite afirmar exatamente o que acontece depois dessa verificação.

Por que a abordagem parece fazer sentido

Imagine um serviço web típico. Há um endpoint que recebe do usuário um nome de arquivo e lê esse arquivo do disco. Um prompt de revisão simplista pode sinalizar uma dúzia de ocorrências de open em arquivos diferentes. O fluxo descrito no anúncio funciona de outra forma. Primeiro, identifica que o parâmetro vem de uma entrada não confiável. Depois, o agente rastreia seu destino e só então aponta uma possível vulnerabilidade de travessia de diretórios. A descoberta fica vinculada a um fluxo de dados específico, o que facilita sua verificação por uma pessoa.

Os subagentes em paralelo resolvem aqui um problema de engenharia. Auditar um monólito de forma sequencial leva muito tempo e preenche rapidamente a janela de contexto. Dividir o trabalho em partes acelera o processo e reduz o risco de o modelo perder detalhes no meio da análise.

O que ainda não sabemos

A publicação é curta e tem alcance modesto: cerca de 15 mil visualizações. Por isso, é importante não atribuir a ela mais do que as evidências permitem. A fonte não apresenta dados sobre a taxa de falsos positivos, as linguagens compatíveis, o custo de executar o plugin em um repositório grande nem comparações com analisadores estáticos. Também não traz exemplos de vulnerabilidades reais encontradas. Por enquanto, trata-se de uma abordagem anunciada, não de um resultado comprovado.

Há ainda um risco comum a todos os agentes de auditoria: a verificação “no código” continua sendo feita por um modelo. Ele pode confirmar com convicção uma descoberta incorreta ou deixar passar uma vulnerabilidade real. Uma ferramenta assim não substitui SAST, testes de invasão ou revisão humana.

O que fazer na prática

Se você já usa o Hermes Agent, vale testar o plugin em um serviço pequeno cujos pontos fracos você conhece. Insira previamente alguns problemas conhecidos e veja se o agente os encontra e quanto ruído acrescenta. Essa é a maneira mais rápida de avaliar sua qualidade sem confiar apenas no anúncio.

Para equipes sem um especialista dedicado à segurança, um papel razoável para esse tipo de ferramenta é fazer uma primeira revisão antes de um lançamento ou de uma auditoria completa. Ela deve identificar os problemas óbvios e levantar hipóteses com indicações de onde surgiram. Para gestores de produto e fundadores, a conclusão é simples: os agentes de revisão de segurança estão passando da geração de listas para um fluxo de “reconhecimento, divisão do trabalho e verificação”. São essas três capacidades que devem orientar a comparação entre soluções concorrentes.

A chegada de um plugin oficial da equipe da Nous também sinaliza outra tendência. O ecossistema do Hermes Agent cresce por meio de extensões, além da evolução do próprio modelo. Testes independentes mostrarão o quanto esse plugin específico é útil; uma publicação no X não basta para demonstrar isso.

História

Perguntas frequentes sobre a notícia

O que sabemos sobre o funcionamento do plugin?

Segundo o anúncio, o Hermes começa pelo reconhecimento, em vez de partir diretamente para a busca de bugs. Primeiro, o agente mapeia o que está acessível a um invasor no projeto e em quais dados de entrada o código confia. Essa é a lógica habitual da modelagem de ameaças. Uma vulnerabilidade em uma função inacessível externamente e a mesma falha no código que processa uma requisição pública têm consequências financeiras diferentes. Em seguida, o código é dividido entre subagentes que trabalham em paralelo.

Por que a abordagem parece fazer sentido?

Imagine um serviço web típico. Há um endpoint que recebe do usuário um nome de arquivo e lê esse arquivo do disco. Um prompt de revisão simplista pode sinalizar uma dúzia de ocorrências de open em arquivos diferentes. O fluxo descrito no anúncio funciona de outra forma. Primeiro, identifica que o parâmetro vem de uma entrada não confiável. Depois, o agente rastreia seu destino e só então aponta uma possível vulnerabilidade de travessia de diretórios.

O que ainda não sabemos?

A publicação é curta e tem alcance modesto: cerca de 15 mil visualizações. Por isso, é importante não atribuir a ela mais do que as evidências permitem. A fonte não apresenta dados sobre a taxa de falsos positivos, as linguagens compatíveis, o custo de executar o plugin em um repositório grande nem comparações com analisadores estáticos. Também não traz exemplos de vulnerabilidades reais encontradas. Por enquanto, trata-se de uma abordagem anunciada, não de um resultado comprovado.

ZK
Zhemal Khamidun — CPO da Alpina Digital, gerente de produto do AlpinaGPT. Cria produtos de IA desde 2019. O Hamidun News é um projeto pessoal que virou um agregador em produção com mais de 6.000 leitores.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
O que você acha?
Carregando comentários…