Além do hackbot: como funciona a pesquisa de vulnerabilidades assistida por IA

A pesquisa de vulnerabilidades assistida por IA costuma ser apresentada por meio da figura do “hackbot”: um agente quase autônomo que recebe um alvo, executa ferramentas e encontra sozinho uma falha crítica.

Essa imagem é atraente, mas descreve mal o trabalho real.

Ferramentas como Codex e Claude Code conseguem ler mais código, testar mais hipóteses e repetir tarefas em uma velocidade difícil de alcançar manualmente. Esse volume aumenta a cobertura. Ele não garante profundidade, criatividade nem qualidade.

O que torna a pesquisa produtiva é o sistema em torno do modelo. A heurística define onde vale a pena olhar. O steering orienta como aprofundar cada hipótese. A execução produz evidência. Um corpus persistente preserva o que foi aprendido e melhora a próxima rodada.

A IA não substitui o processo de pesquisa. Ela permite executá-lo, registrá-lo e refiná-lo continuamente.

Por que “encontre vulnerabilidades” não basta

Um prompt como:

analise esse projeto e encontre vulnerabilidades

não contém uma estratégia. O agente ainda precisa decidir quais superfícies merecem atenção, que classes de falha priorizar, quanto tempo gastar em cada hipótese e quando uma observação justifica a criação de um laboratório ou harness.

Sem critérios claros, a tendência é produzir uma auditoria superficial. O modelo procura sinks conhecidos, lista fluxos suspeitos e encerra a análise antes das partes caras. Isso não ocorre necessariamente por falta de capacidade. O problema é que profundidade tem custo.

Uma hipótese complexa pode exigir a leitura de várias camadas, a compilação de uma versão específica, a reconstrução de uma feature, a criação de estados raros e o uso de controles negativos para eliminar explicações alternativas. Se “entregar algum resultado” parece ser o objetivo, dez suspeitas frágeis podem parecer mais úteis que uma única investigação inconclusiva.

As instruções iniciais precisam corrigir esse incentivo. Quantidade de suspeitas não deve ser tratada como sucesso. Um finding só deve existir depois de validação, e caminhos óbvios em projetos maduros devem receber menos atenção que inconsistências ainda pouco compreendidas.

O agente também precisa ter permissão para executar o trabalho necessário. Compilar, instrumentar, escrever aplicações mínimas, criar ferramentas temporárias e fazer fuzzing não são desvios. Muitas vezes, são o que separa uma leitura plausível de uma falha demonstrada.

Heurística e steering

Heurística é o conjunto de critérios usado para escolher onde pesquisar. Steering é a correção aplicada durante a investigação para manter o agente na pergunta certa.

Em projetos maduros, as falhas mais interessantes raramente aparecem apenas como uma chamada obviamente perigosa. Elas surgem nas diferenças entre camadas:

• uma parte valida uma representação, enquanto outra consome uma forma transformada do mesmo dado;
• um controle protege o caminho principal, mas ignora um entrypoint equivalente;
• duas features corretas isoladamente quebram uma garantia quando combinadas;
• uma API responde a uma pergunta parecida, mas não idêntica, àquela que o código pretendia fazer.

Esses padrões não provam uma vulnerabilidade. Eles indicam pontos onde o modelo de segurança pode divergir do comportamento real.

O steering macro define regras para toda a pesquisa, como exigir impacto concreto, priorizar fronteiras de confiança e registrar resultados negativos. O steering local controla uma hipótese. Ele pode mandar interromper a busca por novos sinks e construir uma reprodução mínima, ou encerrar uma linha cujo impacto ainda depende de uma premissa improvável.

Persistência sem esse controle apenas produz loops mais longos. Um bom sistema precisa saber aprofundar e também saber parar.

Evidência antes de finding

Uma hipótese não deve avançar apenas porque parece plausível. Ela precisa sobreviver a gates de evidência.

Uma observação inicial merece uma verificação barata. Se houver uma hipótese concreta, o passo seguinte é demonstrar que dados ou estados controláveis chegam ao ponto relevante. Só então faz sentido investir em uma reprodução completa.

Mesmo um comportamento reproduzido ainda não é necessariamente uma vulnerabilidade. Ele pode ser esperado, depender de uma configuração artificial ou não quebrar nenhuma propriedade de segurança. A análise de impacto precisa identificar o atacante, a condição de exploração, a autoridade obtida e o efeito sobre um alvo real.

A maior parte das ideias não deveria chegar ao último estágio. Descartá-las cedo não é fracasso; é alocação correta de tempo.

O resultado negativo, porém, precisa ser útil. “Não vulnerável” diz pouco. O registro deve explicar por que a hipótese parecia promissora, como foi testada, que mecanismo impediu o impacto e quais mudanças poderiam invalidar a conclusão. Assim, uma rodada futura consegue distinguir repetição de reavaliação.

O corpus persistente

O corpus é o conhecimento acumulado sobre o alvo. Ele vai além dos arquivos do projeto e do histórico de conversa.

Um corpus útil preserva:

• a arquitetura e as principais fronteiras de confiança;
• hipóteses testadas, evidências e condições de validade;
• versões, comandos, scripts, harnesses e ambientes de reprodução;
• comportamentos estranhos ainda sem conclusão;
• caminhos descartados e os motivos do descarte.

Sem esse registro, cada sessão reaprende o projeto. Com vários agentes, o desperdício aumenta: eles podem reconstruir os mesmos ambientes, repetir análises e reencontrar hipóteses já eliminadas.

Memória persistente também não significa colocar tudo em um arquivo enorme. O contexto precisa ser recuperado de forma seletiva. Ao entrar em um componente, o agente deveria receber as decisões ligadas àquela região, não todo o histórico da pesquisa. Ao analisar uma mudança, deveria encontrar conclusões antigas que dependiam do comportamento alterado.

