💻 computer science

Free-Riding in the AI Economy: Demystifying Logic Flaws in x402-Enabled Payment Systems

Este artigo apresenta a primeira análise de segurança abrangente do protocolo x402, revelando vulnerabilidades críticas, como lacunas no design de assinaturas e condições de corrida que permitem o "free-riding" e o vazamento de recursos em sistemas de pagamento impulsionados por IA, e propõe mitigações arquitetônicas para proteger transações máquina-a-máquina.

Autores originais: Shengchen Ling, Yihang Huang, Yuan Chen, Yajin Zhou, Lei Wu, Cong Wang

Publicado 2026-06-01

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Shengchen Ling, Yihang Huang, Yuan Chen, Yajin Zhou, Lei Wu, Cong Wang

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine um mercado digital movimentado onde robôs (agentes de IA) estão comprando e vendendo serviços uns dos outros em uma velocidade vertiginosa. Eles não têm caixas ou gerentes humanos; eles apenas conversam entre si e trocam moedas digitais instantaneamente. Para fazer isso funcionar, um novo sistema chamado x402 foi inventado. É como uma placa universal de "Pague para Entrar" que os robôs podem ler e obedecer automaticamente.

No entanto, este artigo é um relatório de segurança que diz: "As fechaduras deste mercado estão quebradas."

Os pesquisadores descobriram que, como o sistema tenta ser rápido demais e flexível demais, ele criou um "vão" entre o momento em que um robô diz que vai pagar e o momento em que o dinheiro realmente chega. Esse vão permite que atores mal-intencionados enganem o sistema para obter trabalho de graça.

Aqui está um detalhamento das quatro principais formas como esse "Free-Riding" (uso gratuito) acontece, usando analogias simples:

1. O Problema do "Ingresso Errado" (Substituição de Recurso Cruzado)

A Analogia: Imagine que você compra um ingresso para um filme chamado Matrix. O ingresso diz: "Uma entrada, $10". Mas o segurança do cinema verifica apenas o preço ($10) e não o título do filme.
A Falha: Um hacker compra um ingresso para o filme barato (Matrix), mas caminha até a entrada da área VIP do filme caro (Duna). O segurança vê o ingresso de $10, assente com a cabeça e o deixa entrar.
A Realidade: No sistema x402, a "assinatura" digital que um robô usa para pagar não diz estritamente qual serviço específico ele está pagando, apenas quanto e para quem. Um hacker pode pegar uma prova de pagamento válida para uma chamada de API barata e usá-la para desbloquear um serviço de IA premium e caro. O sistema aceita o dinheiro, mas entrega o produto errado (e mais valioso).

2. O Problema da "Reserva Dupla" (Duplicação de Serviço Probabilística)

A Analogia: Imagine um hotel com uma recepção muito lenta. Você se aproxima e diz: "Eu tenho uma reserva". O funcionário verifica o computador, vê que seu nome está limpo e diz: "Ótimo, vá para o seu quarto!"
Enquanto o funcionário ainda está digitando o check-in no livro de registros principal, você corre de volta à recepção com um amigo e diz: "Eu também tenho uma reserva!". Como o funcionário ainda não terminou de digitar a primeira, o computador ainda parece "limpo" para a segunda pessoa. Ambos conseguem uma chave de quarto, mas o hotel só cobrou você uma vez.
A Falha: O sistema x402 verifica se um pagamento é válido (a "verificação"), mas não bloqueia imediatamente a transação para que ninguém mais possa usá-la (o "bloqueio"). Um hacker pode enviar o mesmo pedido de pagamento 20 vezes em uma fração de segundo. O servidor, movendo-se rápido, diz "Sim" para todos os 20 pedidos antes que o blockchain (o livro de registros principal) tenha tempo de dizer: "Espere, esse pagamento já foi usado!" O comerciante entrega 20 serviços, mas recebe o pagamento de apenas um.

3. O Problema do "Cheque em Branco" (Estouro de Limite de Verba)

