O Teste do Oráculo: Quando Confiar em um Agente para Achar um Bug

O tempo médio até a exploração de uma vulnerabilidade agora é de menos sete dias. O M-Trends 2026 da Mandiant diz sem rodeios: vulnerabilidades são frequentemente exploradas uma semana antes de o patch existir. Nas intrusões que a Mandiant investigou no último ano, a exploração de vulnerabilidade foi o vetor primário de infecção inicial.

Essa pressão explica por que todo time de segurança recebeu a ordem de apontar um agente para o próprio código. E explica também por que tantos desses deploys produzem uma fila em que ninguém confia. O texto AI-Assisted Vulnerability Management, da Mandiant Consulting / Google Cloud, assinado por Jules Czarniak com o Google Threat Intelligence Group, traz a primitiva que explica a diferença. Ela interroga o bug, e deixa o modelo em segundo plano.

A Pergunta: O Que Prova?

Um oráculo é aquilo que informa se um achado é real. Todo sistema automatizado de descoberta de bugs depende de um, e as propriedades desse oráculo decidem se um agente pode operar por conta própria.

A fonte descreve o mecanismo de forma direta: “if an agent’s payload fails to produce a clear outcome, it can’t reliably distinguish whether the vulnerability is a hallucination or if it simply constructed the payload incorrectly.” Duas falhas colapsam no mesmo silêncio. O agente não consegue distinguir uma da outra, então chuta ou reporta as duas. É por isso que varredura agêntica de código corporativo produz achados confiantes em volume, sem nenhuma forma de classificá-los.

O teste a rodar contra qualquer classe de bug que você pretendia entregar a um agente: se o agente estiver certo, o que acontece em segundos, de forma observável, sem um humano interpretando?

Classe Um: O Oráculo É Binário

Corrupção de memória responde a essa pergunta com um crash. O payload é enviado, o processo morre, o sanitizer imprime o stack trace. O sinal chega em milissegundos e não exige julgamento. Fuzzing funciona há duas décadas exatamente por causa dessa propriedade, e a razão pela qual agentes amplificam fuzzing com tanta eficiência é que eles herdaram um oráculo que já funcionava, em vez de inventar um.

Para essa classe, autonomia é uma decisão de engenharia trivial. O agente propõe, o harness prova, e o volume de propostas erradas custa quase nada porque cada uma é resolvida automaticamente.

Classe Dois: O Oráculo É Arquitetural

Agora considere um bypass de autorização. O agente monta uma requisição que lê os registros de outro tenant. Nada trava. A resposta é um HTTP 200 normal com um corpo JSON normal. Decidir se aquele corpo representa um vazamento exige saber de qual tenant era o registro, qual role deveria conseguir vê-lo e qual era a política pretendida. Esse conhecimento vive em um documento de arquitetura, em uma matriz de compliance ou na cabeça de alguém.

Falhas de lógica de negócio se comportam do mesmo jeito. SSRF indireta também, porque o resultado observável é uma requisição cujo destino o agente não consegue observar. A fonte é dura quanto à distribuição: software corporativo “is heavily dominated by vulnerabilities that require architectural oracles.”

Compare isso com as manchetes. As vitórias divulgadas em descoberta de vulnerabilidades por IA se concentram em C sem segurança de memória, em parsers, codecs e kernels, que é justamente onde o oráculo de crash existe. As classes de bug que de fato abrem uma brecha corporativa se concentram na outra metade. O CodeMender do Google fica do lado binário dessa linha, e a fonte o descreve como não disponível publicamente, então ele é um sinal de direção, não uma ferramenta que você adota neste trimestre.

A consequência prática é incômoda e limpa. Para oráculos arquiteturais, a saída do agente é infalsificável na velocidade da máquina. Um humano é dono do achado desde o instante em que ele aparece, e o papel do agente encolhe até virar geração de candidatos para uma pessoa que já entende o desenho pretendido.

O Portão: Descartar Antes do Humano Ver

A maioria das arquiteturas de triagem coloca o humano primeiro e a prova depois. A fonte inverte isso, e essa é a parte que vale copiar mesmo que você ignore todo o resto.

O agente é obrigado a produzir “a fully reproducible, deterministic test harness (such as a compiled binary or a Python test script) that attempts to prove the exploit.” Esse harness roda automaticamente em um sandbox isolado e monitorado, com timeouts rígidos de execução e limites de iteração. Se o sandbox não conseguir provar o exploit, o ticket é descartado. Nenhum humano chega a abrir. Se o sandbox provar, um engenheiro revisa um achado que já vem com reprodução funcionando.

A economia por trás disso está declarada com a mesma clareza: “LLMs can generate findings significantly faster than human engineers can triage them.” Uma fila que cresce mais rápido do que drena não é um programa de segurança. Automatizar a etapa de prova, e deixá-la apagar em vez de ranquear, é o que mantém a atenção humana escassa e, portanto, útil.

