Protocolo propõe prova verificável de autoridade para bloquear transações de pagamento não autorizadas por agentes de IA
O artigo descreve o ChainIT Authority Protocol, um esquema que gera evidência verificável e vinculada à transação de que quem está executando um pagamento — humano, organização ou agente de IA — realmente detém autoridade vigente para aquilo, sob as políticas, orçamento e aprovações em vigor no momento exato. A motivação central é o risco crescente de "comércio agentico": um agente de software pode assinar uma transação de forma criptograficamente válida mesmo agindo fora do que foi delegado, após mudança de política, ou com detalhes diferentes dos aprovados por um humano. O protocolo amarra cada decisão a um resumo canônico da transação e só libera a execução por meio de uma credencial de uso único consumida no adaptador do trilho de pagamento (ACH, TED/wire, cartão, pagamento instantâneo, stablecoin).
Este é um problema de fraude de autorização que vai ficar mais comum à medida que empresas delegam pagamentos a agentes de IA: a validação criptográfica de uma assinatura ("esse agente tinha a chave certa") não responde à pergunta que realmente protege contra fraude, que é "esse agente tinha permissão para fazer exatamente esta transação, agora, dentro deste orçamento e desta política". É o mesmo buraco explorado hoje em fraudes de BEC contra humanos — um e-mail aparentemente legítimo autoriza uma transferência fora do processo normal — só que, com agentes autônomos, o volume e a velocidade de erros ou abusos podem escalar muito mais rápido do que uma revisão humana consegue acompanhar.
A solução proposta separa várias camadas que hoje costumam estar misturadas ou implícitas: identidade duradoura do agente/organização, um registro versionado de autoridade (quem pode aprovar o quê, até que valor, sob qual escopo), evidências de origem (sourced evidence), regras de política determinísticas e codificadas por motivo, e uma camada de disposição configurada pela organização. Cada decisão e cada aprovação humana são amarradas a um "digest" canônico da transação específica — não a uma autorização genérica — e a capacidade (limite de gasto, orçamento) é reservada atomicamente para evitar que duas transações concorrentes consumam o mesmo limite duas vezes. A execução só acontece com uma credencial de autorização de uso único, vinculada ao remetente, consumida no ponto de adaptação com o trilho de pagamento, e todo o histórico de decisão é selado de forma append-only (não pode ser reescrito) após o resultado final.
Na prática isso ataca diretamente um vetor de fraude que cresce junto com a automação: transações aprovadas tecnicamente, mas fora de contexto de negócio. Um agente de compras automatizado que "vaza" autoridade por escopo mal definido, ou que continua operando com um orçamento antigo depois que a política mudou, pode produzir perdas financeiras sem que exista nenhum ataque externo — o problema é a ausência de controle de autoridade em tempo real e auditável. É equivalente, em essência, a um controle antifraude de "quarto olho" tradicional, mas desenhado para operar na velocidade e na escala de agentes de software.
Para quem constrói ou avalia controles antifraude em pagamentos agentic (seja em stablecoins, PIX-like rails ou cartão), os pontos de atenção práticos são: exigir que toda autorização seja amarrada criptograficamente ao conteúdo exato da transação (e não apenas à identidade de quem assina); tratar limites e orçamentos como recursos reservados atomicamente, não verificados apenas após o fato; e manter trilha de auditoria imutável que amarre a aprovação humana original ao resultado final, para suportar investigação de fraude e chargeback quando algo sai errado.