Arbiter: Detecting Interference in LLM Agent System Prompts

O artigo apresenta o Arbiter, um framework que combina regras de avaliação formal e varredura com múltiplos modelos de linguagem para detectar padrões de interferência em prompts de sistema de agentes de codificação, revelando vulnerabilidades críticas em ferramentas de grandes empresas e demonstrando que a arquitetura do prompt influencia o tipo de falha, mas não sua gravidade.

O essencial

Imagine que os "agentes de IA" (como o Claude Code, o Codex e o Gemini) são como estagiários superinteligentes que você contrata para escrever código para você. Eles são incríveis, mas têm um problema: eles seguem cegamente um "manual de instruções" chamado Prompt de Sistema.

Este manual é o que diz ao estagiário o que fazer, o que não fazer e como se comportar. O problema é que, até agora, ninguém verificava se esse manual fazia sentido. Era como entregar um livro de regras para um piloto de avião onde, na página 10, diz "suba", e na página 50, diz "nunca suba", mas sem ninguém ter lido para ver a contradição. O piloto (a IA) apenas "adivinha" qual regra seguir e segue em frente, silenciosamente.

O artigo "Arbiter" (o Árbitro) é como um detetive de falhas que criou uma nova maneira de ler esses manuais antes que eles causem acidentes.

Aqui está a explicação simples do que eles descobriram:

1. O Problema: Manuais Caóticos

Os autores compararam esses prompts a softwares reais. Se você escreve um código de computador, usa ferramentas para achar erros. Com os prompts de IA, não existe isso.

• A Analogia: Imagine que o prompt é a Constituição do agente. Mas é uma constituição escrita à mão, com rasuras, onde uma seção diz "coma maçãs" e outra diz "nunca coma frutas". A IA não grita "Erro!"; ela apenas decide qual regra seguir naquele momento, o que pode levar a comportamentos estranhos ou perigosos.

2. A Solução: O Detetive "Arbiter"

Os pesquisadores criaram uma ferramenta chamada Arbiter que usa duas estratégias para encontrar esses erros:

• Estratégia 1: O Detetive Rigoroso (Análise Direta)
  Eles quebraram o manual em pedaços e usaram regras estritas para procurar contradições óbvias.

  • Exemplo: "Se a regra A diz 'sempre use X' e a regra B diz 'nunca use X', temos um erro."
  • Eles encontraram 21 erros claros no manual do Claude Code, como instruções conflitantes sobre como salvar tarefas.

• Estratégia 2: O Explorador Curioso (Varredura com Múltiplos Modelos)
  Aqui está a parte genial. Eles pegaram o manual e pediram para vários modelos de IA diferentes (não apenas um) que o lessem e dissessem: "O que você achou de estranho aqui?".

  • A Analogia: É como pedir para 10 detetives diferentes lerem o mesmo caso. Um é especialista em finanças, outro em segurança, outro em psicologia.
  • Eles não queriam que todos concordassem. Eles queriam que cada um trouxesse uma perspectiva única. Um modelo pode notar que o manual gasta dinheiro demais, enquanto outro nota que o manual esquece de salvar a memória do usuário.

3. O Que Eles Encontraram? (Os 3 Tipos de Arquitetura)

Eles analisaram os manuais de três grandes empresas (Anthropic, OpenAI e Google) e descobriram que o formato do manual determina o tipo de erro:

1. O "Monolito" (Claude Code): Um livro gigante e único de quase 1.500 linhas.

   • O Erro: Como é um livro gigante feito por várias pessoas em momentos diferentes, as regras das "capítulos" não conversam entre si. É como uma casa onde o encanador instalou canos que vazam na parede que o eletricista pintou.
   • Resultado: Contradições graves entre tarefas gerais e tarefas específicas.

2. O "Plano" (Codex CLI): Um manual curto e simples.

   • O Erro: É tão simples que não tem muitos erros, mas também não faz muita coisa. É como um carro básico: não quebra, mas não tem ar-condicionado nem rádio.

3. O "Modular" (Gemini CLI): Um manual feito de blocos montados na hora.

   • O Erro: Cada bloco funciona perfeitamente sozinho, mas quando você os junta, eles não se encaixam.
   • A Descoberta Chocante: Eles encontraram um erro onde o sistema de "memória" do agente (onde ele guarda suas preferências) era apagado automaticamente quando o histórico de conversa ficava longo. Era como se você escrevesse um bilhete para si mesmo, e a cada 10 páginas, o livro se fechasse e rasgasse a página onde você escreveu. O Google corrigiu o "sintoma" (o travamento), mas não corrigiu a "causa" (o desenho do livro que rasga a página).

