Fraude de agentes de compra com IA no checkout: como barrar a fraude de bots por IP sem bloquear vendas reais

O tráfego de checkout que mais converte e a fraude que mais custa agora chegam dos mesmos tipos de rede. A Adobe constatou que o tráfego de IA para sites de varejo dos EUA "converted 42% better" (converteu 42% melhor) do que visitantes humanos em março de 2026, um ano depois de converter 38% pior (dados da Adobe via TechCrunch). Enquanto isso, o tráfego automatizado passou de 53% de todo o tráfego web em 2025 (Imperva 2026 Bad Bot Report).

A HUMAN Security relata que "2.3% of agentic activity now occurs on checkout pages" (2,3% da atividade agêntica agora acontece em páginas de checkout) e que "only one half of one percent separates" (apenas meio ponto percentual separa) a taxa de automação benigna da de automação maliciosa (HUMAN, março de 2026). O comportamento, sozinho, não vai separá-las.

A seguir: quatro consultas reais, por que a comparação do User-Agent é responsabilidade sua e um mapa de pontuação para ação que preserva as vendas feitas por agentes reais.

Por que bloquear IPs de datacenter e proxy no checkout falha nos dois sentidos

Um bloqueio generalizado de datacenter falha porque é, ao mesmo tempo, permeável e caro. É permeável porque os ataques mais caros não precisam de um endereço de datacenter. A HUMAN diz que "Carding volume has surged 250% since 2022" (o volume de carding disparou 250% desde 2022) e que "Post-login account compromise attempts more than quadrupled year over year" (as tentativas de comprometimento de conta após o login mais que quadruplicaram em um ano) (HUMAN). A GeoIPHub não detecta proxies residenciais, então a fraude vinda de conexões domésticas precisa ser pega pelos seus dados de velocidade e de pagamento. Nosso texto sobre fraude com proxies residenciais explica por quê.

É caro porque atinge pessoas para quem você quer vender:

• Agentes reais rodam em redes de nuvem. O endereço verificado do ChatGPT-User mais abaixo fica no AS8075 da Microsoft e é marcado como datacenter_ip.
• Usuários do Apple iCloud Private Relay compartilham endereços de egress de relay operados em redes parceiras, como a Cloudflare.
• O NAT de operadora (CGNAT) coloca muitos assinantes atrás de um único endereço. A RFC 6598 reserva 100.64.0.0/10 como espaço de endereços compartilhado para isso. A Cloudflare mediu que "CGNAT IPs are subject to rate limiting three times more often than non-CGNAT IPs" (IPs de CGNAT sofrem limitação de taxa três vezes mais do que IPs que não são de CGNAT), enquanto a taxa média de bots era menor em endereços de CGNAT, 7% contra 13,1% (Cloudflare).

Portanto, o tipo de conexão é uma entrada ponderada, nunca uma recusa automática. Nosso guia central sobre detecção de bots por IP mostra o que cada indicador de IP consegue e não consegue provar, com cinco consultas reais.

Quatro chamadores no checkout, quatro consultas: o que vimos em 23/10/2026

Um endereço de agente verificado recebe 0 e allow, e o mesmo vale para quase qualquer servidor de nuvem. Fizemos quatro consultas sem chave entre 05:03:52 e 05:04:07 UTC em 23 de outubro de 2026, com 5 segundos de intervalo entre elas:

• ChatGPT-User: 104.208.184.193, o primeiro host de 104.208.184.192/28, o primeiro prefixo do chatgpt-user.json da OpenAI. Baixamos o arquivo às 05:03 UTC. Ele listava 234 prefixos IPv4, nenhum IPv6, com creationTime de 20/10/2026.
• Fetcher acionado por usuário do Google: 107.178.192.1, dentro de 107.178.192.0/27 no user-triggered-fetchers.json do Google.
• Servidor comum de nuvem: 45.33.32.156, scanme.nmap.org, um host de teste público na Linode. Não é um agente.
• iCloud Private Relay: 104.28.46.99, um endereço de egress de relay da Apple na Cloudflare.

Esta é a consulta do ChatGPT-User, reduzida, com o aninhamento preservado e os valores sem edição:

Dois sinais de hospedagem dispararam, datacenter_ip e no_ptr_datacenter. O sinal atenuante verified_crawler levou o total a 0. Este endereço não tem DNS reverso, nem ao vivo nem armazenado, então o arquivo de faixas da OpenAI é a única prova. O fetcher do Google mostra o mesmo padrão, com 0, exceto que o hostname dele resolve, então dispara rdns_hosting em vez de no_ptr_datacenter.

