Google abre o Mantis — reproduzir a falha ainda exige isolamento
Em 2 de setembro de 2026, o Google apresentou o Mantis como um framework aberto para agentes de programação descobrirem, triarem, reproduzirem e corrigirem vulnerabilidades em repositórios de software. O anúncio do Google Cloud informa que o código está disponível no GitHub e relaciona o projeto à abordagem interna da empresa para encontrar e corrigir falhas.
Também em 2 de setembro de 2026, uma síntese independente da ComputeLabs registrou a abertura do Mantis e o encadeamento entre descoberta, triagem, reprodução e patch. A disponibilidade pública, porém, não elimina a principal condição de uso: as etapas sensíveis podem executar código produzido por IA e precisam permanecer isoladas, sob critérios definidos por pessoas.
O fluxo separa descoberta, crítica e correção
O Mantis é um conjunto modular e sequencial de habilidades, não um scanner único que devolve um veredito definitivo. Cada etapa produz ou atualiza artefatos sobre o repositório, permitindo que uma suspeita seja contestada antes de avançar para reprodução, classificação de risco ou correção.
O trabalho pode começar com o histórico de versões, um índice estrutural, um resumo da arquitetura e um modelo de ameaças. Em seguida, o planejamento delimita as áreas de interesse; a pesquisa procura falhas; e as etapas de deduplicação, revisão e crítica tentam retirar achados repetidos, inválidos ou sem viabilidade em uma compilação de produção.
Somente depois entram a geração de uma prova de conceito, a tentativa de reprodução em sandbox e a combinação de achados individuais em uma possível cadeia. Se houver evidência suficiente, o agente pode preparar uma alteração mínima, repetir o teste contra o código modificado, calibrar o risco e montar um relatório para revisão humana. Descoberta, reprodução e correção continuam sendo estados diferentes, e não sinônimos de vulnerabilidade confirmada.
Reproduzir aproxima a hipótese da evidência
A reprodução existe para confrontar o raciocínio do modelo com um efeito observável no programa. Uma análise pode interpretar uma chamada de forma errada, ignorar uma validação existente ou imaginar um caminho inalcançável; por isso, uma descrição plausível da falha não basta para estabelecer seu impacto.
Antes da execução, a equipe precisa determinar o que constitui sucesso. Dependendo do caso, pode ser um travamento em uma compilação representativa, a chegada comprovada a uma função vulnerável ou a violação observável de uma fronteira de acesso. Um erro de compilação, uma dependência ausente ou a montagem incompleta do serviço não demonstram a falha e tampouco provam que o achado é falso.
O mesmo limite vale no sentido contrário. Uma prova de conceito bem-sucedida confirma determinado comportamento nas condições do teste, mas não garante que a vulnerabilidade seja explorável em todos os contextos. Quando o Mantis relaciona falhas em uma cadeia, o efeito combinado ainda pode depender de um ambiente específico e de validação adicional.
O isolamento precisa existir fora do agente
A documentação do repositório Mantis alerta que a suíte gera e executa código autônomo potencialmente instável, exige ambientes isolados e restritos e proíbe seu uso em máquinas com acesso a produção, dados sensíveis ou redes internas. Para os agentes de reprodução e patch, o projeto descreve contêineres sem rede, cita gVisor como reforço e recomenda uma máquina virtual dedicada como barreira adicional.
Essas instruções não constituem uma garantia de contenção. Como o agente é não determinístico, ele pode tentar uma ação insegura ou deixar de seguir a etapa de sandbox se o ambiente permitir. A separação efetiva, portanto, depende de controles externos ao modelo: privilégios mínimos, credenciais ausentes, destinos de escrita limitados e bloqueios de rede impostos pela infraestrutura.
No modo interativo, o agente deve pedir aprovação antes de executar comandos sensíveis, sobretudo ao rodar uma carga ou modificar arquivos. Uma operação sem supervisão exige limites mais fortes e um orquestrador determinístico; a própria documentação trata uma máquina virtual reforçada como requisito para execução contínua e autônoma.
O patch não encerra a validação
Bloquear a prova de conceito original é uma evidência útil, mas não demonstra sozinho que a causa foi removida ou que outras variantes deixaram de funcionar. A alteração também pode introduzir regressões, restringir um comportamento legítimo ou apenas mudar as condições do teste.
O projeto determina que todos os achados sejam verificados manualmente por um especialista antes de serem reportados e desaconselha o envio em massa de relatórios gerados por IA a mantenedores de código aberto. A revisão precisa confrontar o caminho alcançável, as premissas do atacante, o impacto real e o efeito do patch no restante do sistema.
Esse limite define também o público do Mantis. O toolkit pode servir como ponto de partida para equipes de desenvolvimento e segurança capazes de adaptar o modelo de ameaças, construir o ambiente de execução e assumir a decisão final. Não é um produto Google oficialmente suportado: o repositório o classifica como demonstração e afirma que ele não se destina a ambientes de produção.
Assim, a abertura do código torna o fluxo inspecionável e adaptável, mas não transfere confiança automática aos resultados. O Mantis organiza a passagem da suspeita ao teste e do teste ao patch; isolamento de infraestrutura, critérios de reprodução e julgamento especializado continuam fora do alcance de uma sequência puramente autônoma.
Leia também:
Assine nossa newsletter
Receba as últimas notícias sobre Web3, IA e cripto diretamente no seu e-mail.