Por que os sites bloqueiam agentes de compras com IA?

Quando um usuário diz a um assistente de IA "encontre para mim botas de trilha impermeáveis tamanho 42 que caibam no meu orçamento e coloque no carrinho", o assistente tenta fazer isso como uma pessoa faria: pesquisa, abre lojas, compara páginas de produto, escolhe o tamanho e avança para o pagamento. E muitas vezes para em algum ponto. No lugar da página do produto aparece uma tela de verificação, a requisição de adicionar ao carrinho é recusada ou a página de pagamento marca uma transação suspeita. Para o usuário, o assistente falhou; para a loja, um bot foi barrado.

Neste artigo, explicamos o que é um agente de compras com IA, por que os sites bloqueiam esses agentes e o centro do problema: por que é difícil para um site diferenciar uma pessoa, um bot malicioso e um agente que age com a autorização do usuário. Depois, vemos as soluções que estão surgindo (agentes assinados, Web Bot Auth e novos protocolos do lado do pagamento) e o caminho certo para lojistas e desenvolvedores de agentes. Este artigo não explica como fazer agentes passarem pela proteção de bots; ele se concentra em o tráfego de agentes se identificar corretamente.

O que é um agente de compras com IA?#

Um agente de compras com IA é um sistema de IA que recebe o objetivo de compra de um usuário e o executa agindo ele mesmo em sites. O mecanismo geral é o loop perceber-planejar-agir-avaliar que descrevemos em Agentes de IA: planejamento, ferramentas e memória; em um agente de compras, as ferramentas do loop são os sites das lojas e os sistemas de pagamento.

O que um agente de compras faz se divide em três níveis:

1. Pesquisa: buscar produtos, comparar preços e características, ler avaliações.
2. Preparação: escolher tamanho, cor e quantidade, adicionar ao carrinho, avaliar as opções de frete.
3. Transação: concluir o pedido usando os dados de pagamento.

Cada nível traz um risco diferente para o site. A pesquisa se parece com o que um scraper faz. Adicionar ao carrinho afeta os sistemas de estoque e de sessão do site. O pagamento envolve dinheiro e risco de fraude. Os sites reagem aos agentes de forma diferente em cada nível.

Por que os sites bloqueiam agentes?#

Quando uma loja online barra tráfego de agentes, geralmente não é por uma posição especial contra agentes, e sim porque defesas que existem há anos também pegam os agentes.

Proteção de bots. Lojas online usam sistemas de gerenciamento de bots contra coleta de preços, acúmulo de estoque (colocar produtos limitados em carrinhos para que outros não possam comprar), roubo de contas e ataques de teste de cartões. Esses sistemas pontuam as requisições com sinais como velocidade, reputação do IP, impressão digital do navegador e comportamento. Um agente de compras costuma rodar a partir de um data center, com navegador headless, abrindo páginas muito mais rápido do que uma pessoa; ou seja, carrega quase todos os sinais que os sistemas de proteção de bots procuram. Para um exemplo de como esses sinais são avaliados, veja Cloudflare Precursor.

Risco de fraude no pagamento. Os sistemas de pagamento verificam com vários sinais se um cartão está sendo usado pelo titular: dispositivo, localização, hábitos e etapas extras de verificação, como o 3-D Secure. Quando um agente tenta pagar com dados de cartão, a maioria desses sinais não bate com o perfil normal do titular. Do ponto de vista do sistema de pagamento, o quadro se parece com uma compra automatizada com cartão roubado.

Termos de uso. Os termos de uso de muitas lojas online restringem o acesso automatizado, os pedidos automáticos ou a coleta de conteúdo do site com ferramentas automatizadas. Pelas regras do próprio site, um agente é uma ferramenta de automação não autorizada, mesmo agindo em nome do usuário.

Relacionamento com o cliente e dados. Para o lojista, o agente é um intermediário que se coloca entre ele e o cliente. Boa parte da experiência de venda, como a página do produto, as recomendações, as campanhas e os programas de fidelidade, é pulada quando o agente mostra ao usuário só um resumo. Alguns lojistas são cautelosos com o tráfego de agentes por esse motivo.

