Enquanto alguns bloqueiam bots, outros os ensinam a apresentar passaporte. Em 2026, Cloudflare, Google, Amazon, Akamai e OpenAI se reuniram em torno de um único padrão — Web Bot Auth. A ideia é simples e radical: o tráfego automático não é mais verificado pelo endereço IP e pela string User-Agent, que são fáceis de falsificar. Em vez disso, o agente assina criptograficamente cada solicitação, e o site verifica instantaneamente a assinatura. Em 2 de março de 2026, foi lançada a quinta versão do rascunho da arquitetura (draft-meunier-web-bot-auth-architecture-05), em maio o Google começou os testes em produção, e o grupo de trabalho da IETF pretende lançar o padrão até agosto de 2026. Vamos entender que mecanismo é esse, quem está por trás dele e por que para todos que lidam com scraping e multi-contas, isso representa uma mudança de 180 graus.
O que aconteceu: bots ganham identidade criptográfica
A verificação clássica de "amigo ou inimigo" na web se sustentava em dois pilares. O primeiro — User-Agent: uma string que o cliente informa sobre si mesmo e que qualquer script reescreve em uma linha de código. O segundo — listas de endereços IP: o site mantém uma lista de intervalos "oficiais" do Googlebot, Bingbot e outros, e verifica o DNS reverso. Ambos os métodos, em 2026, desmoronaram completamente.
Cloudflare formula diretamente o problema em sua documentação técnica: o mesmo IP pode ser utilizado por múltiplos usuários ou serviços ao mesmo tempo, e os próprios intervalos mudam constantemente com a infraestrutura. O User-Agent, por sua vez, não é uma prova — é apenas uma autoapresentação. A assinatura criptográfica, segundo os autores, proporciona autenticação sem depender de "intervalos de IP que mudam constantemente" ou de "cabeçalhos falsificáveis como o User-Agent".
Tecnologicamente, Web Bot Auth se baseia no padrão já aceito HTTP Message Signatures (RFC 9421). A cada agente é fornecido um par de chaves Ed25519. Antes de enviar uma solicitação, o agente assina não tudo, mas o authority do URI de destino — ou seja, o domínio ao qual está se dirigindo (ao acessar example.com, é exatamente example.com que é assinado). Na solicitação, são adicionados os cabeçalhos Signature-Input (janela de validade com as marcas created e expires, identificador da chave keyid no formato JWK Thumbprint e a tag web-bot-auth) e Signature-Agent, que aponta para o diretório com as chaves públicas (JWKS). O site baixa a chave pública desse diretório e verifica a assinatura. Falsificá-la sem a chave privada é impossível, e a janela de validade protege contra a reprodução de solicitações interceptadas.
Quem está por trás do padrão
Isso não é um experimento de uma única empresa. O Web Bot Auth é apoiado por Cloudflare, Amazon, Akamai e OpenAI. O rascunho da arquitetura está sendo escrito em coautoria por Thibaut Meunier (Cloudflare) e Shandor Major (Google). AWS WAF já adicionou suporte à verificação de assinaturas, e a Cloudflare integrou isso em seu programa Verified Bots e ativou em sua edge em produção. Um grupo de trabalho separado da IETF para o Web Bot Auth foi estabelecido em 2026 e visa entregar a especificação para padronização até agosto de 2026.
Google se envolveu — e este é um ponto de virada
Em 6 de maio de 2026, foi revelado que Google está testando o Web Bot Auth para verificar seu próprio tráfego de bots. O objetivo é que o site possa se certificar de que a solicitação que se apresenta como sendo do Google realmente vem do Google, e não de alguém que apenas digitou Googlebot no User-Agent. O tráfego assinado da AI do Google opera sob a identidade agent.bot.goog — os proprietários de sites obtêm as chaves públicas do Google desse endpoint e validam os cabeçalhos Signature e Signature-Input.
Por que isso é importante agora. Exatamente por causa do que escrevemos sobre o bloqueio de navegadores de agentes: a partir de 15 de setembro de 2026, a Cloudflare, por padrão, cortará "misturados" AI-crawlers em páginas de anúncios de novos domínios, e cerca de um quinto de toda a web passa pela rede Cloudflare. A web está se fechando. E o Web Bot Auth não é sobre "como bloquear", mas sobre "quem deixar entrar". Surge uma lista branca de um novo tipo: não por IP, mas por identidade criptográfica. O site poderá implementar uma política do tipo "mostrar preços e detalhes do produto apenas a agentes assinados verificados" — e todo o resto automaticamente permanece do lado de fora.
Agentes assinados: a primeira coorte
Uma categoria separada — signed agents (agentes assinados). Esses são bots controlados pelo usuário final, e não por uma única corporação: a plataforma ou navegador remoto em que o agente opera assina suas solicitações HTTP, e a Cloudflare valida as assinaturas. A primeira coorte inclui ChatGPT agent (OpenAI), Goose (Block), Browserbase, Anchor Browser e Cloudflare Browser Rendering. Daouve Osinga da Block descreveu o benefício diretamente: "Web Bot Auth permite que os sites confiem no Goose, mantendo o que o torna único".
A diferença chave: o signed agent atua em nome de uma pessoa (um assistente condicional que acessa o site a seu pedido), enquanto o crawler "de busca" ou "de treinamento" opera para uma empresa. A Cloudflare já está diferenciando essas entidades nas regras de segurança — e essa divisão determinará quem na web de 2026-2027 terá as portas abertas e quem não.
O que isso significa para scraping e proxies
A princípio, parece que a assinatura criptográfica acaba com o scraping anônimo. Na prática, a situação é mais sutil — a web se divide em duas faixas de tráfego, e para nosso público isso muda a tática, em vez de cancelá-la.
- Faixa de agentes assinados. Um acesso estreito e privilegiado para grandes plataformas e assistentes "de usuários" da lista branca. Para entrar, são necessárias uma chave privada, um diretório JWKS público, registro em CDN e conformidade com as políticas. Para um projeto típico de parsing, fazendas anti-detect ou automação SMM, esse caminho está fechado: você não é o Google e não é a OpenAI, você não receberá uma assinatura.
- Faixa de todos os outros. Aqui ainda vivem scrapers independentes, monitoramento de preços, coleta de dados, multi-contas. E é aqui que as apostas na qualidade dos proxies e na autenticidade da impressão aumentam. Uma vez que "legítimos" são aceitos por assinatura, a relação com todo o tráfego não assinado se torna mais rigorosa por padrão.
Em outras palavras, o Web Bot Auth não elimina a necessidade de proxies — ele eleva o padrão para aqueles que não estão na lista branca. Se antes era possível esperar passar com um User-Agent cinza, agora uma solicitação não assinada imediatamente cai na categoria "prove que você é um ser humano". E isso é provado por uma combinação de IP limpo e comportamento plausível.
Por que IPs residenciais e móveis se tornam ainda mais valiosos
Quando a assinatura não está disponível, a única maneira de parecer legítimo é ser indistinguível de um usuário comum. Endereços de data center não resolvem essa tarefa: de acordo com várias medições de proteção, a Cloudflare aceita IPs de data center apenas em 40-60% dos casos, enquanto proxies residenciais oferecem uma taxa de sucesso entre 85-99%. A razão é exatamente que o endereço residencial pertence a um provedor de internet real e a um assinante vivo — pela reputação do IP, ele não pode ser distinguido de uma pessoa atrás do mesmo roteador.
A situação é ainda mais rigorosa com as plataformas mais protegidas e aplicativos móveis, onde as redes celulares desempenham um papel. Aqui, os proxies móveis são úteis: atrás de um IP de operadora estão milhares de assinantes vivos, portanto, banir esse endereço em massa significa cortar clientes reais. É exatamente esse efeito de "caldeirão comum" que torna os IPs móveis a moeda mais estável em um mundo onde tudo o mais é transparente.
Mas um IP limpo já não é suficiente. Uma vez que a verificação de identidade se desloca da rede para a criptografia, todo o exército não assinado de bots passa por impressão comportamental e de navegador: TLS/JA4, canvas, WebGL, fontes, tempos. O proxy elimina um sinal de alarme (a reputação do endereço), mas não cancela os outros. A combinação de trabalho de 2026 é um IP residencial ou móvel mais um ambiente anti-detect com impressão coerente. Um componente sem o outro revela o bot no primeiro nível de proteção.
Como agir já agora
- Divida os projetos por faixas. Se a tarefa é uma integração oficial em nome de um grande produto, estude o caminho do signed agent: registro em CDN e obtenção de chaves. Para tudo o mais, planeje o trabalho na "faixa de todos os outros" e estabeleça suas regras.
- Invista na qualidade do IP, e não na quantidade. Pools de data center baratos em 2026 estão se tornando cada vez mais um fator limitante. Aposte em endereços residenciais e móveis com rotação conforme a necessidade.
- Sincronize a impressão com a rede. IP de um país, enquanto o idioma do navegador, o fuso horário e a localidade são de outro — isso é uma falha clássica. A impressão deve coincidir de forma coerente com a geolocalização do proxy.
- Fique de olho no padrão. Até agosto de 2026, a IETF planeja finalizar a especificação. Assim que o Web Bot Auth se tornar uma condição obrigatória de acesso em uma plataforma específica, a tática para ela precisará ser revisada com antecedência, e não após o fato.
Conclusão
Web Bot Auth não é apenas mais um anti-bot, mas uma mudança na própria lógica de confiança na web: de "quem você é pelo IP" para "prove criptograficamente quem você é". Para gigantes como Google e OpenAI, isso é um passe para a internet que está se fechando. Para scrapers independentes e projetos de multi-contas, isso é um sinal de que métodos cinzentos estão definitivamente deixando de funcionar, e a diferença entre "parecer humano" e "parecer bot" se torna decisiva. Vencer na nova realidade não será para quem tem mais IPs, mas para quem tem um endereço residencial ou móvel limpo e uma impressão perfeitamente coerente. O criptopassaporte não foi concedido a todos — portanto, todos os outros terão que ser mais convincentes.
```