O servidor de nuvem é a linha que importa. O 10 dele vem apenas de datacenter_ip, dentro da faixa allow (25 ou menos). Se essa requisição tivesse chegado com um User-Agent ChatGPT-User, a pontuação continuaria dizendo allow. Só verified: false e name: "none" mostram que a alegação é falsa. É por isso que a coluna de decisão diz step up, e não allow.

O endereço de relay recebeu 9, com relay_ip como único método. Relays têm teto de 60, então um usuário do Private Relay nunca chega a block. Nossa geolocalização diz Luanda, Angola, mas o feed de egress da Apple dizia Lusaka, Zâmbia, quando verificamos em 12/10/2026; portanto, avalie usuários de relay pelo país.

Às 05:09 UTC também consultamos 136.121.16.1, o primeiro host IPv4 do user-triggered-agents.json do Google. Esse arquivo cobre o Google-Agent, que o Google diz que "is used by agents hosted on Google infrastructure to navigate the web and perform actions upon user request" (é usado por agentes hospedados na infraestrutura do Google para navegar na web e executar ações a pedido do usuário) (Google). Ele voltou verificado como GoogleUserTriggeredAgent, pontuação 0, allow. Também disparou fcrdns_mismatch, embora um dig ao vivo confirme o hostname na resolução direta. Esse é um bug nosso; ele não alterou a pontuação, e já o registramos.

São cinco consultas em uma única manhã, não um benchmark. As faixas mudam, então repita as consultas antes de copiar um valor.

A comparação do User-Agent é tarefa do seu código, não da API

A API prova qual bot é dono de um endereço, e o seu código prova que a requisição alegou ser esse mesmo bot. Uma consulta de IP nunca vê o User-Agent, então a GeoIPHub não consegue sinalizar sozinha um agente falsificado. O handler do seu checkout tem o cabeçalho e precisa fazer a comparação.

Os nomes diferem entre os dois lados. O token de User-Agent da OpenAI é ChatGPT-User, e a API retorna ChatGPTUser, sem o hífen. O token do Google é Google-Agent, e a API retorna GoogleUserTriggeredAgent. Uma comparação literal de strings falha, então mantenha um pequeno mapa:

Um resultado false é a linha do servidor de nuvem acima: escale ou recuse, qualquer que seja a pontuação. A aplicação completa em nginx e Express, com um teste de GPTBot falsificado, está no nosso guia sobre se vale a pena bloquear rastreadores de IA.

Verifique a assinatura do agente antes de pontuar o IP dele

Uma credencial de protocolo ou assinatura válida vale mais do que qualquer sinal de IP. Três mecanismos respondem "quem enviou isto" com mais firmeza do que um arquivo de faixas.

Agentic Commerce Protocol (ACP). A Stripe anunciou o ACP em 29 de setembro de 2025 como um padrão aberto "codeveloped by Stripe and OpenAI" (desenvolvido em conjunto pela Stripe e pela OpenAI); o repositório da especificação tem licença Apache-2.0. A RFC do Agentic Checkout marca como obrigatórios um bearer token em Authorization, API-Version e, em todo POST, Idempotency-Key, com Signature e Timestamp recomendados. A Stripe diz que seus Shared Payment Tokens "are scoped to a specific merchant and cart total" (são restritos a um lojista e a um valor de carrinho específicos), o que limita o que um token roubado consegue comprar.

Web Bot Auth. Os agentes assinam cada requisição conforme a RFC 9421 HTTP Message Signatures (Standards Track, fevereiro de 2024). O post da Cloudflare sobre Web Bot Auth usa os cabeçalhos Signature, Signature-Input e Signature-Agent e chaves Ed25519 publicadas por quem assina.

Programas de agentes das bandeiras de cartão. A Visa criou seu Trusted Agent Protocol "in collaboration with Cloudflare" (em colaboração com a Cloudflare) sobre o padrão HTTP Message Signature, para distinguir agentes confiáveis "from malicious automation and rogue bots" (de automação maliciosa e bots mal-intencionados) (Visa, 14 de outubro de 2025). O anúncio da Cloudflare no mesmo dia diz que "Mastercard is incorporating Web Bot Auth into Mastercard Agent Pay" (a Mastercard está incorporando o Web Bot Auth ao Mastercard Agent Pay).

Em uma chamada ACP, a RFC diz que o ChatGPT chama os endpoints do seu checkout, então o IP que se conecta pertence à plataforma do agente, não ao comprador. Verifique a credencial nesse canal e reserve a pontuação de IP para o tráfego web direto. Nosso guia para verificar rastreadores e agentes de IA por IP, rDNS e Web Bot Auth percorre cada verificação.

Por que allowlists de IP, sozinhas, são frágeis, mesmo para agentes reais