Responsabilidade pouco clara. Quando o agente coloca no carrinho o tamanho errado, compra um produto que o usuário não aprovou ou lê o preço errado, quem cuida da devolução e da disputa? Enquanto essas perguntas não têm respostas claras, lojistas e empresas de pagamento podem preferir bloquear para reduzir o risco.

Por que é difícil diferenciar pessoas, bots e agentes autorizados?#

Historicamente, a proteção de bots de um site trabalha com duas categorias: pessoa e bot. Um agente de compras é uma terceira categoria que não se encaixa nessa divisão.

O problema é que, nas quatro primeiras linhas da tabela, o agente se parece com um bot malicioso, e nas duas últimas, com uma pessoa. Como os sistemas de proteção de bots só conseguem olhar sinais de comportamento e de rede, a informação de que precisariam para diferenciar o agente de um bot, ou seja, "quem está por trás desta automação e com qual autoridade", não está na requisição HTTP.

Essa lacuna não pode ser preenchida com o cabeçalho User-Agent, porque esse cabeçalho é texto simples e qualquer um pode escrever qualquer valor nele. Para um site acreditar que uma requisição dizendo "KnownShoppingAgent/1.0" vem de fato do agente daquela empresa, ele precisa de uma prova verificável. Listas de endereços IP ajudam até certo ponto, mas, na infraestrutura em nuvem, os endereços são compartilhados e mudam.

Por isso o agente se esconder ou tentar parecer humano não resolve o problema; piora. Um agente que falsifica a impressão digital do navegador e troca de IP com pools de proxies vira exatamente o tipo de tráfego que os sistemas de proteção de bots foram feitos para bloquear. A solução vai na direção contrária: o agente se identificar de forma verificável.

Agentes assinados e Web Bot Auth#

A principal abordagem que surge nessa direção é o agente assinar criptograficamente cada requisição HTTP. Por baixo está o padrão HTTP Message Signatures (RFC 9421) do IETF. O padrão define como assinar com uma chave privada componentes selecionados de uma mensagem HTTP (método, endereço, certos cabeçalhos) e como o destinatário verifica a assinatura com a chave pública.

Web Bot Auth é o nome da abordagem que usa esse padrão para autenticar bots e agentes. Segundo a documentação do Web Bot Auth da Cloudflare, funciona assim:

1. O operador do agente cria um par de chaves e publica a chave pública como diretório de chaves no próprio domínio, em /.well-known/http-message-signatures-directory.
2. O agente adiciona três cabeçalhos a cada requisição: Signature-Input (os componentes cobertos pela assinatura, o ID da chave, os horários de criação e expiração e um nonce), Signature (a assinatura em si) e Signature-Agent (o endereço do diretório de chaves).
3. O site, ou a CDN na frente dele, verifica a assinatura: lê o diretório de chaves, confere a assinatura com a chave pública e garante que ela não expirou.
4. A requisição verificada é atribuída a um agente conhecido. Com base nisso, o site pode permitir a requisição, limitar a velocidade dela ou restringir o acesso a certos caminhos.

Uma característica importante dessa abordagem é que a verificação não depende do endereço IP: seja qual for o servidor em que o agente roda, a assinatura aponta para o mesmo operador. O próprio diretório de chaves também é assinado, o que dificulta alguém se passar pelo operador com um diretório falso.

Desde 1º de julho de 2026, a Cloudflare trata os agentes que se identificam criptograficamente dessa forma dentro da classificação de bots verificados. Na prática, isso significa que os donos de sites podem abrir um caminho separado para agentes verificados nas regras de proteção de bots.

Novos protocolos do lado do pagamento#

Um agente conseguir chegar a um site é metade do problema. A outra metade é verificar a autoridade do agente para pagar. Desde 2025, surgiram vários protocolos nessa área. Mais do que concorrentes, são protocolos focados em etapas diferentes do processo:

• Visa Trusted Agent Protocol: segundo o anúncio da Visa, o protocolo apresentado pela Visa em outubro de 2025 se baseia no padrão HTTP Message Signatures, está alinhado ao Web Bot Auth e foi desenvolvido junto com a Cloudflare. O objetivo é permitir que os lojistas diferenciem os agentes reconhecidos pela Visa, com intenção de compra, da automação maliciosa.
• Agentic Commerce Protocol (ACP): uma especificação aberta mantida pela OpenAI e pela Stripe. Segundo a página do projeto, ele padroniza o fluxo de compra entre comprador, agente, lojista e provedor de pagamento; o agente mostra ao usuário a interface de pagamento, enquanto o lojista mantém a própria infraestrutura e o processamento de pagamentos.
• Agent Payments Protocol (AP2): o protocolo anunciado pelo Google com parceiros busca transmitir a autoridade de um agente para pagar em nome do usuário por meio de documentos de autorização assinados criptograficamente. Assim, o lojista e a empresa de pagamento conseguem verificar se a transação está dentro dos limites aprovados pelo usuário.

Alguns desses protocolos ainda estão em beta, e o escopo deles muda rápido. Se você está planejando uma integração, confira a documentação atual do protocolo correspondente.

Quem está resolvendo o quê?#

O que os lojistas podem fazer?#

Bloquear todo o tráfego de agentes ou deixá-lo totalmente aberto pode não ser o certo para um lojista. Uma abordagem por etapas é mais saudável:

1. Meça o tráfego. Veja quanto do tráfego automatizado que chega ao seu site é de buscadores, de crawlers de IA conhecidos e de automação de identidade desconhecida.
2. Escreva a sua política. Decida quais agentes podem chegar a quais páginas (catálogo, carrinho, pagamento). Manter as páginas de catálogo abertas e vincular o pagamento a protocolos verificados é um ponto de partida comum.
3. Atualize o robots.txt e os seus termos. Deixe as suas preferências sobre agentes claras tanto em formato legível por máquina quanto nos termos de uso. Explicamos como o arquivo é escrito em O que é robots.txt e como ler o arquivo?.
4. Reconheça agentes assinados. Use as configurações que o seu serviço de gerenciamento de bots oferece para agentes verificados; avalie o tráfego de agentes com identidade verificada separadamente do tráfego de identidade desconhecida.
5. Ofereça dados estruturados. Dados schema.org nas páginas de produto e, se você tiver, feeds oficiais de produtos permitem que os agentes cheguem a informações corretas sem precisar extrair a página.
6. Acompanhe os protocolos de agentes dos seus parceiros de pagamento. Se o seu provedor de pagamento suporta esses protocolos, fica possível tratar as transações originadas por agentes em um fluxo separado das regras de fraude.

Para trabalhos como monitorar o tráfego de agentes e bots no seu próprio site e verificar como anúncios e preços aparecem em países diferentes, veja os cenários nas nossas páginas de solução de proxy para e-commerce e de solução de verificação de anúncios.

O caminho certo para desenvolvedores de agentes#

Se você desenvolve um agente de compras, a resposta errada para os bloqueios é esconder melhor o agente. Falsificar a impressão digital do navegador, fazer resolver telas de verificação ou distribuir o tráfego entre pools de proxies para burlar a proteção de bots vai contra as regras dos sites e coloca o seu agente exatamente na classe de tráfego que deve ser bloqueada. Explicamos como funciona a impressão digital do navegador em Browser fingerprinting, e por que as telas de verificação aparecem em Puppeteer e CAPTCHA.

O caminho certo passa por estas etapas:

• Identifique o seu agente. Use um User-Agent com um token de produto definido e um endereço de contato; se possível, assine as requisições com Web Bot Auth.
• Priorize as integrações oficiais. Se o lojista tiver uma API, um feed de produtos ou um protocolo de compra suportado, use-os em vez de extrair páginas.
• Siga o robots.txt e os termos. Não force caminhos que um site fechou para agentes, nem em nome de um usuário.
• Faça da aprovação do usuário parte do processo. Peça a aprovação explícita do usuário antes de etapas irreversíveis como o pagamento; quem define os limites de gasto é o usuário, não o agente.
• Limite a velocidade. Para a compra de um único usuário, você não precisa abrir dezenas de páginas em segundos.
• Aceite a falha. Se um site bloquear o seu agente, diga isso claramente ao usuário e ofereça uma alternativa; não tente contornar o bloqueio.