A Analogia: Imagine que você dá a um garçom um cartão de crédito com um limite de $100 e diz: "Peça o que quiser, só não passe de $100". O garçom começa a pedir bifes caros.
O problema é que o garçom pede 10 bifes antes que o banco tenha tempo de verificar se você realmente tem o dinheiro. Quando o banco tenta cobrar o cartão, você já gastou $500. O banco rejeita a cobrança, mas o garçom já serviu a comida. Você recebe a comida de graça; o restaurante arca com o custo.
A Falha: No mundo da IA, o custo de uma tarefa não é conhecido até que ela seja concluída. Hackers configuram um "limite de gastos" (allowance) que é apenas o suficiente para passar em uma verificação rápida. Eles então disparam tarefas de IA massivas e caras. O sistema começa o trabalho imediatamente (porque a verificação passou), mas quando a conta final é calculada, o hacker gastou mais do que seu limite. O blockchain rejeita o pagamento, mas a IA já realizou o trabalho.

4. O Problema do "Engarrafamento" (Negação de Liquidação)

A Analogia: Imagine um pedágio que pode processar apenas 10 carros por minuto. Um hacker envia 50 carros pelo portão de uma só vez. O portão abre para todos os 50 porque a verificação de "entrada" é rápida. Mas quando os carros tentam pagar na cabine ao final, a cabine está sobrecarregada e só consegue processar 10. Os outros 40 carros vão embora sem pagar.
A Falha: O sistema tem um limite de quantos pagamentos pode processar por segundo. Hackers inundam o sistema com requisições. O servidor entrega o serviço para todos eles porque a "entrada" é rápida, mas o lado do "pagamento" fica congestionado. O servidor acaba entregando serviços gratuitos porque não consegue processar os pagamentos rápido o suficiente para dizer "Não".

O Panorama Geral: Por Que Isso Importa

O artigo argumenta que o sistema x402 está tentando fazer duas coisas que não se misturam bem:

Velocidade da Web: Interações instantâneas de "confie em mim" (como requisições HTTP).
Segurança do Blockchain: Segurança de "verifique tudo primeiro" (como a finalidade do blockchain).

Ao tentar unir esses dois mundos, o sistema criou um "vão de tempo". Nesse vão, atores mal-intencionados podem se infiltrar.

As Correções Propostas

Os autores sugerem algumas maneiras de corrigir isso, essencialmente dizendo ao sistema para ser mais cuidadoso:

Vincular o ingresso ao assento específico: Garantir que a assinatura digital diga exatamente qual serviço está sendo comprado, não apenas o preço.
Colocar uma placa de "Não Perturbe" no livro de registros: Quando um pagamento está sendo verificado, bloqueie-o imediatamente para que ninguém mais possa usá-lo até que seja confirmado.
Não servir a comida até que o cheque seja compensado: Para tarefas de IA, não transmita os resultados para o usuário até que o pagamento seja realmente confirmado. Se o pagamento falhar, o usuário não recebe nada.
Verificar a capacidade do pedágio: Se o sistema de pagamento estiver muito ocupado para processar uma conta, não deixe o carro entrar de jeito nenhum.

Em resumo: O artigo revela que os "trilhos econômicos" para agentes de IA estão atualmente cheios de buracos onde as pessoas podem roubar serviços. Para consertar isso, precisamos parar de ser tão otimistas sobre os pagamentos e começar a bloquear as coisas com segurança, mesmo que isso torne o processo um pouco mais lento.

Resumo Técnico: Free-Riding na Economia da IA

1. Definição do Problema

A emergência da economia agente-para-agente (A2A) exige trilhos financeiros programáticos capazes de lidar com transações autônomas de alta frequência. O protocolo x402 surgiu como o padrão de fato para pagamentos máquina-para-máquina, utilizando o código de status HTTP 402 "Payment Required" para incorporar instruções de pagamento criptográficas diretamente nas requisições da camada de aplicação.

No entanto, a operacionalização do x402 introduz uma dissonância arquitetônica fundamental: ele tenta unir ciclos de requisição-resposta HTTP síncronos e efêmeros com a finalidade blockchain assíncrona e probabilística. Este artigo argumenta que as implementações atuais do ecossistema x402 falham em impor invariantes de segurança críticos devido a essa lacuna de sincronização de estado. Especificamente, o desacoplamento entre verificação (off-chain) e liquidação (on-chain) cria condições de corrida e ambiguidades semânticas que permitem que atacantes pratiquem o "free-riding" (uso gratuito), forçando os comerciantes a subsidiar custos de computação e expondo o sistema à exploração econômica sistêmica.

