Políticas de agentes pessoais da Cloudflare: como permitir, limitar ou bloquear assistentes de IA

Os controles de bots mais recentes da Cloudflare existem para tirar os donos de sites de uma armadilha específica. Como a Cloudflare explica no seu post sobre Trusted Agent Delegation, quando um usuário abusa de um agente compartilhado para credential stuffing, scraping ou teste de cartões, o site consegue detectar o abuso, mas só pode bloquear o agente, o que também bloqueia todos os seus usuários legítimos. Com cada vez mais clientes enviando assistentes de IA para navegar, comparar e comprar por eles, essa é uma escolha cara demais para ser imposta.

Os novos controles permitem escolher uma política diferente para cada agente pessoal compatível, em vez de se contentar com um bloqueio de tudo ou nada. A seguir, explico como eles funcionam, apresento um modelo de implantação que você pode reutilizar e mostro onde as evidências ainda são frágeis.

Por que agentes pessoais precisam de uma política própria

Crawlers e agentes podem parecer iguais nos seus logs, mas levantam perguntas diferentes. Um crawler de treinamento coleta conteúdo para construir um modelo. Um crawler de busca indexa páginas para exibi-las depois.

Com crawlers, a pergunta é se você quer que o seu conteúdo seja usado. Com agentes pessoais, a pergunta é se você quer atender um cliente que escolheu enviar um software no lugar dele. O lado dos crawlers tem seu próprio conjunto de decisões, abordado no nosso mapa de migração de crawlers da Cloudflare para equipes de busca.

Encare o argumento do volume com cautela. A Cloudflare afirma que o tráfego agêntico está crescendo rapidamente e pode superar a navegação humana tradicional num futuro próximo. Em setembro, o CEO da Cloudflare, Matthew Prince, previu que o tráfego de bots chegaria a 1,000 vezes o tráfego humano em cinco anos. São previsões de uma empresa que vende ferramentas para gerenciar esse tráfego. Não são medições.

A ideia mais útil é o que a Cloudflare chama de Princípio da Intermediação: a relação comercial entre usuários e sites, assim como as responsabilidades de segurança de cada participante, deve ser mantida independentemente da intermediação. O seu cliente continua sendo o seu cliente quando um assistente faz os cliques. Boa parte deste lançamento é uma tentativa de tornar esse princípio viável na prática.

A escala é o motivo para prestar atenção mesmo que você não use a Cloudflare. A empresa diz que mais de 20% dos domínios da web estão por trás da sua rede, então os padrões e categorias que ela define influenciam como uma grande parte da web trata os agentes.

O que mudou nas políticas de acesso

A configuração fica em Security Settings. Como explica o anúncio de agentes pessoais da Cloudflare, você define uma política geral de Agents e depois escolhe uma política diferente para cada agente pessoal compatível. Cada agente recebe uma destas ações:

• Allow (do not block): o tráfego correspondente passa. Daqui em diante, chamo essa ação apenas de Allow.
• Block on pages with ads: o agente é barrado em páginas com anúncios, mas ainda consegue acessar o restante do site.
• Block: o tráfego correspondente é bloqueado em todo o site.

Para contextualizar, o painel de Account Abuse Protection, que dá base a esses recursos, foi lançado em 2 de outubro de 2026.

Como funciona a herança

É aqui que as equipes costumam ser pegas de surpresa. Segundo a documentação de políticas de acesso da Cloudflare, os agentes pessoais herdam a política de Agents por padrão, e alterar a política de Agents atualiza cada agente pessoal. Você pode definir ações individuais novamente depois, mas as suas exceções por agente não sobrevivem a uma edição da política principal.

A Cloudflare recomenda Allow para agentes pessoais. Para a maioria das empresas, esse é o padrão certo, pelos motivos que a matriz de decisão abaixo explica.

Como ler a categoria Personal Assistants

Em Security Analytics, o gráfico de Bot Analysis agora mostra Personal Assistants como uma nova categoria, ao lado de Verified Bot, Likely Human, Likely Automated e Automated. Abra essa visualização antes de mexer em qualquer política. Verifique quanto tráfego de assistentes reconhecidos você recebe e se ele é estável ou tem picos em torno de eventos específicos. Acima de tudo, verifique quais caminhos ele acessa.

Os caminhos definem a política. Um assistente lendo artigos sustentados por anúncios é uma questão de receita. Um que acessa login e checkout é uma questão de fraude e conversão. O mesmo volume pode justificar configurações muito diferentes dependendo de onde ele chega.

Uma limitação vale desde o primeiro dia. A documentação da Cloudflare afirma que requisições de assistentes que ela não reconhece aparecem como tráfego comum. Trate a categoria como um piso, não como uma contagem completa.

Controle por conta com Hashed User ID

