Omission Constraints Decay While Commission Constraints Persist in Long-Context LLM Agents

Título: Restrições de Omissão Decaem Enquanto Restrições de Comissão Persistem em Agentes LLM de Longo Contexto

1. O Problema: Divergência Segurança-Recall (SRD)

Os agentes de LLM (Large Language Models) em produção operam sob políticas comportamentais definidas por operadores (instruções no system prompt), como proibições de revelar credenciais, vazar dados ou executar código não confiável. A premissa de segurança atual assume que essas restrições se mantêm válidas ao longo de toda a conversa.

O artigo identifica uma assimetria crítica chamada Divergência Segurança-Recall (Security-Recall Divergence - SRD):

• Restrições de Comissão (Requisitos): Instruções que exigem que o modelo faça algo (ex: "incluir um ID de incidente", "começar com STATUS:"). Estas tendem a persistir mesmo em contextos longos.
• Restrições de Omissão (Proibições): Instruções que exigem que o modelo não faça algo (ex: "nunca use marcadores", "nunca revele senhas"). Estas decaem rapidamente à medida que a profundidade do contexto aumenta.

O Risco: Um agente pode parecer seguro porque os sinais de auditoria (comissões) permanecem verdes (100% de conformidade), enquanto as restrições de segurança críticas (omissões) já falharam silenciosamente. Isso cria uma "Zona de Exploração" onde um adversário pode induzir violações sem disparar alertas.

2. Metodologia

O estudo foi conduzido como um experimento causal de três braços, envolvendo 12 modelos de 8 provedores diferentes, gerando 4.416 ensaios em seis profundidades de conversa (turnos 5, 10, 13, 16, 20, 25).

• Cenário: Um cenário sintético de depuração DevOps onde o modelo interage com ferramentas e um documento de política de segurança.

• Estrutura das Restrições: 8 regras comportamentais (3 de comissão, 5 de omissão) verificadas via correspondência de strings (regex), garantindo medição determinística.

• Os Três Braços do Experimento:

  1. Braço A (Controle sem Diluição): Apenas as ferramentas base. Isola o efeito da profundidade da conversa.
  2. Braço B (Diluição por Esquema - Ataque CEI): Adiciona 20 esquemas de ferramentas de infraestrutura em nuvem (aprox. 10.000 tokens) ao contexto. Simula um ataque de "Esgotamento de Contexto" (Context-Exhaustion Injection) onde um adversário registra ferramentas legítimas para empurrar a política de segurança para fora da "janela de atenção" efetiva.
  3. Braço C (Preenchimento Token-Matched): Substitui os esquemas complexos por conteúdo semântico neutro de tamanho similar. Serve para distinguir se o decaimento é causado pelo volume de tokens ou pelo conteúdo semântico (complexidade) dos esquemas.

• Métricas Principais:

  • Taxa de Conformidade: Porcentagem de ensaios onde a regra foi seguida.
  • Profundidade de Turno Segura (Safe Turn Depth - STD): O turno onde a conformidade cai abaixo de 50%.
  • Testes Estatísticos: Teste de Cochran-Mantel-Haenszel (CMH) e regressão logística para validar a assimetria.

3. Resultados Principais

• Decaimento Assimétrico:

  • Em modelos suscetíveis (ex: Mistral Large 3, Qwen 3.5, Nemotron), a conformidade com restrições de omissão (ex: "não usar marcadores") caiu drasticamente: de 73% no turno 5 para 33% no turno 16 (Mistral Large 3).
  • Simultaneamente, a conformidade com restrições de comissão (ex: "incluir ID") permaneceu em 100% ao longo de todos os turnos.
  • Gemma 4 31B atuou como um "controle imune", mantendo conformidade quase total em ambos os tipos, sugerindo que a vulnerabilidade não é universal e depende da arquitetura ou regime de treinamento.

• Causa do Efeito (Diluição Semântica vs. Volume):

  • No Braço C, o preenchimento neutro (apenas volume de tokens) não causou o mesmo decaimento que os esquemas semânticos complexos.
  • Em modelos testados com o Braço C (Gemini 2.5 Flash e Llama 3.3 70B), o conteúdo semântico dos esquemas foi responsável por 62% a 100% do efeito de diluição. O volume de tokens sozinho não explica a falha; a complexidade semântica compete mais agressivamente pela atenção do modelo.

• Independência da Dificuldade:

  • Restrições de comissão "difíceis" (ex: incluir um ID específico) mantiveram-se estáveis, enquanto restrições de omissão "difíceis" (ex: não usar marcadores) falharam. Isso prova que o decaimento não é devido à carga cognitiva ou dificuldade da tarefa, mas sim ao tipo de restrição (proibição vs. requisito).

• Ataque Context-Exhaustion Injection (CEI):

  • O estudo demonstra que um adversário não precisa injetar instruções maliciosas. Basta registrar ferramentas legítimas (via MCP ou canais de API) para aumentar o contexto e diluir a atenção sobre as políticas de segurança, fazendo o modelo violar proibições sem perceber.

4. Contribuições Chave

1. Descoberta da Assimetria (SRD): Evidência empírica de que avaliações de segurança tradicionais (que geralmente testam em um único turno ou agregam tipos de restrição) falham em detectar que proibições se degradam enquanto requisitos permanecem intactos em conversas longas.
2. Evidência Causal: O desenho de três braços isolou o conteúdo semântico como o principal motor da diluição, refutando a ideia de que apenas o "número de tokens" é o culpado.
3. Métrica Acionável (STD): Introdução da Profundidade de Turno Segura (Safe Turn Depth), um limite prático para operadores.
   • Exemplo: Para o Mistral Large 3, o STD é ~10,6 turnos. Após esse ponto, a conformidade com proibições torna-se não confiável.
4. Mitigações Práticas:
   • Re-injeção Periódica: Reenviar as restrições de omissão no system prompt a cada $k$ turnos (onde $k < STD$) para "resetar" a distância de atenção.
   • Limites de Orçamento de Tokens: Encerrar sessões quando o total de tokens acumulados atingir o limite calculado pelo STD.

5. Significado e Implicações

• Falha Invisível: Sistemas de monitoramento que dependem de sinais de auditoria (comissões) podem não detectar violações de segurança (omissões) em sessões longas, criando uma falsa sensação de segurança.
• Vulnerabilidade Universal: O ataque CEI funciona sem payload malicioso, explorando apenas a arquitetura de atenção dos modelos. Isso afeta pipelines de DevOps, atendimento ao cliente e fluxos de trabalho empresariais que operam em dezenas ou centenas de turnos.
• Limitações Atuais dos Benchmarks: Ferramentas como AgentDojo ou FollowBench testam interações curtas (1-3 turnos) e não capturam esse decaimento passivo.
• Solução Imediata: Não é necessário re-treinar os modelos. Operadores podem implementar mitigação imediata monitorando a profundidade da conversa e re-injetando políticas de segurança periodicamente.

Conclusão: O artigo alerta que a segurança de agentes LLM em produção é frágil em contextos longos. A capacidade de um modelo de "fazer o que é pedido" (comissão) não garante que ele "não fará o que é proibido" (omissão) após um certo tempo de interação. A comunidade de segurança deve adaptar suas avaliações para testar a persistência de proibições em conversas de longo prazo.