4. O Grande Segredo: Por que usar várias IAs?

Se você usar apenas uma IA para ler o manual, ela vai ver apenas o que ela foi treinada para ver.

• A Analogia: Se você tem um problema de saúde e vai ao médico, ele pode focar no coração. Se você vai a um nutricionista, ele foca na dieta. Você precisa de ambos para ter a imagem completa.
• O estudo mostrou que modelos diferentes encontram tipos de erros completamente diferentes. Um modelo encontrou falhas de segurança, outro encontrou falhas de economia (gasto de tokens), outro encontrou falhas de lógica. Eles se complementam.

5. O Custo: Quase Grátis

A parte mais impressionante é o preço. Analisar esses três manuais gigantes, usando dezenas de modelos de IA diferentes, custou US$ 0,27 (vinte e sete centavos de dólar).

• Isso é menos do que o custo de 3 minutos do salário mínimo nos EUA.
• A mensagem final é: Nós temos a tecnologia para verificar se esses "constituições" de IA estão seguras, e é baratíssimo fazer isso. Mas ninguém está fazendo.

Resumo Final

O artigo diz que os manuais que controlam nossas IAs são como softwares mal escritos, cheios de contradições que ninguém verifica. O "Arbiter" é uma nova ferramenta que usa uma equipe de "detetives de IA" diferentes para encontrar esses erros. Eles descobriram que o jeito como esses manuais são escritos (se são longos, curtos ou feitos de blocos) define que tipo de erro vai acontecer. E o melhor: podemos consertar isso gastando menos de um real.

Resumo técnico

Resumo Técnico: Arbiter – Detecção de Interferência em Prompts de Sistema de Agentes LLM

1. O Problema

Os prompts de sistema que governam agentes de codificação baseados em Grandes Modelos de Linguagem (LLMs), como o Claude Code, Codex CLI e Gemini CLI, são artefatos de software críticos. Eles definem o comportamento, hierarquias de precedência, contratos de ferramentas e gerenciamento de estado do agente. No entanto, diferentemente do software tradicional, esses prompts carecem de infraestrutura de teste (linters, verificadores de tipo, suites de teste).

Quando um prompt contém instruções contraditórias (ex: "SEMPRE use X" em uma seção e "NUNCA use X" em outra), o LLM executor resolve o conflito silenciosamente através de heurísticas de treinamento, sem gerar erros ou avisos. O artigo argumenta que o agente que resolve o conflito não pode ser o agente que o detecta, pois o mesmo mecanismo de "julgamento" que torna os LLMs úteis os torna auditores não confiáveis de suas próprias instruções.

2. Metodologia: O Framework Arbiter

O autores apresentam o Arbiter, um framework de avaliação que combina regras formais com varredura multi-modelo para detectar padrões de interferência. O processo divide-se em duas fases complementares:

A. Avaliação Direcionada (Prompt Archaeology)

Esta fase é exaustiva dentro de seu escopo definido:

1. Decomposição: O prompt é dividido em blocos contíguos classificados por nível (sistema/domínio), categoria (identidade, segurança, fluxo de trabalho), modalidade (mandato, proibição, orientação) e escopo.
2. Aplicação de Regras: Regras formais verificam tipos específicos de interferência, como:
   • Conflitos direto entre mandatos e proibições.
   • Redundância de sobreposição de escopo.
   • Ambiguidade em marcadores de prioridade.
   • Dependências implícitas não resolvidas.
   • Duplicação literal.
3. Pré-filtragem: Reduz o espaço de busca ao considerar apenas pares de blocos que compartilham escopos relevantes.

B. Varredura Indireta (Multi-Model Scouring)

Esta fase aborda lacunas onde não existem regras predefinidas:

1. Design: Um "scourer" (varredor) recebe instruções deliberadamente vagas ("leia com atenção e note o que achar interessante") para evitar viés de auditoria.
2. Composição Multi-passagem: Cada passagem recebe os achados acumulados das passagens anteriores e é instruída a explorar territórios não cobertos.
3. Execução Multi-Modelo: Cada passagem utiliza um LLM diferente (ex: Claude Opus, DeepSeek, Kimi, Grok, etc.). O objetivo não é o consenso, mas a complementaridade: modelos treinados em dados diferentes trazem vieses analíticos distintos.
4. Critério de Parada Convergente: A exploração termina quando três modelos consecutivos declinam em encontrar novos materiais.

