Resumo Técnico: Autoridade Temporária, Efeitos Permanentes

1. Declaração do Problema

Agentes de Grandes Modelos de Linguagem (LLMs) frequentemente operam em ambientes mutáveis onde a autoridade para realizar uma ação é derivada de evidências temporárias (ex: um snapshot do DOM, um token de aprovação, uma testemunha de versão ou um resultado de worker). Existe uma lacuna de segurança crítica quando um agente realiza um efeito durável (como um pagamento, atualização de ticket ou implantação) baseado em uma evidência de autoridade que era válida no momento da observação, mas que expirou, mutou ou foi substituída antes que o commit ocorra.

As métricas de avaliação atuais focam no sucesso do endpoint — se o estado final visível corresponde ao objetivo do usuário. No entanto, o sucesso do endpoint é uma métrica de segurança insuficiente porque um agente pode completar uma tarefa com sucesso usando uma autoridade obsoleta. Por exemplo, uma página de pagamento pode sofrer um repaint ou um epoch de sessão pode avançar enquanto o agente está raciocinando, fazendo com que o agente realize um commit para um alvo que não é mais o que foi originalmente aprovado. Este artigo define este modo de falha como um commit não autorizado: um efeito durável que se externaliza após o caminho de licenciamento ter perdido o direito de concessão.

O problema é mais amplo do que as falhas clássicas de Time-of-Check/Time-of-Use (TOCTOU). Em fluxos de trabalho de agentes, o "objeto verificado" é frequentemente não o alvo final, mas um artefato intermediário (um plano, um alvo em cache ou um resultado delegado) que carrega a autoridade através de estado derivado. Se a testemunha original (ex: um token de branch ou epoch de aprovação) tornar-se inválida, o estado derivado ainda pode parecer plausível, levando a um commit que viola o limite de segurança.

2. Metodologia

Os autores introduzem uma suíte de invalidação controlada para medir a divergência entre o sucesso do endpoint e a conclusão autorizada.

Design Experimental

• Matriz de Tarefas: Uma matriz primária de 54 tarefas abrangendo três famílias: Browser (interações de UI), Tool/State (APIs, tickets, repositórios) e Multi-Agent (orquestração, memória compartilhada).
• Perturbações: Cada tarefa inclui um controle limpo e quatro perturbações temporais não guardadas. As perturbações são eventos de tempo de execução (ex: repaint do DOM, reordenação de callback, cancelamento de branch, avanço de versão) que invalidam a testemunha de autoridade após a observação, mas antes do commit durável.
• Restrições: O objetivo do usuário, o formato do payload e a dificuldade nominal da tarefa permanecem fixos. Apenas a relação de direito de concessão (entitlement) muda.
• Métricas de Avaliação:
  • Sucesso do Endpoint: O agente alcançou o objetivo visível?
  • Conclusão Autorizada: O agente alcançou o objetivo e manteve autoridade válida (frescor, prioridade causal, vinculação de efeito e elegibilidade) no momento do commit?
  • Commit Não Autorizado: O agente realizou um commit de um efeito durável após o caminho de autoridade ter falhado?
  • Não Conclusão Segura: O sistema abortou ou replanejou ao detectar a perda de autoridade?

Modelo Teórico

O artigo define a Autorização no Momento do Commit baseada em quatro condições que devem ser mantidas na fronteira de durabilidade:

1. Frescor (Freshness): A testemunha que licencia o efeito é atual.
2. Prioridade Causal: Todos os predecessores necessários foram concluídos sem dependências não resolvidas.
3. Vinculação de Efeito (Effect Binding): A testemunha ainda nomeia exatamente o alvo, versão ou instância sendo modificada.
4. Elegibilidade de Commit: O caminho de autorização (branch, epoch de aprovação) ainda está ativo e não foi revogado.

3. Principais Contribuições

1. Definição de Commit Autorizado: O artigo define formalmente o commit autorizado para agentes onde o estado derivado carrega autoridade temporária através de uma fronteira de durabilidade.
2. Verificações de Fronteira: Identifica quatro verificações específicas de tempo de execução (frescor, prioridade causal, vinculação de efeito, elegibilidade) e a evidência necessária para verificá-las.
3. Medição de Lacuna Empírica: Através de uma suíte de 54 tarefas (270 execuções), os autores demonstram que o sucesso do endpoint é um substituto (proxy) ruim para a autorização.
4. Mitigação e Monitoramento: O artigo avalia famílias de mitigação e introduz o COMMITGUARD, um monitor de fronteira de falha fechada (fail-closed) que bloqueia tentativas de efeitos duráveis obsoletos quando sinais de tempo de execução indicam invalidação.