Esta é a parte do lançamento que ataca diretamente a armadilha do agente compartilhado. Se parecer que um invasor está usando um agente em uma conta, os analistas de fraude podem mitigar essa conta com uma regra de WAF baseada no seu Hashed User ID, sem bloquear o agente para todas as outras pessoas que dependem dele. A cobertura independente do Unite.AI descreve o mesmo mecanismo: a regra mira o Hashed User ID da conta, e não o agente como um todo.

Existem duas ações. Managed Challenge adiciona atrito, enquanto Block interrompe de vez as requisições da conta. A documentação de Account Abuse Protection da Cloudflare diz que apenas a conta visada é afetada, inclusive quando ela usa um assistente de IA do qual outros usuários dependem.

O painel também exibe sinais de credenciais. No exemplo de painel da própria Cloudflare, aproximadamente 2.4K eventos resultaram em nome de usuário ou senha vazados, contra 11.7K eventos em que as credenciais foram classificadas como limpas. Isso mostra como é a visualização. Não é uma referência para o seu próprio tráfego.

Planeje considerando duas restrições. Primeiro, o Account Abuse Protection está em Early Access para clientes do Bot Management Enterprise, sem custo adicional por um período limitado, até ficar disponível para todos. Faça o orçamento como se o preço fosse mudar. Segundo, a documentação da Cloudflare limita a visibilidade de assistentes de IA a eventos de login e cadastro, então abusos em outros pontos de uma sessão não serão atribuídos a um assistente por meio desse recurso.

Matriz de decisão por modelo de negócio

A configuração certa depende de como o seu site ganha dinheiro. Trate as posições abaixo como insumos para a etapa de Exceções do playbook mais adiante. Elas são pontos de partida. Se a sua própria linha de base indicar outra coisa, siga os seus dados.

Publishers financiados por anúncios

Quando um assistente lê o seu artigo e o resume para o usuário, essa visita pode não gerar nenhuma receita de anúncios. A própria Cloudflare já pendeu para esse lado. O seu anúncio de julho de 2026 dizia que, para todos os novos domínios integrados à Cloudflare, as categorias Training e Agent seriam bloqueadas por padrão em páginas que exibem anúncios, enquanto Search continuaria permitida. A documentação atual descreve padrões diferentes, tema ao qual volto mais abaixo, então verifique as suas próprias zonas.

SaaS

Em um produto SaaS, um agente que faz login provavelmente é um cliente pagante automatizando o próprio trabalho. Bloquear agentes em massa traz o risco de fluxos de trabalho quebrados e de uma enxurrada de tickets de suporte. A configuração recomendada, Allow, se encaixa nesse modelo. Quando surgir abuso, aja sobre o Hashed User ID, e não sobre o agente inteiro.

E-commerce

Os agentes já chegam ao checkout. Dados do Microsoft Clarity mostraram o checkout aparecendo em 25% das sessões de agentes de IA, contra 15% nas sessões humanas. Bloqueie um agente e você pode estar bloqueando compradores.

Bloqueios generalizados acontecem. No início de outubro, o Muse, da Meta, respondia por 72% das requisições de agentes de IA nos dados da HUMAN, e a Amazon bloqueou o Muse de fazer compras no seu site. Sugerimos tratar qualquer bloqueio generalizado como a decisão de uma empresa específica, não como um modelo para a sua.

A exposição a fraudes também é real. A Arkose Labs relatou que 65.2% dos seus clientes viram agentes de IA chegarem a fluxos de login, cadastro e checkout. Trata-se de uma parcela dos clientes da Arkose, não de sessões. Sugerimos ler esse dado como uma indicação de tendência, e não como referência para o seu próprio site. Mesmo assim, ele reforça a ideia de combinar Allow com monitoramento ativo de contas, em vez de tratar a decisão como aberto contra fechado.

Conteúdo e comércio combinados

Muitos sites mantêm artigos sustentados por anúncios ao lado de checkout, área de membros ou um produto com login. Uma única ação para o site inteiro raramente serve para eles. Um bom começo é manter a política geral de Agents em Allow, para que os agentes consigam acessar páginas de login, conta e checkout, e aplicar Block on pages with ads apenas aos agentes cuja linha de base mostre leitura intensa de páginas com anúncios. Essa ação acompanha os anúncios, não a seção do site. Confirme que as suas páginas de comércio e de áreas logadas não exibem anúncios, ou o bloqueio também chegará até elas. Divida a responsabilidade seguindo a mesma lógica: a equipe de conteúdo ou de receita cuida das exceções em páginas com anúncios, e a equipe de fraude cuida das respostas por conta.

Tabela-resumo

Playbook: Linha de base, Herança, Exceções, Contenção e Revisão

Sugerimos executar isto como um ciclo de cinco etapas. Cada etapa gera um resultado concreto, para que você saiba quando ela terminou e de onde retomar na próxima revisão.

Etapa 1: Linha de base

Analise o tráfego de Personal Assistants em Bot Analysis por um período longo o bastante para cobrir os ciclos semanais normais e eventuais promoções. Agrupe as páginas acessadas pelos assistentes em páginas com anúncios, login e cadastro, páginas de produto e checkout. Resultado: uma visualização salva em Bot Analysis e os principais caminhos por agente.