C. Análise Estrutural (AST)

Um parser de duas camadas gera uma Árvore de Sintaxe Abstrata (AST) para analisar a estrutura do documento (nós, profundidade, seções) independentemente do conteúdo, permitindo a detecção de clones e diffs precisos entre versões.

3. Corpus de Estudo

A análise foi aplicada a três prompts de sistema de grandes fornecedores:

• Claude Code (Anthropic): 1.490 linhas (Arquitetura Monolítica).
• Codex CLI (OpenAI): 298 linhas (Arquitetura Plana/Flat).
• Gemini CLI (Google): 245 linhas (Arquitetura Modular, composta dinamicamente via TypeScript).

4. Resultados Principais

Descobertas Quantitativas

• Total de Achados: 152 achados da fase de varredura (scouring) e 21 padrões de interferência rotulados manualmente na análise direcionada (apenas no Claude Code).
• Custo: A análise completa de todos os três fornecedores custou $0.27 USD em chamadas de API (menos de 3 minutos de trabalho humano ao salário mínimo dos EUA).

Correlação Arquitetura-Falha

O estudo identifica uma forte correlação entre a arquitetura do prompt e o tipo de falha observada:

1. Monolítico (Claude Code): Produz falhas de "crescimento" nas fronteiras de subsistemas. Exemplo: O subsistema de gerenciamento de tarefas (TodoWrite) faz afirmações universais ("SEMPRE usar") que conflitam diretamente com proibições em fluxos de trabalho específicos (como commits e PRs).
2. Plano/Flat (Codex CLI): Troca capacidade por consistência. Possui menos oportunidades de contradição, mas apresenta falhas estruturais como confusão de identidade e vazamento de detalhes de implementação.
3. Modular (Gemini CLI): Produz falhas de nível de design nas "costuras" da composição. Cada módulo funciona isoladamente, mas os contratos entre eles são inexistentes ou inconsistentes.
   • Exemplo Crítico: O sistema de compressão de histórico deleta estruturalmente preferências salvas (save_memory) porque o esquema XML de compressão não possui um campo para essas memórias. O fornecedor corrigiu um sintoma (loop infinito), mas não a causa raiz estrutural (perda de dados).

Complementaridade Multi-Modelo

A avaliação com múltiplos modelos descobriu classes de vulnerabilidade categoricamente diferentes que a análise de um único modelo não encontraria.

• Modelos como Kimi K2.5 focaram em exploração econômica e exaustão de recursos.
• Modelos como Claude Opus focaram em contradições estruturais e superfícies de segurança.
• A cobertura total é maior do que a soma das partes; os modelos não são redundantes, são complementares.

5. Contribuições e Significado

1. Taxonomia de Falhas: Estabelece uma taxonomia de modos de falha em prompts de sistema baseada em evidências empíricas multi-fornecedor, ligando a estrutura do prompt (monolito, plano, modular) ao tipo de bug.
2. Metodologia de Análise: Propõe uma abordagem híbrida que combina regras direcionadas (para cobertura exaustiva conhecida) com varredura indutiva multi-modelo (para descobrir o desconhecido).
3. Validação Externa: Um bug de design identificado pelo scourer (perda de dados no Gemini CLI) foi confirmado independentemente por um relatório de bug do próprio fornecedor, embora a correção do fornecedor não tenha resolvido a causa raiz estrutural.
4. Viabilidade Econômica: Demonstra que a análise profunda e abrangente de prompts de sistema é acessível a qualquer desenvolvedor, custando centavos de dólar, em contraste com auditorias de segurança tradicionais.
5. Prompt como Software: Reforça a tese de que prompts de sistema são artefatos de software que exigem a mesma infraestrutura de engenharia (linters, testes de integração, CI/CD) que o código tradicional, citando a Lei de Conway: a estrutura do prompt reflete a estrutura da equipe que o produziu.

Conclusão

O artigo conclui que os prompts de sistema são os artefatos de software menos testados, mas mais consequentes, dos sistemas de IA modernos. A falta de verificação de consistência interna permite que contradições persistam, tornando o comportamento do agente imprevisível. O framework Arbiter demonstra que a detecção dessas interferências é viável, barata e essencial, exigindo uma mudança de paradigma onde a análise de prompts se torna uma prática padrão de engenharia de software.