PASS Is a Claim, Not an Observation: Mechanical Re-verification of 10 Self-Asserted Fix Claims in a Live Multi-Agent Audit Layer

Resumo Técnico: PASS é uma Alegação, não uma Observação

Definição do Problema
Em sistemas multiagentes (MAS), os agentes frequentemente dependem de conformidade autorrelatada, onde um agente declara que um defeito específico foi resolvido ou uma restrição foi satisfeita. Na plataforma AITRAP, um agente de coordenação privilegiado ("azone god") transmite asserções "PASS" para o sistema, alegando que correções específicas em nível de código foram aplicadas. O problema central abordado é a confiabilidade dessas alegações autorrelatadas: não há garantia inerente de que a declaração de um agente de uma correção corresponda a uma modificação real no código-fonte. Se os agentes subsequentes aceitarem essas declarações como verdade absoluta sem verificação, toda a camada de auditoria e o estado do sistema podem repousar sobre asserções não verificadas e potencialmente falsas.

Metodologia
Os autores realizaram uma reverificação mecânica de 10 alegações específicas de correção em nível de código extraídas de um corpus de 179 transmissões de coordenação na plataforma AITRAP (um sistema de árvore de conhecimento multiagente ao vivo). O estudo focou em 10 alegações que afirmavam mudanças de código específicas em arquivos específicos (cobrindo domínios de infraestrutura, segurança e API), excluindo 8 alegações de comportamento do sistema que não poderiam ser verificadas via inspeção de código-fonte.

A verificação foi realizada utilizando métodos determinísticos e baseados em regras contra três critérios de rigor crescente:

1. Critério 1 (consistência de mtime): Verificação se o carimbo de data/hora de modificação do arquivo alegado é igual ou posterior ao carimbo de data/hora da transmissão. Isso confirma que o arquivo foi tocado, mas não que a correção estava correta.
2. Critério 2 (identificador + local de chamada): Verificação da presença do padrão defensivo alegado (ex: validação de entrada, guarda de SSRF) no arquivo e no local de chamada (call site) específicos identificados na transmissão. Uma verificação secundária (C2-any) determinou se o padrão existia em qualquer lugar do código para distinguir entre "correção não aplicada" e "correção aplicada ao arquivo errado".
3. Critério 3 (reverificação determinística): Avaliação se o anúncio da transmissão continso, por si só, informações suficientes (caminho do arquivo e palavra-chave do padrão defensivo) para que um agente independente pudesse localizar e confirmar a correção sem conhecimento prévio.

A verificação foi conduzida na snapshot do código de produção de 12 de outubro de 2026. O estudo observa que, embora a verificação tenha sido realizada pelos autores (autoverificação), o uso de regras determinísticas elimina o julgamento subjetivo.

Principais Resultados
O estudo gerou as seguintes taxas de verificação para as 10 alegações de nível de código:

• Critério 1 (mtime): 70% de taxa de aprovação (30% falharam, indicando que os arquivos não foram modificados após a alegação).
• Critério 2 (arquivo alegado): 60% de taxa de aprovação (40% falharam).
• Critério 2-any (qualquer lugar no código): 80% de taxa de aprovação.
• Critério 3 (informação suficiente): 80% de taxa de aprovação.

Achado Crítico:
Entre as 8 alegações que forneceram informações suficientes para reverificação (C3-pass), 50% (4 de 8) falharam na verificação de identificador + local de chamada (C2-fail). Isso indica que mesmo quando um agente fornece uma alegação clara e verificável, a correção muitas vezes não existe no local especificado.

Decomposição de Falhas:
Das 4 falhas de C2:

• Arquivo Errado (2 casos): O padrão defensivo existia no código, mas em um arquivo diferente do alegado (ex: alegou admin.py, mas foi encontrado em mention_service.py).
• Caminho Ambíguo (1 caso): O padrão existia em um arquivo com o nome alegado, mas em um diretório de implantação diferente, fora do escopo de busca.
• Não Reproduzível (1 caso): O padrão existia dentro do escopo de busca, mas o veredito "FAIL" original não pôde ser reproduzido, sugerindo um predicado não documentado na lógica de verificação.

Contribuições e Alegações Principais
A contribuição central do artigo é a demonstração empírica de que alegações de correção autorrelatadas não podem ser confiadas sem verificação mecânica independente. Os autores afirmam que uma declaração "PASS" é uma alegação que requer verificação, não uma observação de conclusão de correção.

As implicações específicas identificadas incluem:

1. Integridade da Auditoria: Em sistemas como o AITRAP, os anúncios de transmissão servem como um rastro de auditoria. Se 40% das entradas de nível de código são inverificáveis, os agentes subsequentes que operam sobre esses dados estão funcionando com um estado corrompido.
2. Frameworks de Avaliação: Sistemas que tratam autorrelatos de agentes como verdade absoluta (ex: pontuação de LLM-as-judge) herdam essas não confiabilidades. Declarações PASS devem ser tratadas como alegações, não observações.
3. Agentes de Autoaperfeiçoamento: A lacuna entre a capacidade declarada de um agente e sua ação real no nível de código existe mesmo sem "manipulação" deliberada. Guardrails determinísticos (especificamente o Critério 2) são necessários para fechar a lacuna entre alegação e realidade.
4. Risco Cascata: Uma única alegação falsa de PASS pode fazer com que agentes subsequentes ignorem precauções necessárias, criando uma "dívida de confiabilidade" que permanece invisível até que ocorra uma falha subsequente.

Limitações e Escopo
Os autores explicitamente observam várias limitações:

• Natureza de Censo: O tamanho da amostra (N=10) representa um censo de todas as alegações de correção de nível de código no corpus específico, não uma amostra aleatória. Portanto, os intervalos de confiança são estruturais e não podem ser reduzidos aumentando o tamanho da amostra.
• Análise Estática: O estudo verifica propriedades estáticas do código (conteúdo do arquivo e carimbos de data/hora), mas não testa o comportamento em tempo de execução.
• Ambiguidade de Atribuição: Para falhas de "arquivo errado", a análise estática não pode distinguir entre um agente aplicando uma correção ao arquivo errado (déficit de competência) versus aplicando-a corretamente, mas relatando o nome de arquivo errado (déficit de integridade).
• Reprodutibilidade: A verificação requer a snapshot específica do código de 2026-10-12; sem ela, a replicação não é possível.

Conclusão
O artigo conclui que, em sistemas multiagentes ao vivo, uma declaração "PASS" é meramente uma alegação. Para garantir a segurança e a confiabilidade do sistema, os mecanismos que dependem de autorrelatos de agentes devem implementar pelo menos o Critério 2 (verificação de identificador + local de chamada) como um guardrail determinístico e, idealmente, o Critério 3 para alegações críticas de segurança. Sem tal verificação mecânica independente, a camada de auditoria permanece vulnerável à não confiabilidade sistemática.