Resumo Técnico: Invariantes de Segurança para Agentes que Orquestram Transições de Estado Irreversíveis

Declaração do Problema

Agentes autônomos baseados em planejadores probabilísticos (LLMs) são cada vez mais incumbidos de produzir efeitos irreversíveis em sistemas externos, como transferir fundos em livros contábeis públicos, escrever em armazenamento durável ou atuar em hardware. Estruturas existentes (ex: ReAct, Reflexion, MCP) otimizam o sucesso da tarefa em benchmarks, mas ignoram amplamente a segurança dos efeitos colaterais irreversíveis.

O desafio central é que uma camada de tempo de execução não pode determinar definitivamente se uma transição gerada representa fielmente uma intenção de usuário em linguagem natural (o problema do "mapeamento de intenção"). No entanto, o artigo argumenta que, embora o mapeamento de intenção seja um problema não resolvido, a execução dessa intenção pode ser estritamente controlada. Sem tais controles, os agentes sofrem de modos de falha específicos:

• Nível de RPC: "Sucesso fantasma" (RPCs retornando hashes que são posteriormente retirados) ou "Falha fantasma" (transações legítimas que ocorrem, mas são reportadas como falhas devido a janelas de verificação curtas).
• Nível de LLM: "Deriva de contexto estagnado" (stale-context drift), onde agentes repetem conclusões desatualizadas (ex: "o usuário não possui conta") mesmo após a mudança na verdade fundamental (ground truth).
• Nível de Exchange/API: "Deriva de atomicidade documentada", onde ações especificadas como atômicas (ex: cancelar e substituir) executam apenas parcialmente após uma rejeição, deixando os usuários em estados inseguros.
• Operacional: Entregas duplicadas e seleções de carteira mal mapeadas que levam a gastos duplos (double-spends) não pretendidos.

Metodologia e Formalismo

Espaço de Estado Quadridimensional

O artigo formaliza operações de carteira como transições de estado em um espaço quadridimensional $S = W \times C \times A \times P$:

• $W$ (Wallet/Carteira): O mnemônico/semente que controla os fundos.
• $C$ (Chain/Cadeia): A rede blockchain.
• $A$ (Address/Endereço): O endereço específico naquela cadeia.
• $P$ (Protocol/Protocolo): O token, contrato ou conta off-chain específico (ex: USDC na Arbitrum vs. perp-USDC na Hyperliquid).

Uma transição $\tau$ é uma função parcial que modifica saldos em um conjunto limitado de quadruplas. Crucialmente, o formalismo trata a Carteira ($W$) como uma coordenada fixa para uma única transição. Isso permite que o sistema distingua entre "fundos insuficientes" (uma falha de verificação de estado válida) e "seleção de carteira errada" (um erro fatal onde o agente escolheu o $W$ incorreto), uma distinção perdida em modelos de menor dimensão.

Fidelidade de Execução

O artigo define Fidelidade de Execução como a garantia de que, para qualquer sessão $\sigma$, o efeito realizado no livro contábil, $real(\sigma)$, é:

1. Nada ($\emptyset$), ou
2. Exatamente a transição $\tau_p$ que foi apresentada ao usuário, exatamente uma vez.

O teorema explicitamente não afirma que $\tau_p$ corresponde à intenção de linguagem natural do usuário. Em vez disso, ele reduz a questão semântica ilimitada de "o agente entendeu?" para uma verificação delimitada e decidível: "a tupla de quatro coordenadas e o valor correspondem ao que foi prévia de visualização?".

Os Sete Invariantes de Segurança

Derivados via análise de caso da condição de fidelidade (prevenindo execução não renderizada, execução duplicada e execução derivada mas diferente), o sistema impõe sete invariantes:

1. Portão de Confirmação (Executor-local): Nenhuma chave de assinatura é derivada até que uma confirmação explícita seja registrada contra uma tupla de transição renderizada. Isso força o sistema a se comprometer com um único ponto em $S$ antes de etapas irreversíveis.
2. Suficiência de Pré-estado (Executor-local): Uma verificação de saldo de verdade fundamental (ignorando caches de consistência eventual) é realizada imediatamente antes da assinatura para garantir que a transição seja aplicável no momento da transmissão (broadcast).
3. Observabilidade de Pós-estado (Executor-local): Se um resultado de transmissão não puder ser observado dentro de uma janela delimitada, o sistema reporta "incerteza" em vez de "falha" para evitar gatilhos falsos para tentativas de repetição (retries).
4. Sem Sucesso Fantasma (Executor-local): Uma transação nunca é reportada como bem-sucedida a menos que sua existência na cadeia seja verificada por um indexador ou RPC.
5. Delegação Escopada (Cross-tier): Chamadores não humanos (avatars) operam sob conjuntos de escopo explícitos (ex: {transfer}) derivados de tokens de delegação. O executor admite chamadas apenas se o escopo cobrir a transição necessária, desacoplando autenticação de autorização.
6. Segurança de Repetição de Nível de Plano (Nível de Plano): Avatares não podem reemitir uma transição irreversível em caso de falha reportada/incerteza até que tenham verificado positivamente via estado de verdade fundamental se o efeito da transição está ausente.
7. Receptor de Intenção Idempotente (Receptor HTTP): Intenções externas chegando por canais de entrega "pelo menos uma vez" (at-least-once) são deduplicadas através do hash do ID do remetente e dos bytes da requisição, garantindo que uma única intenção de usuário produza uma única tupla de transição.