Uma allowlist mantida à mão quebra porque os endereços dos agentes são compartilhados e mudam o tempo todo. A Cloudflare diz isso sem rodeios: "the logic around IP address ranges representing a product or group of users is brittle" (a lógica de faixas de endereços IP representando um produto ou grupo de usuários é frágil). E acrescenta que as conexões "might be shared by multiple users, such as in the case of privacy proxies and VPNs" (podem ser compartilhadas por vários usuários, como no caso de proxies de privacidade e VPNs), e que as faixas de nuvem "change over time" (mudam com o tempo) (Cloudflare).

O próprio arquivo da OpenAI mostra essa deriva:

A contagem de 06/10/2026 vem da nossa comparação entre GPTBot, OAI-SearchBot e ChatGPT-User. A OpenAI também diz sobre o ChatGPT-User que "Because these actions are initiated by a user, robots.txt rules may not apply" (como essas ações são iniciadas por um usuário, as regras do robots.txt podem não se aplicar) (OpenAI).

Do nosso lado também há atraso. A GeoIPHub baixa novamente 19 arquivos oficiais de faixas e reconstrói seu banco de dados de consulta diariamente, então um prefixo novo pode levar até cerca de dois dias para ser verificado. Trate uma correspondência de faixa como uma confirmação forte e prefira uma assinatura quando o agente enviar uma.

Fraude de agentes de compra com IA: as ameaças na etapa de pagamento

Três ataques impulsionam a fraude de agentes de compra com IA no checkout, e nenhum deles se parece com o pedido legítimo de um agente: um carrinho para um comprador.

• Teste de cartão (enumeração). Rajadas de tentativas pequenas ou apenas de autorização, com altas taxas de recusa. A Visa diz que ataques de enumeração causam "$1.1B annually in fraud losses" (US$ 1,1 bilhão por ano em perdas com fraude) e que "Thirty three percent of enumerated accounts experienced fraud within five days" (33% das contas enumeradas sofreram fraude em até cinco dias) (Visa, maio de 2024).
• Tomada de conta (ATO). Logins roubados usados para comprar com cartões salvos. A Imperva diz que os serviços financeiros responderam por "46% of account takeover incidents" (46% dos incidentes de tomada de conta) (Imperva 2026). Nosso guia de defesa contra tomada de conta cobre o lado do login.
• Scalping. Bots que acumulam estoque limitado em lançamentos de alta demanda.

Um teste de cartão espalhado por muitos endereços passa por um contador por IP, então conte também as recusas e os cartões distintos por ASN e por BIN.

Associe a pontuação de 0 a 100 a uma ação no checkout

Uma pontuação de 0 a 100 só é útil no checkout quando cada faixa corresponde a uma ação fixa. A pontuação de risco explicável da GeoIPHub cobre as entradas do lado do IP, e scoring.detection_methods nomeia cada sinal que disparou. O seu código e os seus dados de pagamento fornecem o resto:

Em seguida, associe as faixas às ações:

Os tetos mantêm endereços compartilhados fora de block. Um endereço de relay tem teto de 60, então não pode ser recusado apenas pela pontuação, e um teto de 50 se aplica a endereços que a API identifica como NAT de operadora. O ACP também traz seu próprio sinal de teste de cartão: a RFC de delegate-payment envia risk_signals do tipo card_testing com uma ação blocked, manual_review ou authorized. A plataforma do agente preenche esse campo; a sua pontuação continua sendo uma verificação separada. Nosso post sobre limites da pontuação de fraude de IP para login, cadastro e checkout testa essas faixas em mais cinco endereços.

Escale, não bloqueie: o 3-D Secure transfere a responsabilidade

Mande as faixas intermediárias para o 3-D Secure em vez de recusá-las, porque um step up preserva a venda e normalmente transfere o risco de chargeback. O guia de responsabilidade do 3-D Secure v2 da Trust Payments diz que, após uma autenticação bem-sucedida, "the card issuer will be liable in the event of a fraudulent chargeback in the majority of cases" (o emissor do cartão será responsável em caso de chargeback fraudulento na maioria dos casos). Ele também alerta que "Successful authentication of a transaction does not guarantee the liability shift or successful authorisation." (a autenticação bem-sucedida de uma transação não garante a transferência de responsabilidade nem a autorização bem-sucedida).

Um step up dá ao comprador real um caminho para concluir e obriga quem testa cartões a provar que tem o cartão. Nosso guia sobre falsos positivos na detecção de VPN mostra quem mais cai nessa faixa intermediária.

A questão do agente autorizado é jurídica, não técnica

A pergunta mais difícil é se o agente pode comprar de você. Em 9 de março de 2026, o Tribunal Distrital dos EUA para o Distrito Norte da Califórnia concedeu à Amazon uma liminar contra a Perplexity. O The Register relata que o juiz escreveu que o agente Comet da Perplexity "accesses with the Amazon user's permission but without authorization by Amazon" (acessa com a permissão do usuário da Amazon, mas sem autorização da Amazon) (The Register). A Perplexity recorreu e, em 4 de agosto de 2026, o Nono Circuito anulou a liminar e devolveu o caso ao tribunal distrital, onde ele continua em aberto.