O mesmo script ganha uma segunda função depois. “By rerunning the initial PoC against the patched code, the workflow repurposes the exploit script as a validation oracle to prove the vulnerability has been remediated.” Um único artefato fecha o ciclo que ele abriu.

Três controles sustentam o pipeline, e cada um falha em silêncio se for ignorado. O acesso ao CI/CD fica “restricted to generating PRs, never direct commits to main.” Identidades de máquina são de menor privilégio e vinculadas a um controlador humano nomeado, com tokens JIT de curta duração “bound exclusively to the specific repository and branch.” Versões de API do modelo são fixadas em releases congelados, porque uma atualização silenciosa de pesos muda o comportamento do agente contra um harness calibrado na versão anterior. Logs de auditoria imutáveis então registram qual versão do modelo propôs a correção, quais testes determinísticos a validaram e qual engenheiro aprovou o merge, que é a evidência que SOC 2, PCI-DSS, FedRAMP, CMMC e as expectativas de supervisão humana do EU AI Act acabam exigindo.

Para achados que passam pelo portão, a fonte oferece uma fórmula de pontuação baseada em risco que vale guardar como artefato compacto:

Final Score = (W1 x S_vuln) + (W2 x S_asset) + (W3 x S_threat)
Pesos de exemplo: 0.20 / 0.40 / 0.40, escala 0-100

S_vuln é o CVSS Base multiplicado por 10. S_asset vai de 100 (exposto à internet com dados de cliente) até 25 (interno, sem dado sensível). S_threat é 100 quando há exploração ativa por atores relevantes, 75 quando existe PoC ou a classe é facilmente explorável por agentes autônomos de IA, e 25 quando é teórica e altamente complexa. O movimento interessante está na ponderação: contexto de ativo e contexto de ameaça juntos carregam 80% da nota, então o CVSS deixa de comandar a fila.

Onde Agentes Falham em Silêncio

Cinco modos de falha são nomeados, e todos os cinco são invisíveis sem uma etapa de prova na frente deles.

Degradação de atenção: uma variável contaminada na linha 10 e sanitizada na linha 500 é pontuada como contaminada. Estreitamento contextual: o agente hiper-fixa em um erro de sintaxe apontado pelo SAST e perde falhas arquiteturais no mesmo arquivo. Técnicas novas produzem falsos negativos silenciosos, já que “the agent will likely scan right past it in silence.” RAG desatualizado faz o agente descrever com confiança “a secure path that no longer exists in production.” E loops descontrolados de iteração queimam orçamento sem convergir, razão pela qual os timeouts são obrigatórios em vez de recomendados.

Duas observações de cadeia de suprimentos pertencem ao lado disso. A orientação de que “security teams should treat the codebase itself as an untrusted input” decorre direto do fato de que prompt injection mora em comentários e fixtures de teste. E “MCP plugins introduce the risk of supply chain poisoning, where a previously benign integration is silently updated with malicious dependencies.” Já cobrimos as superfícies de contenção que isso implica em o stack de contenção de agentes e em cinco níveis de contenção de bash; o teste do oráculo fica acima de todas elas, decidindo se o agente deveria ser apontado para aquele código.

Faça Isto Agora

Pegue seus últimos vinte achados de segurança, de qualquer origem, e separe em duas colunas: aqueles em que um script poderia provar o achado em menos de um minuto sem interpretação humana, e aqueles em que provar exigiu conhecer o desenho pretendido.

Aponte agentes apenas para a primeira coluna. A fonte restringe os alvos a quatro candidatos: bases de código sem segurança de memória, sistemas expostos a conteúdo externo, bibliotecas internas compartilhadas e fronteiras fundamentais de segurança. O próprio texto alerta contra amplitude: “Rather than indiscriminately pointing agents at all available codebases,” limite onde eles rodam.

Para a segunda coluna, a resposta honesta é que agentes ajudam um humano a ler mais rápido e não podem ser donos do veredicto. Alocar gente para a revisão é o controle. Comprar um scanner não é.

Uma ressalva sobre a fonte. É conteúdo consultivo da Mandiant com SKUs do Google atrelados, incluindo Model Armor, Assured OSS, o Mandiant Threat Modeling Security Service e o Wiz. A distinção de oráculo se sustenta independentemente de qualquer um deles. As recomendações de produto carregam interesse comercial e devem ser avaliadas assim. Vale registrar também: quando a IA encontra vulnerabilidades reais, divulgação e responsabilidade se tornam questões de governança bem antes de virarem questões de engenharia, e o problema de arquitetura não se resolve com um modelo melhor.

Fontes

Mandiant Consulting / Google Cloud, Jules Czarniak com o Google Threat Intelligence Group. “AI-Assisted Vulnerability Management.” Julho de 2026. O número de tempo médio até exploração tem origem no relatório M-Trends 2026 da Mandiant.

A Victorino ajuda organizações de engenharia a decidir quais classes de bug seus agentes podem assumir e constrói os portões determinísticos de prova que tornam o resto seguro para triagem: contato@victorino.com.br | www.victorino.com.br