Principais Contribuições

1. Redução Formal de Risco: O artigo prova que, sob um modelo de falha que admite erro de mapeamento do planejador, resultados ambíguos e tentativas de repetição, os sete invariantes confinam todo o risco residual ao único predicado de mapeamento de intenção. Todos os outros modos de falha são forçados a gerar nenhum efeito.
2. Derivação de Invariantes: Ao contrário de trabalhos anteriores que enumeram regras de segurança por experiência, estes invariantes são derivados logicamente da definição de fidelidade de execução, garantindo completude em relação ao modelo de falha definido.
3. Arquitetura de Múltiplos Níveis: O artigo descreve o cryptitalk-wallet, um sistema implantado com um nível de Avatar (agentes persistentes agindo em nome dos usuários) e um nível de Executor (o serviço de carteira). A arquitetura trata avatares e humanos como chamadores intercambiáveis do ponto de vista do executor, protegidos por tokens de delegação escopados.
4. Argumento Metodológico sobre Avaliação: O artigo argumenta que as avaliações de segurança são altamente dependentes do "modelo de suporte" (o LLM). O valor de uma pilha de segurança é uma função da agressividade inerente do modelo; avaliar uma pilha em um único modelo é "próximo de ser infalsificável".

Resultados Empíricos

Suíte Adversária Controlada ($N=60$)

O sistema foi avaliado contra uma suíte de prompts adversários rotulados visando as classes de falha identificadas através de quatro modelos de suporte:

• Modelos de Escrita Agressiva (Claude, MiniMax): A pilha completa de invariantes elevou a taxa de aprovação em ~74 pontos percentuais sobre uma abordagem ReAct de linha de base (ex: 81,7% vs. 10,2% para o Claude).
• Modelo de Escrita Cautelosa (Gemini): A pilha elevou a taxa de aprovação em apenas ~3 pontos (60,0% vs. 56,7%), pois o próprio modelo recusou ferramentas de escrita em prompts ambíguos.
• Estudos de Ablação: Desativar os invariantes de portão de código (I1, I3, I5, I6, I7) fez com que as taxas de aprovação colapsassem para quase zero em classes de falha específicas, confirmando que cada portão é essencial. As ablações de nível de ferramenta (I2, I4) mostraram impactos menores, pois o raciocínio do agente absorveu a remoção de ferramentas individuais.

Implantação em Produção

O sistema realizou 108 operações de escrita em produção através de 8 cadeias e 8 primitivas de transição.

• Taxonomia de Falhas: O registro de implantação validou a taxonomia de falhas, com incidentes observados para "Sucesso fantasma", "Bypass de portão de prévia", "Seleção de carteira errada" e "Entrega duplicada de webhook".
• Frota de Avatares: Em uma frota de 87 execuções de DCA (Dollar Cost Averaging), 32% tiveram sucesso, 32% foram escaladas para humanos, 24% apresentaram erro (corretamente reportado) e 11% foram abortadas. Crucialmente, nenhuma transição on-chain duplicada ocorreu no período pós-implantação do Invariante-6, contrastando com um estudo de caso pré-implantação onde uma "falha fantasma" levou a um gasto duplo realizado de 400 USDT.

Significância e Alegações

O artigo afirma que a fidelidade de execução é uma propriedade de segurança tratável para agentes autônomos agindo sobre estados irreversíveis, mesmo quando o mapeamento de intenção permanece não resolvido. Ao formalizar o espaço de estado e derivar invariantes a partir de primeiros princípios, o sistema garante que, se um agente agir, ele agirá exatamente como previsto, exatamente uma vez.

A significância reside em:

1. Redução de Risco Ilimitado: Converter o problema infinito de "o agente entendeu?" em uma comparação finita e verificável de uma tupla de quatro coordenadas.
2. Implantação Prática: Demonstrar que garantias formais podem ser implementadas em um sistema de carteira multichain real lidando com fundos de produção.
3. Rigor de Avaliação: Destacar que as camadas de segurança não podem ser avaliadas isoladamente do comportamento do LLM subjacente, defendendo o modelo de suporte como uma variável experimental de primeira classe.

O artigo reconhece explicitamente as limitações: a garantia para no "caso não assistido" (onde verificações de escopo substituem a confirmação humana), a supressão de duplicatas é limitada no tempo ($\Delta$), e o sistema não fornece atomicidade para planos de múltiplos passos (apenas consistência de prefixo). Não pretende resolver MEV, bugs de contratos inteligentes ou comprometimento de chaves, focando estritamente na superfície de orquestração do agente.