Who Tests the Testers? Systematic Enumeration and Coverage Audit of LLM Agent Tool Call Safety

Título: Quem Testa os Testadores? Enumeração Sistemática e Auditoria de Cobertura da Segurança de Chamadas de Ferramentas em Agentes LLM

1. Problema e Motivação

Os Agentes de Grandes Modelos de Linguagem (LLM) estão cada vez mais integrados a ferramentas externas (e-mail, calendário, web, APIs), tornando sua segurança dependente não apenas da geração de texto, mas dos fluxos de trabalho de chamadas de ferramentas (tool-call workflows).

Embora existam benchmarks (conjuntos de testes) recentes que avaliam agentes em diversos ambientes e categorias de risco, surge uma questão fundamental não respondida: quão completos são os conjuntos de testes existentes?

• A Lacuna: Os benchmarks atuais focam na diversidade de ambientes e ferramentas, mas não caracterizam sistematicamente o espaço de padrões de comportamento inseguros.
• O Risco: Um agente pode passar em um benchmark (sandbox) mas ainda falhar em cenários do mundo real devido a pequenas variações no contexto do usuário, ambiguidades nos parâmetros da API ou conflitos de instruções que os testes existentes não cobrem.
• A Pergunta: Se um agente passa em um benchmark, até que ponto podemos afirmar que ele é "seguro"?

2. Metodologia: O Framework SafeAudit

Os autores propõem o SafeAudit, um framework de meta-auditoria projetado para descobrir "pontos cegos" (blind spots) nos benchmarks existentes e avaliar sua completude. O sistema opera em duas fases principais para superar dois desafios: a geração de casos de teste e a medição de completude.

A. Enumerador Baseado em LLM (Desafio 1: Geração)

Em vez de gerar casos de teste diretamente (o que cria um espaço de busca enorme e desestruturado), o SafeAudit utiliza uma abordagem de duas fases:

1. Fase 1 - Enumeração de Padrões Abstratos: Um LLM gera descrições de alto nível de padrões de interação insegura, focando em cadeias de chamadas de ferramentas (tool-call chains). O sistema decompõe o fluxo em etapas (busca, execução, verificação) para identificar onde a falha estrutural pode ocorrer (ex: ambiguidade na seleção de destinatário, dados obsoletos, falta de confirmação).
2. Fase 2 - Instanciação de Cenários: Os padrões abstratos são convertidos em casos de teste executáveis e concretos, variando o contexto do usuário (ex: um CFO de startup vs. um tesoureiro de ONG) e o nível de delegação de autoridade, garantindo que os casos sejam realistas e cobram uma ampla gama de estilos de interação.

B. Avaliação por Resistência a Regras (Desafio 2: Medição)

Como o espaço de cenários inseguros é ilimitado, a completude absoluta é impossível de medir. O SafeAudit introduz uma métrica quantitativa chamada Resistência a Regras (Rule-Resistance):

1. Extração de Regras: O sistema extrai regras de segurança compactas (ex: "MUST NOT enviar dados sem verificar...") dos casos de teste existentes do benchmark alvo.
2. Aplicação Iterativa: Essas regras são aplicadas sequencialmente ao agente alvo (anexadas ao system prompt).
3. Cálculo da Taxa de Não Cobertura (Uncovered Rate - UR): O sistema verifica quais casos de teste gerados pelo SafeAudit permanecem inseguros mesmo após a aplicação de todas as regras derivadas do benchmark.
   • Se um caso gerado pelo SafeAudit ainda é inseguro sob as regras do benchmark, ele representa um padrão de falha não coberto (um ponto cego).

3. Contribuições Principais

1. Enumerador Sistemático: Um mecanismo baseado em LLM que explora o espaço de fluxos de trabalho válidos de agentes, gerando sequências de chamadas de ferramentas e cenários de usuário diversificados, superando a geração ad-hoc de prompts.
2. Protocolo de Avaliação "Rule-Resistance": Uma métrica não semântica e verificável que mede a novidade dos casos de teste em relação às defesas derivadas do benchmark. Isso fornece um sinal relativo de completude baseado em rastros de chamadas de ferramentas, evitando interpretações subjetivas.
3. Análise de Padrões Inseguros: Identificação de ~11% de padrões de interação novos não cobertos pelos conjuntos de testes existentes sob as mesmas ferramentas e ambientes.

4. Resultados Experimentais

O estudo foi conduzido em 3 benchmarks (AgentSafetyBench, AgentHarm, ToolSafety), cobrindo 12 ambientes e 8 modelos base (backbone LLMs).

• Descoberta de Falhas Residuais: O SafeAudit revelou que os benchmarks existentes deixam de expor mais de 20% de comportamentos inseguros residuais.
• Comparação com Baselines: O SafeAudit superou consistentemente duas abordagens de base (DirectGen e SIRAJ) na taxa de descoberta de falhas não cobertas (Uncovered Rate).
  • Exemplo: No ambiente de E-mail do AgentSafetyBench, o SafeAudit encontrou uma taxa de não cobertura de 56,4%, enquanto as baselines ficaram em 31,8% e 40,0%.
• Escalabilidade de Cobertura: A taxa de descoberta de falhas cresceu monotonicamente à medida que o orçamento de geração aumentava, indicando que o enumerador continua a encontrar novos padrões de interação à medida que explora mais o espaço.
• Análise de Novidade: Cerca de 50% ou mais dos casos inseguros descobertos pelo SafeAudit correspondiam a padrões não representados nos benchmarks originais (novos mecanismos de falha, novos pontos de falha no pipeline ou cenários distintos).
• Generalização: O framework funcionou bem em modelos mais fortes (como GPT-5 e Qwen3-32B), embora modelos mais alinhados (como GPT-5) tenham taxas de não cobertura ligeiramente menores, sugerindo que as regras derivadas de benchmarks funcionam melhor neles, mas ainda deixam lacunas.
• Utilidade vs. Segurança: A adição das regras de segurança não degradou significativamente a capacidade do agente de realizar tarefas benignas (queda média de ~5% na taxa de sucesso), validando que as descobertas de falhas não são apenas "recusa indiscriminada".

5. Significado e Conclusão

O trabalho demonstra que passar em um benchmark de segurança não garante segurança real. Os benchmarks atuais tendem a capturar falhas óbvias e esperadas, deixando de fora padrões de interação estruturalmente complexos e sutis.

• Implicação Prática: O SafeAudit serve como uma ferramenta essencial de meta-auditoria para desenvolvedores e pesquisadores avaliarem a completude de seus conjuntos de testes antes de implantar agentes.
• Futuro: O trabalho sugere que a segurança de agentes deve evoluir de uma avaliação baseada apenas em benchmarks fixos para uma auditoria contínua que mapeia sistematicamente o espaço de interações inseguras, utilizando os padrões descobertos para melhorar o treinamento e as defesas dos agentes.

Em resumo, o artigo responde à pergunta "Quem testa os testadores?" propondo um método sistemático para expor as lacunas de cobertura dos testes atuais, revelando que uma parcela significativa de riscos estruturais permanece invisível para os métodos de avaliação convencionais.