2. Metodologia

Os autores empregam um framework de análise de segurança rigoroso, combinando modelagem formal e validação empírica:

Modelagem Formal do Sistema: O fluxo de pagamento é modelado como um sistema de transição de estados envolvendo quatro entidades: Comprador ( $S$ ), Comerciante ( $M$ ), Facilitador ( $F$ ) e Blockchain ( $B$ ).
Invariantes de Segurança: Os autores definem cinco Invariantes de Segurança fundamentais que uma implementação segura deve manter:
1. Integridade de Pagamento (I1): A entrega implica na liquidação confirmada on-chain.
2. Consistência de Valor (I2): O valor da transação deve satisfazer a lógica de precificação do recurso.
3. Vinculação de Contexto (I3): A autorização de pagamento deve estar criptograficamente vinculada ao identificador específico do recurso.
4. Unicidade de Autorização (I4): Um nonce de pagamento deve ser consumido exatamente uma vez.
5. Conservação de Execução (I5): Trabalho computacional significativo não deve ser iniciado a menos que o pagamento esteja garantido.
Análise de Vulnerabilidade: Os autores analisam a especificação do protocolo e auditam os SDKs oficiais (TypeScript, Python, Java, Go) e implementações de middleware ao vivo (Thirdweb, Coinbase).
Validação Empírica: Experimentos controlados foram conduzidos em múltiplas testnets (Base Sepolia, Solana Devnet, Arbitrum Sepolia) e contra implementações oficiais para quantificar as taxas de sucesso dos ataques identificados.

3. Principais Descobertas e Vulnerabilidades

A análise revela que as implementações atuais violam sistematicamente os invariantes definidos, levando a três classes primárias de vulnerabilidades:

A. Substituição de Recurso Cruzado (Violando I3)

Mecanismo: O design do protocolo x402 baseia-se em assinaturas EIP-712 que vinculam fundos a um endereço de comerciante, mas são agnósticas ao contexto em relação ao identificador de recurso específico ( $ID_r$ ).
Falha: Os SDKs oficiais falham em vincular criptograficamente a assinatura ao contexto da requisição HTTP (URI, método, corpo).
Exploit: Um atacante pode gerar uma assinatura de pagamento válida para um recurso de baixo valor ou irrestrito ( $r_A$ ) e substituí-la para acessar um recurso diferente, de alto valor ou restrito ( $r_B$ ), com o mesmo preço.
Resultado: Em experimentos, isso levou a uma taxa de sucesso de 100% em troca de recursos. Em cenários concorrentes, permitiu a "duplicação de serviço", onde um único pagamento desbloqueou múltiplos recursos.

B. Duplicação de Serviço Probabilística (Violando I4)

Mecanismo: Existe uma condição de corrida do tipo Time-of-Check to Time-of-Use (TOCTOU) entre a verificação off-chain de um nonce e sua liquidação on-chain.
Falha: A lógica de verificação do Facilitador é sem estado (stateless) e apenas de leitura; ela não bloqueia o nonce.
Exploit: Um atacante transmite $N$ requisições simultâneas com o mesmo payload assinado. Múltiplas threads do servidor verificam o nonce como "não utilizado" simultaneamente antes que a primeira thread atualize com sucesso o estado da blockchain.
Resultado: O comerciante entrega o serviço $N$ vezes, mas apenas uma transação é liquidada on-chain. Experimentos na Base Sepolia demonstraram uma taxa de sucesso de 6% para duplicação de serviço, representando um risco de arbitragem escalável para agentes de IA de alta frequência.

C. Drifts de Estado Específicos de IA (Violando I2 e I5)

No domínio de inferência de IA, a mudança para precificação dinâmica (usando esquemas de autorização "até" ou "upto") exacerba as vulnerabilidades:

