Quem autorizou isto? A zona cinzenta do x402

null

Autor do artigo: David Christopher

Tradução do artigo: Block unicorn

O sucesso do x402 não seria possível sem os integradores nativos. Programas de encapsulamento não autorizados podem transformar potenciais parceiros em adversários.

Na semana passada, a Coinbase lançou o agentic.market, uma plataforma que exibe endpoints do x402, com o objetivo de facilitar a descoberta do ecossistema x402.

Ao navegar no agentic.market, você encontrará acessos em tempo real e sob demanda a diversos serviços, desde ferramentas on-chain até APIs de grande escala. Alguns endpoints são fornecidos diretamente pelos provedores originais. Muitos outros vêm de terceiros: algumas empresas encapsulam APIs existentes em x402 (e/ou MPP) e as empacotam em ferramentas acessíveis por proxy, permitindo que usuários acessem tudo por uma única conexão mediante uma pequena taxa.

A segunda abordagem complica a situação. Entre os endpoints de terceiros exibidos no Agentic Market, estão serviços como Wolfram Alpha, Google Flights e Amadeus (uma plataforma amplamente utilizada de dados de viagens). O motivo pelo qual foco nesses três é que eles não anunciaram integrações x402 e seus termos de serviço indicam que é pouco provável que autorizem terceiros a construir integrações em seu nome.

Cada endpoint indexado no Agentic Market pode ser de primeira parte (fornecido diretamente pelo provedor original), de terceiros autorizados (com permissão explícita, geralmente por meio de certificação formal ou programa de parceiros) ou de terceiros não autorizados (empresas revendendo acesso a APIs pagas sem permissão).

No mercado e em todo o ecossistema x402, não é possível distinguir imediatamente quais endpoints são de primeira parte, quais são de terceiros autorizados ou não autorizados; muitos parecem pertencer à última categoria.

Termos contratuais

Como mencionado, os termos desses três provedores tornam bastante provável que existam acordos não autorizados de terceiros, e em alguns casos, até mesmo que outras opções sejam completamente excluídas.

Wolfram Alpha proíbe explicitamente “revendedores e agregadores”, bem como qualquer forma de scraping ou mineração de dados, além de proibir a venda ou sublicenciamento de seus serviços sem permissão. Esses termos parecem deixar pouco espaço para terceiros autorizados. Além disso, após consultar o guia rápido de início do endpoint, fica claro que essa não é uma integração de primeira parte.

(Termos de serviço da API do Wolfram Alpha proibindo conteúdo)

O contrato de assinatura principal da Amadeus permite apenas o acesso para fins internos de negócios, proibindo qualquer “aluguel, leasing, distribuição, venda, revenda, transferência ou transferência de qualquer forma” de seu acesso. Qualquer conexão de terceiros requer autenticação pela Amadeus e deve ser formalmente registrada por meio de um pedido de serviço. Isso significa que a única maneira de obter autorização de terceiros é por esse caminho, e não é possível verificar externamente se um endpoint existente atende a esses requisitos.

(Restrições no contrato: limitações do contrato de assinatura principal da Amadeus)

A situação do Google é a mais emblemática. O Google Flights não possui uma API pública, e a empresa adota medidas rigorosas de proteção de seus dados.

No entanto, programas de terceiros estão empacotando acessos aos dados do Google Flights, provenientes do SerpApi — uma empresa que o Google está processando ativamente, acusando de fazer scraping de resultados de busca e revender acessos. A acusação do Google afirma que o SerpApi desenvolveu ferramentas para contornar controles de acesso, enviando “milhares de milhões” de requisições falsas por dia para scraping, além de revender conteúdo protegido por direitos autorais embutido nos resultados de busca.

Assim, o Google processou o SerpApi por revenda de conteúdo protegido por direitos autorais e por contornar seus controles de acesso. Enquanto isso, o serviço do SerpApi está sendo encapsulado por um fornecedor de ferramentas de proxy, que o fornece a revendedores mediante pagamento. Isso é algo que merece reflexão.

(Detalhes do acesso ao SerpApi via endpoint StableTravel)

Como a conformidade se manifesta

Mesmo sem ser especialista jurídico, fica claro que esses movimentos são “complexos”. A boa notícia é que um padrão mais claro já está emergindo.

O MPP foi lançado pela Tempo como um protocolo de pagamento por proxy na sua rede principal, oferecendo mais de 100 serviços compatíveis desde o primeiro dia. Fornecedores que integram diretamente o MPP — como Parallel, Stripe Climate, Browser Base — são marcados com um círculo verde em seus cartões, indicando que são provedores de primeira parte.

(Catálogo de serviços acessado via mpp.dev)

Há cerca de duas semanas, a ferramenta de pesquisa de IA popular Exa anunciou suporte nativo ao protocolo x402 em seus endpoints de busca e conteúdo — tornando-se um provedor de primeira parte e estabelecendo parceria com a Coinbase. Exa afirmou que a escolha pelo x402 em vez de um protocolo proprietário se deve ao fato de ser regulado pela Linux Foundation.

Resultado inevitável

Atualmente, não é possível determinar se um endpoint é de primeira parte, autorizado por terceiros ou não autorizado por terceiros. Essa é uma questão que pode ser resolvida, e o catálogo de serviços do MPP — que mostra claramente a origem de cada integração — é um passo nessa direção.

A prática de scraping não autorizado já impôs várias pressões mensuráveis aos provedores de serviços: carga nos servidores, custos de banda e tráfego que eles nunca consentiram em fornecer. Quando terceiros encapsulam esses dados em protocolos como o x402 e cobram por isso, a situação se agrava. Os provedores arcam com todos os custos, sem receber nada em troca.

Por isso, é fundamental identificar a origem do problema. O x402 é um protocolo aberto — assim como qualquer desenvolvedor pode criar com base em HTTP, qualquer desenvolvedor pode criar com base em x402. Os mecanismos de pagamento não rastreiam se os dados upstream foram obtidos de forma autorizada. A responsabilidade recai sobre os desenvolvedores que empacotam esses endpoints para uso dos usuários.

Sem mecanismos de responsabilização, o desenvolvimento do x402 pode sofrer impactos negativos — integradores nativos potenciais podem se tornar opositores, em vez de participantes. Esses rendimentos deveriam pertencer aos provedores de serviços. A integração nativa é a forma de eles reivindicarem esses rendimentos e também de garantir a legitimidade do crescimento do x402.

Atenção: até 25 de abril, o Google Flights deixou de ser listado no Agentic Market.