4. Resultados

Os resultados primários da matriz não guardada de 270 execuções revelam uma divergência acentuada entre utilidade e segurança:

• Sucesso do Endpoint: Alto em todas as famílias.
  • Browser: 89/90 execuções (98,9%)
  • Tool/State: 83/90 execuções (92,2%)
  • Multi-Agent: 90/90 execuções (100%)
  • Total: 262/270 execuções (97,0%) alcançaram o objetivo visível.
• Conclusão Autorizada: Significativamente menor.
  • Browser: 19/90 execuções (21,1%)
  • Tool/State: 18/90 execuções (20,0%)
  • Multi-Agent: 18/90 execuções (20,0%)
  • Total: 55/270 execuções (20,4%) foram autorizadas.
• Commits Não Autorizados: 207 de 270 execuções (76,7%) realizaram commits de efeitos duráveis após o caminho de autorização ter falhado.
  • Nas 216 linhas de invalidação, 207 resultaram em commits não autorizados.
  • Todos os 54 controles limpos permaneceram autorizados.
• Modos de Falha:
  • Browser: Principalmente "Alvo de browser errado ou obsoleto" (70 casos) devido a repaints do DOM ou retargeting.
  • Tool/State: Principalmente "Escrita de ferramenta revogada ou obsoleta" (65 casos) devido a aprovações expiradas ou incompatibilidades de versão.
  • Multi-Agent: Principalmente "Caminho de agente inelegível ou reordenado" (72 casos) devido a cancelamentos de branch ou reordenação de callback.

Análise de Mitigação:

• Cautela via Prompt & Verificações de Condição Única: Insuficientes. Eles falham em cobrir todas as classes de perigo (ex: a revalidação ajuda no drift de repaint, mas perde o drift de aprovação).
• COMMITGUARD: Um monitor de fronteira de falha fechada que impõe as quatro verificações. Quando ativo, ele converte commits não autorizados em abortos guardados (não conclusão segura).
  • Em modo de aplicação, os commits não autorizados caíram para 0 nas comparações correspondentes.
  • O trade-off é uma redução no sucesso do endpoint (utilidade) quando a autoridade não pode ser restaurada, mas isso garante a segurança.

5. Significância e Alegações

O artigo alega que o sucesso do endpoint é uma métrica de utilidade, enquanto o commit autorizado é uma propriedade de segurança.

• Implicação de Segurança: Avaliações de agentes atuais são tecnicamente incorretas para ambientes mutáveis porque confundem "conclusão de tarefa" com "execução segura". Um agente pode completar uma tarefa com sucesso enquanto realiza uma ação não autorizada (ex: atualizando o ticket errado ou realizando um commit em uma branch revogada).
• Design de Tempo de Execução: A segurança requer um monitor de fronteira que rastreie a procedência da autoridade da testemunha até o estado derivado e, finalmente, ao efeito durável. Os sistemas não devem confiar apenas no estado final; eles devem verificar se o caminho para esse estado permaneceu válido no momento do commit.
• Princípio de Falha Fechada (Fail-Closed): Quando a evidência de autoridade estiver ausente, obsoleta ou incompatível, o sistema deve abortar ou reportar o efeito como não observável em vez de prosseguir. A recuperação (replanejamento com novas testemunhas) é secundária ao bloqueio do commit obsoleto.
• Padrão de Relatório: Avaliações futuras devem reportar conclusão autorizada, commit não autorizado e não conclusão segura separadamente do sucesso do endpoint para avaliar a segurança do agente com precisão.

Os autores concluem que a lacuna entre o sucesso do endpoint e a conclusão autorizada é impulsionada pela invalidação temporal, não pela dificuldade da tarefa, e que resolver isso requer a aplicação de condições de fronteira em nível de tempo de execução, em vez de apenas melhorar o prompting ou as capacidades do modelo.