Explicamos como tornar seguro o acesso dos agentes à web com limites de taxa, listas de permitidos e registros em Acesso seguro à web para LLMs: limites e permissões. Nessa configuração, o proxy não serve para esconder o agente, e sim para controlar e registrar de qual endereço e localização sai o tráfego do agente.

Erros comuns#

• Tentar fazer o agente parecer humano. Uma impressão digital falsa e a rotação de IP colocam o agente na mesma classe dos bots maliciosos.
• Como lojista, tratar todo o tráfego automatizado como uma única categoria. Não separar agentes verificados de bots de identidade desconhecida pode fechar canais de venda legítimos.
• Tratar o cabeçalho User-Agent como autenticação. Qualquer um pode escrever o cabeçalho; a verificação precisa de uma assinatura.
• Pagar sem aprovação do usuário. Dispara as regras de fraude e cria um problema sério de confiança com o usuário.
• Planejar uma integração sem conferir o estado do protocolo. A maioria dos protocolos dessa área muda rápido.
• Tratar um bloqueio como erro técnico. Geralmente é uma política deliberada do site.

Guia de decisão#

Perguntas frequentes#

Por que agentes de compras com IA esbarram em telas de verificação?#

Os sistemas de proteção de bots avaliam o tráfego de agentes com sinais como velocidade, características do navegador e origem do IP. Como nesses sinais os agentes se parecem com automação maliciosa, eles encontram telas de verificação ou bloqueios. Enquanto a requisição não trouxer informação verificável sobre quem está por trás, o site não consegue diferenciar os dois casos.

O que é Web Bot Auth?#

É uma abordagem que permite a bots e agentes provar a identidade assinando criptograficamente as requisições HTTP. Ela usa o padrão RFC 9421 HTTP Message Signatures. O agente publica a chave pública no próprio domínio, e o site ou a CDN verifica a assinatura de cada requisição com essa chave.

Um agente assinado funciona em qualquer site?#

Não. A assinatura só prova quem é o agente; ela não dá acesso ao site. Cada site decide o quanto permite aos agentes assinados. Em sites que não verificam assinaturas, a assinatura não tem efeito.

O meu agente pode passar por um bloqueio usando proxy?#

Tentar burlar a proteção de bots trocando de IP por um proxy significa ignorar uma preferência explícita do site e coloca o seu agente na mesma categoria da automação maliciosa. O uso legítimo de um proxy aqui é controlar e registrar a saída do tráfego do agente e aparecer a partir de uma localização específica quando necessário.

Os lojistas devem bloquear todo o tráfego de agentes?#

É uma decisão de negócio. Bloquear tudo reduz o risco de fraude, mas pode fazer perder clientes que usam agentes. Para muitos lojistas, o caminho equilibrado é manter as páginas de catálogo abertas, gerenciar os agentes verificados com regras próprias e vincular o pagamento a protocolos suportados.

Esses protocolos são usados em Türkiye?#

A maioria desses protocolos é nova, e o escopo e o suporte regional mudam rápido. Para um lojista ou desenvolvedor em Türkiye, o caminho mais confiável é perguntar diretamente ao próprio provedor de pagamento e à CDN quais protocolos de verificação de agentes e de pagamento eles suportam.

Em resumo#

Os sites bloqueiam agentes de compras com IA porque os sistemas de proteção de bots não conseguem diferenciar um agente que trabalha para um usuário da automação maliciosa, e os sistemas de pagamento não conseguem verificar se o agente age com a autoridade do titular do cartão. A solução não é esconder o agente, e sim fazê-lo se identificar de forma verificável: requisições assinadas com Web Bot Auth baseado na RFC 9421, estruturas de agentes reconhecidos como o Visa Trusted Agent Protocol e protocolos de compra e autorização de pagamento como ACP e AP2 vão nessa direção. Os lojistas devem medir o tráfego de agentes e definir uma política, e os desenvolvedores de agentes, apoiar-se em integrações oficiais e na aprovação do usuário. Para verificar dentro das regras como preços e conteúdos aparecem em localizações diferentes, veja a nossa página de solução de monitoramento de preços.