Em 13 de julho de 2026, a Cloudflare começou a implementar para todos os clientes o Precursor — um motor de cliente que avalia não apenas uma solicitação isolada ou a passagem de um captcha, mas sim o comportamento durante toda a sessão. A formulação do CTO da Cloudflare, Dane Knecht, é curta e precisa: "Em vez de apenas verificar uma ID na entrada, estamos observando o comportamento durante toda a visita" — em vez de verificar o passe na entrada, observamos o comportamento durante toda a visita.
Para aqueles que automatizam navegadores — scrapers, multi-contas, automação de SMM, agentes de IA — isso representa uma mudança na unidade de medida do risco. Antes, a unidade era a solicitação: passou no desafio, obteve cf_clearance, está funcionando. Agora, a unidade é a sessão, que vive, acumula avaliação e pode "se deteriorar" a qualquer momento após você já ter passado pela verificação.
O que exatamente a Cloudflare lançou
O Precursor é um script que a Cloudflare insere nas páginas através de sua rede. É ativado por um interruptor no painel (Security → Settings → Precursor), não requer modificações no código do site e funciona em toda a zona de uma vez; o comportamento é ajustado pontualmente através das Regras do Precursor. Ele não é posicionado como uma substituição do Turnstile, mas sim como um complemento: o Turnstile é uma verificação única, enquanto o Precursor é contínuo.
O que o script coleta, segundo a própria Cloudflare:
- movimento do cursor — trajetórias, velocidade, natureza dos arcos;
- ritmo de rolagem;
- cadência de digitação — tempos e ritmo, mas não as teclas pressionadas;
- atividade da área de transferência;
- mudança de foco dos elementos e visibilidade da página/aba.
Então, começa a parte interessante. A Cloudflare descreve claramente que busca nesses dados não um "impressão digital", mas sim física e fisiologia humana: arcos de movimento do mouse, limitados pela rotação do pulso, em vez de movimentos lineares de automação; atrasos cognitivos mensuráveis entre o aparecimento do estímulo na tela e a reação; micro-oscilações da mão — tremor — como ruído natural na trajetória.
O segundo nível — verificações cruzadas de contradições internas. O cursor se move enquanto a página está oculta? Eventos de teclado chegam, mas nenhum campo de texto está em foco? Cada sinal individual parece normal, mas juntos não formam uma imagem coerente de um ser humano vivo — e isso é detectado mais barato do que qualquer análise de um clique isolado.
O terceiro e mais desagradável ponto para a automação: a avaliação se acumula durante a sessão e não é redefinida ao recarregar a página. O clássico truque de "recebeu um bloqueio — F5 / nova aba" deixa de ser um reset de estado. Os resultados da verificação contínua atualizam aquele cf_clearance, e a Cloudflare afirma claramente que a confirmação de clearance já emitida pode ser reduzida ou anulada no meio da sessão, além de provocar um desafio adicional.
Dois modos — e por que é importante saber isso com antecedência
- Minimize Friction (por padrão) — verificação em segundo plano sem intersticiais. O usuário não vê nada, mas a garantia de "sessão válida" é mais fraca.
- Maximize Security (recomendado pela Cloudflare) — um leve desafio intersticial que estabelece uma sessão válida, com uma deterioração consciente da experiência do usuário.
Conclusão prática: o comportamento de proteção em um site específico agora depende da configuração que você não vê externamente. O mesmo script, o mesmo proxy e o mesmo site podem se comportar de maneira diferente antes e depois que o proprietário alterna o modo. As ativações são visíveis para o proprietário do site em Security → Analytics → Traffic → Bot analysis — em uma linha com a distribuição de bot score e correspondências WAF.
Escala: por que isso não é "mais um anti-bot"
O contexto que torna a notícia mais importante do que um lançamento comum. A Cloudflare processa mais de 1 trilhão de solicitações por dia, enquanto o Turnstile opera quase 3 bilhões de vezes por dia. Segundo a empresa, o tráfego automatizado superou pela primeira vez o humano e representa cerca de 57% de todas as solicitações da web. A ativação da camada comportamental com um único interruptor em uma base tão grande significa que a parte da internet onde um detector comportamental de sessão opera pode aumentar drasticamente — sem um único commit do lado dos sites.
E o objetivo declarado é exatamente o que é utilizado hoje: "automação avançada que executa JavaScript, opera em um ambiente de navegador real e passa por captchas individuais sem levantar suspeitas". Ou seja, Playwright/Puppeteer com patches stealth, navegadores anti-detect e navegadores de agentes — exatamente o alvo que o Precursor descreve abertamente.
Para ser justo: a Cloudflare não publicou dados quantitativos — nem sobre precisão, nem sobre a taxa de falsos positivos, nem sobre o overhead da monitoração contínua no navegador. Até agora, essas são capacidades declaradas, e não medidas de forma independente. Também não há uma onda pública de reclamações sobre bloqueios falsos em massa nas duas semanas de implementação.
O que isso significa na prática
1. A qualidade do IP não é mais "uma condição suficiente" — mas continua sendo necessária
A conclusão tentadora de que "uma vez que a detecção é comportamental, proxies já não resolvem" é incorreta. O Precursor opera acima das camadas anteriores: reputação do IP, impressão digital TLS/HTTP, bot score. Um IP de datacenter de uma sub-rede exposta recebe um alto bot score e um modo rigoroso de desafios antes mesmo de chegar à análise do mouse. O comportamento é um exame adicional, e não uma substituição do filtro de entrada: proxies residenciais limpos ou proxies móveis com ASN ativo simplesmente dão a chance de chegar ao segundo exame.
2. A sessão é um novo objeto de higiene
Antes, o erro típico era "muitas solicitações de um IP". Agora, adiciona-se "muita atividade não humana dentro de uma única sessão". Daí a prática:
- Não reutilize um único contexto de navegador para centenas de tarefas. Uma sessão longa é uma longa sequência de comportamento, onde qualquer anomalia pode se acumular. Sessões mais curtas significam menos material para pontuação.
- Mantenha a combinação "sessão ↔ IP" estável. Mudar o IP de saída no meio da sessão é uma contradição notável; para cenários com login, são necessárias sessões sticky com tempo de vida adequado à tarefa, e não uma rotação agressiva a cada solicitação.
- Não misture perfis. Uma conta — um conjunto consistente: perfil do navegador, IP, fuso horário, idioma, padrão comportamental.
3. O comportamento sintético precisará ser mais honesto — ou não ser feito de forma alguma
Emulações "humanas" ingênuas (movimento linear em direção ao centro do botão, pausas uniformes de 100 ms, clique instantâneo após o carregamento) sob verificações cruzadas trabalham contra você: elas adicionam sinal, em vez de removê-lo. Se o cenário não exigir a imitação de um humano — é mais confiável não gerar comportamento algum do que gerar um comportamento ruim. Discutimos mais sobre essa camada no material sobre biometria comportamental e proxies.
4. Endpoints de API e clientes não-navegadores — uma história à parte
O Precursor requer a execução de JavaScript. Clientes sem navegador — curl, backends móveis — e solicitações XHR/fetch para endpoints protegidos devem carregar corretamente as credenciais da sessão, ou seja, cf_clearance. Na prática, isso significa: primeiro, o navegador estabelece uma sessão válida, e depois as solicitações "rápidas" vão com seus cookies e no mesmo contexto de rede (o mesmo IP, perfil TLS acordado). A discrepância entre a sessão do navegador e o cliente HTTP é a contradição interna que eles buscam.
5. Os pontos de coleta de dados estão mudando
Onde o site ativar o Maximize Security, a coleta sem cabeça barata se tornará significativamente mais cara. A resposta sensata não é escalar a "emulação inteligente" a qualquer custo, mas revisar a fonte: API oficial da plataforma, feed de parceiros, endpoints móveis, conjuntos de dados públicos. O caminho totalmente baseado em navegador faz sentido deixar onde os dados não podem ser obtidos de outra forma.
Para onde isso está indo
O Precursor se encaixa logicamente na linha da Cloudflare do último ano: bloqueio de crawlers de IA por padrão, AI Crawl Control com regras granulares, Pay Per Crawl como uma tentativa de tornar o acesso ao conteúdo pago, e a partir de 15 de setembro de 2026 — bloqueio de crawlers de IA de uso misto em páginas com anúncios por padrão. O vetor geral: o site quer saber não "se você é humano no momento da entrada", mas "quem você é durante a visita e por que veio".
Para o mercado de automação, isso significa um deslocamento lento, mas unidirecional: o custo de uma sessão "humanoide" está aumentando, o custo de uma solicitação deixa de ser a métrica principal. Vencem aqueles que coletam menos, mas com mais precisão: sessões cuidadosas, IPs limpos para a tarefa, impressões digitais acordadas — e uma avaliação sóbria sobre quais dados realmente justificam o caminho do navegador.
Resumindo
- A partir de 13 de julho de 2026, a Cloudflare está implementando o Precursor — um detector comportamental de sessão, ativado por um único interruptor sem alterações no código do lado do site.
- Sinais: cursor, rolagem, ritmo de digitação (sem conteúdo), área de transferência, foco e visibilidade; além de verificações cruzadas de contradições.
- A avaliação se acumula durante a sessão; recarregar a página não redefine a assinatura, o clearance pode ser anulado no meio da visita.
- Proxies não "desapareceram": a camada de IP permanece como um filtro de entrada, o comportamento é um segundo exame.
- A Cloudflare ainda não publicou dados quantitativos sobre precisão e falsos positivos — é cedo para tirar conclusões sobre a real rigidez.