Essa decisão não resolveu a questão. As verificações de IP dizem quem enviou a requisição. Os seus termos de serviço dizem se esse remetente pode comprar.

Onde as verificações de IP falham no checkout

Os sinais de IP cobrem apenas parte do quadro do checkout, e estas são as lacunas conhecidas:

• Sem detecção de proxy residencial. A fraude vinda de conexões domésticas exige os seus dados de velocidade e de pagamento.
• Sem visibilidade do User-Agent. A API nunca sinaliza um agente falsificado; quem faz isso é a comparação de nomes no seu código.
• Atraso nas faixas e lacunas de DNS. Um prefixo novo pode levar cerca de dois dias para ser verificado, e vimos um fcrdns_mismatch falso nesta manhã.
• O NAT de operadora ainda não é sinalizado por faixa. Quando consultamos 100.64.0.1 em 22/10/2026, ele não voltou marcado como CGNAT. Não crie uma regra com base nesse indicador por enquanto.

Depois de qualquer mudança de regra, acompanhe os falsos positivos por segmento, como Safari no iOS, operadoras móveis e Private Relay. Nossa nota sobre quão precisa é de fato a geolocalização de IP explica por que o país vale mais do que a cidade.

Coloque isso no handler do seu checkout

Implemente isso no servidor, no endpoint de checkout, em quatro passos:

1. Verifique primeiro qualquer credencial ACP ou assinatura Web Bot Auth e dê o canal confiável às que forem válidas.
2. Consulte o IP que está se conectando, como no nosso guia para adicionar detecção de fraude por IP ao seu app com a API gratuita.
3. Aplique o mapa de User-Agent sobre threat.crawler.name. Uma alegação de agente que falha recebe step up ou recusa.
4. Associe scoring.recommended_action à tabela de faixas e acrescente por cima a sua velocidade por cartão e por ASN.

Quando uma decisão parecer errada, use os passos de como investigar um endereço IP para entender o motivo. Comece com um endereço dos logs do seu próprio checkout que tenha alegado ser ChatGPT-User nesta semana. Consulte-o e compare crawler.name com a alegação.

Perguntas frequentes

Devo bloquear todos os IPs de datacenter ou proxy no checkout para barrar bots?

Não. Agentes reais rodam em redes de nuvem: em 23/10/2026, um endereço verificado do ChatGPT-User no AS8075 da Microsoft recebeu 0, allow. Bloqueios generalizados também rejeitam usuários do Private Relay e de NAT de operadora (CGNAT). Pese a hospedagem na pontuação e mande as faixas intermediárias para o 3-D Secure.

Como diferenciar um agente de compra com IA legítimo de um bot de fraude na etapa de pagamento?

Verifique a identidade primeiro: uma credencial ACP ou uma assinatura Web Bot Auth conforme a RFC 9421. Sem nenhuma delas, consulte o IP, que retorna threat.crawler.verified e o nome do bot, e faça seu código comparar esse nome com o User-Agent declarado na requisição.

Por que uma allowlist de IPs, sozinha, é frágil para agentes de IA?

A Cloudflare observa que as conexões de um serviço de rastreamento podem ser compartilhadas, como acontece com proxies de privacidade e VPNs, e que as faixas de nuvem mudam com o tempo. O chatgpt-user.json da OpenAI passou de 230 para 234 prefixos IPv4 entre as nossas coletas de 06/10/2026 e 23/10/2026.

Como uma pontuação de risco de IP de 0 a 100 deve se traduzir em uma decisão de checkout?

Deixe passar allow (25 ou menos), mande review (50 ou menos) e step_up (75 ou menos) para o 3-D Secure, e recuse ou retenha block (acima de 75). Uma alegação de agente que falha na verificação recebe step up, qualquer que seja a pontuação.

Escalar para o 3-D Secure prejudica mais a conversão do que bloquear?

Um bloqueio perde a venda com certeza; um step up dá ao comprador real um caminho para concluir. A Trust Payments diz que, após uma autenticação bem-sucedida, o emissor responde pelo chargeback fraudulento na maioria dos casos, embora isso não seja garantido.

É legal bloquear agentes de IA que compram na minha loja?

Depende de autorização, e isto não é aconselhamento jurídico. Em março de 2026, um tribunal federal concedeu à Amazon uma liminar contra a Perplexity, cujo agente Comet, segundo o juiz, acessava a Amazon com a permissão do usuário, mas sem autorização da Amazon. O Nono Circuito anulou essa liminar em agosto de 2026, e o caso continua em aberto.