Estouro de Permissão (Allowance Overdraft): Como o custo da inferência de LLM é desconhecido até a conclusão, os comerciantes devem verificar um limite de gastos ( $V_{max}$ $V_{ma x}$ ) em vez de um valor exato. Atacantes exploram a falta de bloqueio atômico na permissão. Ao lançar $N$ $N$ requisições simultâneas onde $\sum v_i \gg V_{max}$ $\sum v_{i} ≫ V_{ma x}$ , o atacante consome recursos para todas as requisições. A blockchain reverte as transações excedentes, mas o comerciante já entregou o output computacional.
- Impacto: Experimentos mostraram uma razão de vazamento ( $\rho$ ) de até 97,76%, o que significa que os atacantes receberam quase 100% dos recursos computacionais enquanto pagavam apenas uma fração do custo.
Negação de Liquidação (Denial of Settlement): Atacantes podem inundar o sistema com requisições válidas que excedem os limites de taxa de liquidação do Facilitador (ex: 10 tx/s). A camada de verificação aceita o surto, e o comerciante entrega o serviço, mas a API de liquidação rejeita as transações excedentes.
- Impacto: Em casos extremos, isso resultou em uma razão de vazamento de 100%, onde o comerciante forneceu o serviço completo por zero pagamento.

4. Mitigações Propostas

O artigo propõe quatro estratégias de defesa hierárquicas para restaurar os invariantes de segurança:

Vinculação de Contexto Criptográfico: Estender os esquemas EIP-712 para incluir um hash da requisição HTTP completa (Método, URI, Corpo) na assinatura. Isso elimina a lacuna semântica, tornando as assinaturas inválidas se forem replicadas contra diferentes recursos.
Linearização de Nonce com Estado (Stateful): Implementar um modelo "Check-and-Set" no nível do Facilitador usando locks distribuídos (ex: SETNX). Isso garante que, mesmo que múltiplas threads verifiquem um nonce, apenas a primeira a adquirir o lock prossiga para a liquidação, eliminando condições de corrida.
Entrega de Recurso Pessimista:
- Entrega Diferida: Armazenar o output de inferência de IA até que a liquidação seja confirmada. Isso neutraliza o incentivo econômico para o roubo (o atacante não recebe os dados se o pagamento falhar).
- Bloqueio de Duas Fases: Para cenários de alto risco, transferir o limite máximo para um contrato de custódia (escrow) antes da execução para atomizar a verificação de permissão.
- Anti-Griefing Criptoeconômico: Exigir que os agentes depositem um "vínculo de gás" (gas bond) para cobrir potenciais reversões de liquidação, confiscando o depósito (slashing) se o agente tentar praticar griefing contra o comerciante.
Design de Falha Fechada (Failure-Closed): Sincronizar os limites de taxa e as verificações de faturamento com a entrada da requisição. Se a capacidade de liquidação for excedida, a requisição deve ser rejeitada imediatamente (429), em vez de ser processada e entregue gratuitamente.

5. Significância e Alegações

O artigo afirma ser a primeira análise de segurança abrangente do ecossistema x402. Sua significância reside em:

Identificação de Risco Sistêmico: Demonstra que a dissonância arquitetônica entre protocolos web e blockchains não é apenas um erro de implementação, mas uma falha estrutural que compromete o modelo de confiança econômica da web agêntica.
Formalização de Invariantes de Segurança: Estabelece um framework formal (os cinco invariantes) necessário para assegurar sistemas híbridos agênticos, fornecendo uma base para o design de protocolos futuros.
Exposição da Ameaça de "Free-Riding": Quantifica como os atuais modelos de precificação dinâmica em IA podem ser usados como arma para forçar comerciantes a subsidiar custos de computação em escala, ameaçando a viabilidade da economia de IA.
Divulgação Responsável: Todos os problemas identificados foram divulgados à Coinbase e à Thirdweb, destacando a necessidade imediata de mudanças arquitetônicas de uma "folga ergonômica" para uma "vinculação criptográfica rigorosa".

Os autores concluem que, sem a adoção de middleware consciente de estado e mecanismos de bloqueio pessimista, a economia da IA corre o risco de construir seu fundamento financeiro sobre trilhos propensos ao free-riding sistêmico.