Google Mantis: o que a descoberta de bugs com IA precisa para funcionar

Resumo rápido: ferramentas de segurança precisam de um ciclo de verificação

O projeto Mantis, apresentado pelo Google Cloud, é um exemplo de para onde a segurança de aplicações com IA está avançando. Em vez de pedir que um modelo escaneie um repositório e devolva uma lista enorme de suspeitas, o Mantis é descrito como um harness que coordena descoberta de vulnerabilidades, triagem, reprodução, deduplicação e verificação de patches. A ideia importante não é substituir o engenheiro de segurança. É tornar o agente útil quando ele tem histórico do repositório, um modelo de ameaças, execução isolada, ferramentas repetíveis e um teste explícito para saber se a correção funcionou.

Isso muda a pergunta de compra. O melhor assistente de segurança não é necessariamente o que gera mais alertas. É o que ajuda a equipe a sair de uma linha suspeita e chegar a um achado reproduzível, um patch revisável e evidências de que a regressão desapareceu.

O problema que o Mantis tenta resolver

A visão do Google Cloud sobre o Mantis apresenta o projeto como um harness open source para encontrar e corrigir bugs com agentes de IA. O repositório do Mantis inclui fluxos e habilidades voltados para análise de segurança. Na prática, o agente recebe um ambiente estruturado, não uma janela de chat vazia.

Isso importa porque descobertas de segurança raramente são apenas problemas de geração de texto. Uma investigação útil pode precisar entender como um recurso mudou, localizar a fronteira de confiança de uma entrada, criar uma prova de conceito pequena, executar testes em sandbox, comparar um patch com o comportamento original e remover relatórios duplicados. Cada etapa exige evidências diferentes. Um modelo bom em explicar código ainda pode ser ruim em provar explorabilidade ou verificar se a correção não quebrou outro caminho.

Por que histórico e threat modeling fazem diferença

Um scanner estático vê o código de hoje. Um agente com histórico também pode descobrir por que uma verificação de permissão foi adicionada, qual entrada era considerada insegura ou se uma correção anterior ficou incompleta. Esse contexto reduz falsos positivos e ajuda a priorizar mudanças que afetam uma fronteira real.

O threat modeling acrescenta perguntas essenciais: quem controla a entrada, o que o atacante consegue alcançar, qual identidade ou dado pode ser afetado e o que um ataque bem-sucedido mudaria. Sem essas perguntas, o agente pode chamar todo padrão incomum de crítico ou perder um problema sutil porque o código parece normal isoladamente.

Por isso, ferramentas de segurança com IA devem mostrar evidências, não apenas uma pontuação confiante. Um relatório deve indicar arquivos e caminhos, premissas, passos de reprodução, impacto esperado e limites da análise. Assim a equipe decide entre corrigir, aplicar um controle compensatório ou não agir.

Reprodução é o divisor de águas

A parte mais valiosa de um fluxo agentic costuma ser tentar reproduzir o problema com segurança. Uma sandbox pode limitar rede, credenciais, sistema de arquivos e comandos destrutivos, permitindo ao mesmo tempo testar uma hipótese estreita. O resultado é mais concreto que uma simples correspondência de padrões.

A reprodução também melhora a comunicação. O desenvolvedor revisa um caso de teste pequeno, o revisor de segurança verifica a fronteira e o responsável pelo release pode exigir que o mesmo teste passe depois do patch. O processo cria um artefato que continua útil fora da conversa original.

Nem toda vulnerabilidade pode ser provada automaticamente. Algumas dependem de configuração de produção, tempo, políticas de identidade ou da combinação de vários controles fracos. Nesses casos, a saída correta é uma hipótese limitada e marcada com incerteza, não um exploit inventado.

O que verificar antes de escolher uma ferramenta

Antes de baixar ou adotar uma ferramenta de segurança com agentes, confira cinco limites:

1. Permissões: o agente lê segredos, escreve em branches de produção ou chama serviços externos?
2. Isolamento: a reprodução usa um ambiente descartável com políticas claras de rede e arquivos?
3. Evidências: o achado aponta para código, testes, logs e passos reproduzíveis?
4. Recuperação: uma pessoa pode pausar, reverter ou rejeitar o patch?
5. Dados: repositórios, prompts e patches gerados são retidos ou usados para treinamento?

Para comparar assistentes de código, scanners, ferramentas de teste e utilitários de repositório, visite o diretório de software da BTTC. Compare permissões, integrações, exportação e controles de revisão, não apenas o rótulo “IA”. Há mais explicações práticas no blog da BTTC.

Perguntas frequentes sobre agentes e segurança

Um agente de IA substitui um engenheiro de segurança?

Não. Ele acelera investigações repetitivas e organiza evidências, mas pessoas ainda precisam definir risco, validar premissas, aprovar mudanças e entender o ambiente de produção.

Um bug reproduzido é automaticamente uma vulnerabilidade crítica?

Não. A reprodução mostra que um comportamento ocorre nas condições testadas. A gravidade depende da exposição, do controle do atacante, dos ativos afetados, dos privilégios e do impacto comercial.

O agente deve fazer merge do próprio patch?

Normalmente não por padrão. Um limite mais seguro é permitir um patch proposto e um teste de regressão, exigindo revisão humana e uma verificação independente.

Conclusão

O Google Mantis aponta para um modelo mais confiável de segurança assistida por IA: agentes devem reunir contexto, testar hipóteses limitadas, produzir evidências revisáveis e verificar a correção dentro de limites controlados. Para quem avalia ferramentas de desenvolvimento, a pergunta duradoura é simples: o produto ajuda a provar e resolver um problema com segurança, ou apenas gera outra lista para revisar?