---
title: "Por que os sites bloqueiam agentes de compras com IA?"
description: "Agentes de compras com IA esbarram na proteção de bots porque o site não distingue um agente autorizado. Explicamos o motivo e as novas soluções."
url: https://proxynet.io/pt-br/blog/ai-shopping-agents-blocked
date: 2026-09-13
author: "Acar Diveroli"
category: "IA, Web scraping"
lang: pt-BR
---

# 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.

> **Nota: Resposta rápida**
>
> Os sites bloqueiam agentes de compras com IA porque a proteção de bots não consegue diferenciar a requisição de um agente da automação maliciosa: os dois geram tráfego rápido, baseado em automação de navegador, diferente do comportamento humano. No pagamento, não há como verificar se o agente que usa um cartão realmente age com a autoridade do titular. As soluções que estão surgindo se baseiam em os agentes assinarem criptograficamente as requisições (Web Bot Auth, HTTP Message Signatures) e em a autorização de pagamento ser transmitida de forma verificável.

## 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](/pt-br/blog/how-ai-agents-work); em um agente de compras, as ferramentas do loop são os sites das lojas e os sistemas de pagamento. Alguns desses agentes vêm embutidos no próprio navegador; como esses navegadores funcionam e que riscos trazem está em [O que é um navegador com IA? Navegadores agênticos e riscos](/pt-br/blog/what-is-an-ai-browser).

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](/pt-br/blog/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.

| Característica | Visitante humano | Bot malicioso | Agente agindo por um usuário |
|---|---|---|---|
| Em nome de quem age? | Em nome próprio | Em nome de um atacante | Em nome de um usuário real |
| Padrão de tráfego | Navegador, velocidade humana | Automação, alta velocidade | Automação, alta velocidade |
| Origem do IP | Conexão doméstica ou móvel | Geralmente data center ou proxy | Geralmente os servidores do provedor do agente |
| Intenção | Comprar | Coletar, acumular, fraudar | Comprar |
| Pagamento | O titular do cartão | Um cartão roubado ou de teste | Com a autoridade do titular |
| O que o site quer | Permitir | Bloquear | Permitir, mas verificar |

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)](https://www.rfc-editor.org/rfc/rfc9421) 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](https://developers.cloudflare.com/bots/reference/bot-verification/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](https://developers.cloudflare.com/bots/concepts/bot/signed-agents/). 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](https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21716.html), 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](https://www.agenticcommerce.dev/), 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ê?

| Parte | O problema que tem | A solução que surge |
|---|---|---|
| Lojista (loja online) | Não diferencia um agente de um bot malicioso | Verificar o tráfego de agentes assinados e gerenciá-lo com regras próprias |
| CDN e serviço de gerenciamento de bots | Automação cuja identidade não pode ser verificada | Verificação de assinaturas com Web Bot Auth, classificação de bots verificados |
| Rede de pagamentos | A autoridade do agente em nome do titular é desconhecida | Protocolos de agentes reconhecidos, documentos de autorização verificáveis |
| Provedor de pagamento | Não há fluxo de pagamento padrão entre agente e lojista | Protocolos de compra abertos |
| Desenvolvedor de agentes | As requisições são bloqueadas, as transações são interrompidas | Assinar as requisições, usar integrações oficiais |
| Usuário | Não controla o que o agente vai comprar | Limites de gasto, etapas de aprovação, autorização verificável |

## 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?](/pt-br/blog/robots-txt).
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](/pt-br/e-commerce-proxy) e de [solução de verificação de anúncios](/pt-br/ad-verification).

## 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](/pt-br/blog/browser-fingerprinting), e por que as telas de verificação aparecem em [Puppeteer e CAPTCHA](/pt-br/blog/puppeteer-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](/pt-br/blog/llm-safe-web-access). 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

| Sua situação | Recomendação |
|---|---|
| O seu agente só pesquisa produtos | Um User-Agent que identifique você, robots.txt, limites de taxa; uma API de produtos, se houver |
| O seu agente vai adicionar ao carrinho e pagar | O protocolo de compra suportado pelo lojista, aprovação do usuário |
| O seu agente é bloqueado com frequência | Assine as requisições com Web Bot Auth; não tente contornar o bloqueio |
| Você é lojista e o tráfego de agentes está crescendo | Meça o tráfego, escreva uma política, gerencie agentes assinados com regras próprias |
| Você é lojista e as transações de agentes são recusadas no pagamento | Avalie os protocolos de agentes do seu provedor de pagamento |
| Você quer controlar a saída do tráfego do seu agente | Um endereço de saída fixo e registrado e uma lista de permitidos |

## 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](/pt-br/price-monitoring).