Etapa 2: Herança

Defina primeiro a política geral de Agents, já que todos os agentes pessoais a herdam. Registre-a como a primeira linha de um log de exceções, com a data e quem aprovou. Trate qualquer edição posterior como uma solicitação de mudança e registre as configurações atuais por agente antes que alguém mexa nela, porque a edição as redefine. Resultado: uma política principal registrada e um acordo de que ela só muda mediante revisão.

Etapa 3: Exceções

Comece todos os agentes em Allow. Mude um agente para Block on pages with ads ou Block somente quando houver um registro no log que justifique. Veja um modelo ilustrativo, não um registro real de cliente:

Resultado: um registro por exceção. Qualquer exceção sem registro volta para a política principal na próxima revisão.

Etapa 4: Contenção

Se você tem Bot Management Enterprise, ative o Account Abuse Protection e prepare regras de WAF que mirem um Hashed User ID. Comece com Managed Challenge e escale para Block apenas quando as evidências sustentarem isso. Escreva a escalada como um runbook de kill switch para agentes de IA, com gatilhos e responsáveis claros, para que o analista de plantão não precise improvisar. Registre cada regra de conta da mesma forma que registra uma exceção: referência da conta, ação, gatilho, responsável e data de expiração. Resultado: um caminho de escalada documentado e um log de regras.

Etapa 5: Revisão

Faça revisões mensais ou trimestrais, dependendo do tráfego. Verifique os padrões em domínios recém-adicionados, reaplique as exceções registradas após qualquer mudança na política principal, encerre regras de conta de que você não precisa mais e reavalie as configurações após grandes lançamentos de agentes. Depois, volte à Etapa 1 com uma nova linha de base.

É a definição de responsáveis que mantém o ciclo honesto. As equipes de marketing ou de receita devem ser donas das decisões sobre páginas com anúncios, porque conseguem pesar visitas contra receita. As equipes de segurança ou de fraude devem ser donas das ações por conta, porque são elas que têm as evidências.

Erros comuns

Tratar Allow como identidade. Como observa o Forkast, uma política de agentes controla se o tráfego correspondente é permitido, mas não estabelece, por si só, a identidade da conta do usuário nem quem autorizou a ação específica. A sua autenticação normal continua valendo, seja com senhas e MFA, seja com uma implantação de passkeys com recuperação sólida.

Presumir que assinaturas verificam a pessoa. Uma assinatura Web Bot Auth autentica a identidade do agente ou do bot. Ela não diz nada sobre a pessoa por trás dele.

Bloquear um agente compartilhado para deter um único abusador. Isso corta o acesso de todos os usuários legítimos do agente. Use mitigação por conta sempre que possível.

Esquecer a herança. Edite a política principal de Agents e todas as escolhas por agente precisarão ser reaplicadas.

Interpretar um número baixo em Personal Assistants como pouco tráfego de agentes. Assistentes não reconhecidos aparecem como tráfego comum, então uma categoria pequena pode esconder um cenário maior.

Ressalvas e limites

A lacuna de visibilidade. Apenas os assistentes que a Cloudflare reconhece recebem rótulo e controle por agente. A sua política cobre os agentes que a Cloudflare consegue identificar, não todos os assistentes automatizados.

Fontes conflitantes sobre os padrões. O blog de julho de 2026 dizia que novos domínios bloqueariam Training e Agent em páginas com anúncios por padrão. A documentação atual diz que, para novos domínios, Search, Agents e Training usam Allow por padrão. Quando as duas divergirem, confie no seu painel.

Limites de detecção. No teste da própria Resemble AI, ferramentas de bots identificaram entre 3.1% e 14.8% dos agentes de IA disfarçados. É um número de fornecedor, sem tamanho de amostra publicado, mas a direção é clara: agentes feitos para parecer humanos são difíceis de detectar.

A lacuna de identidade. A Arkose Labs constatou que 97.7% das sessões legítimas de agentes de IA não tinham nenhum ID verificado entre 1º de julho e 30 de setembro. Sugerimos planejar partindo do pressuposto de que o tráfego legítimo de agentes pode chegar até você sem nenhuma identidade verificada associada.

Padrões ainda iniciais. O post sobre Trusted Agent Delegation menciona uma coalizão trabalhando em delegação de agentes, mas não cita nenhum membro, e o site da própria coalizão também não. Esse site diz que os padrões abertos estão sendo desenvolvidos no IETF e no W3C. Espere que os mecanismos mudem à medida que esse trabalho amadurecer.

Números sem link. Vários números e citações de terceiros neste artigo têm a fonte atribuída, mas não têm link para as publicações originais. Verifique a metodologia e as datas na fonte antes de reutilizá-los. As previsões de tráfego também vêm da própria Cloudflare, então use-as como indicação de direção, não para planejamento de capacidade.