Esse é o objetivo do Proteus, o framework que criamos na Vyntra para pesquisa contínua de vulnerabilidades. Ele não tenta transformar segurança em um botão automático. O objetivo é manter coerência entre rodadas, registrar novo aprendizado e impedir que a investigação volte aos mesmos loops.

Modelos e prompts podem ser copiados. Um corpus maduro é específico do alvo. Depois de várias rodadas, ele representa um mapa de arquitetura, garantias, áreas saturadas e perguntas que ainda valem o custo.

Como uma rodada melhora a seguinte

Uma primeira rodada pode descobrir que uma feature usa três representações internas para o mesmo recurso. Essa observação entra no corpus.

A rodada seguinte não precisa “analisar a feature” de novo. Ela pode comparar como autenticação, cache e canonicalização tratam cada representação. Se duas passam pelo mesmo pipeline e a terceira é resolvida por uma camada posterior, o próximo steering pode focar apenas nessa divergência e exigir validação dinâmica.

A profundidade não surge de um prompt perfeito. Ela surge quando cada rodada reduz a incerteza e permite formular uma pergunta melhor.

Esse ciclo também evita um uso ruim de contexto. Em vez de enviar todo o histórico ao modelo, o sistema recupera as decisões que mudam a investigação atual. O agente começa sabendo o que já foi provado, o que falhou e quais condições continuam abertas.

Criatividade nas diferenças entre camadas

Criatividade em pesquisa não significa inventar ataques aleatórios. Significa conectar comportamentos reais que costumam ser analisados separadamente.

Foi esse tipo de raciocínio que levou a falhas que encontramos em projetos maduros. No caso dos artefatos de segmento RSC do Next.js, uma camada avaliava o pathname protegido enquanto outra entregava conteúdo correspondente a um entrypoint diferente. No bypass de allowlist do Vercel AI SDK, a checagem respondia positivamente a propriedades herdadas que nunca haviam sido aprovadas diretamente.

Nenhum dos casos dependia de uma função com o rótulo “insegura”. A falha estava na diferença entre a pergunta que o código pretendia responder e aquela que realmente respondia.

Agentes são úteis para manter várias relações em paralelo, navegar entre implementações distantes e construir testes rapidamente. Ainda assim, o corpus precisa fornecer fatos confiáveis, e o steering precisa exigir uma quebra concreta antes de promover a conexão.

Labs, fuzzing e execução

Pesquisa assistida por IA não é apenas leitura de código. Agentes conseguem montar aplicações mínimas, servidores simulados, clientes de protocolo, scripts de instrumentação e harnesses de fuzzing com baixo custo.

Isso acelera a passagem de suspeita para evidência. Porém, a instrução “faça fuzzing” continua sendo fraca. Uma campanha precisa definir:

• o comportamento explorado;
• os estados que o harness deve alcançar;
• o oracle que distingue um resultado relevante;
• controles que confirmem que a parte interessante do componente foi exercitada.

Coverage, crashes e resultados precisam voltar ao corpus. Eles devem orientar novas sementes, mudanças no harness e a decisão de continuar ou encerrar a campanha. Sem memória, campanhas ruins são repetidas. Sem steering, resultados se acumulam sem uma regra para decidir quais merecem investigação.

Um agente bem orientado pode superar muitos

Arquiteturas multiagente aumentam cobertura e paralelismo, mas não resolvem o problema central por conta própria.

Sem memória compartilhada, divisão clara de superfícies e critérios iguais de promoção, vários agentes repetem trabalho em paralelo e produzem mais ruído. A escala amplia tanto um processo bom quanto um processo ruim.

Um único agente com boa heurística, contexto relevante, capacidade de execução e memória persistente pode ser mais eficiente que dezenas de agentes genéricos percorrendo o mesmo repositório sem coordenação. Na nossa experiência, esse modelo permitiu investigar falhas complexas em alvos muito analisados usando o Codex como executor principal.

Mais agentes passam a ajudar quando o sistema consegue separar frentes, compartilhar evidência e impedir duplicação. A qualidade da coordenação vem antes da quantidade.

O pesquisador continua no centro

O papel do pesquisador muda, mas não desaparece. Em vez de executar manualmente cada leitura, ele controla o sistema de pesquisa.

É o pesquisador que define prioridades, reconhece fronteiras de confiança, avalia exploitabilidade, corrige interpretações e decide quando uma hipótese merece mais custo. Também é ele quem adiciona contexto que não está no código.

Um comportamento pode ser reproduzível, mas depender de uma condição irreal. Outro pode parecer pequeno isoladamente, mas quebrar uma garantia central do produto. O agente pode demonstrar que algo acontece. Concluir se aquilo constitui uma vulnerabilidade relevante exige modelagem de ameaça e julgamento.

Por isso, “pesquisa assistida” descreve melhor o processo que “pesquisa autônoma”. A IA amplia a execução e parte do raciocínio, mas a direção e os critérios de qualidade continuam sob responsabilidade do pesquisador.

Conclusão

Pesquisa de vulnerabilidades assistida por IA não é apertar um botão e esperar uma CVE. Também não é executar o maior número possível de agentes até algum deles encontrar algo.

O processo é iterativo. A heurística escolhe onde olhar. O steering define como aprofundar. A execução produz evidência. A avaliação elimina hipóteses fracas. O corpus preserva o que cada rodada ensinou.

Com o tempo, o agente deveria repetir menos trabalho, operar sobre um espaço de busca menor e receber perguntas mais precisas. É isso que permite trocar cobertura superficial por profundidade.

A IA aumenta a velocidade da pesquisa. A direção vem da heurística. A continuidade vem do corpus.