A lista de permissão de user agent é um dos padrões mais antigos da web. Você mantém uma lista de nomes de crawlers e clientes em que confia. Quando uma requisição chega com um header User-Agent correspondente, você a libera, pula um desafio ou entrega uma página mais leve. Leva minutos para configurar e todos no time entendem.
Esse padrão fazia mais sentido quando os principais visitantes automatizados eram alguns crawlers de busca e poucas ferramentas de monitoramento. Hoje, agentes de IA, assistentes e clientes automatizados chegam às aplicações em números crescentes, e muitos deles anunciam um nome. Alguns desses nomes são reais. Alguns são copiados. O header não consegue dizer qual.
Proof of Actor adota uma abordagem diferente. Ele trata uma string de User-Agent como o que ela é, uma declaração, e a exibe junto com evidências mais fortes quando essas evidências existem. Esta página explica os limites do allowlisting por nome, onde as verificações em nível de rede ajudam e como assinaturas verificadas e uma classe Unknown explícita mudam o cenário.
A versão curta
| Lista de permissão de user agent | Proof of Actor | |
|---|---|---|
| Evidência principal | Um nome no header User-Agent | Assinaturas, declarações e sinais, cada um rotulado com sua base |
| O cliente pode falsificar? | Sim, enviando a mesma string | Uma base declarada pode ser alegada; uma base verificada exige a chave de assinatura |
| Saída | Na lista ou não | Human, Human + AI, Agent ou Unknown, além de uma base |
| Tráfego incerto | Tratado como não permitido, ou liberado por padrão | Unknown, com um fallback que você escolhe por rota |
| Pessoas com apoio de IA | Invisível; elas usam navegadores comuns | Uma classe distinta, Human + AI, quando declarada ou observada |
| Manutenção | Atualizações manuais da lista conforme os nomes mudam | Chaves publicadas pelos operadores dos agentes; políticas no seu código |
| Padrão na instalação | O que a lista permitir | Observação; nada muda até você adicionar uma política |
| Melhor para | Roteamento barato de clientes conhecidos e bem-comportados | Contexto de ator baseado em evidências para decisões de produto e política |
O restante da página explica cada linha.
Por que o allowlisting por User-Agent é suscetível a falsificação
O header User-Agent é definido pelo cliente. Um navegador o define, um script o define e uma framework de agente o define. Nada em HTTP verifica se o valor é verdadeiro. Se sua lista de permissão confiar em uma string, qualquer pessoa que copiar essa string recebe o mesmo tratamento.
Isso é chamado de user agent spoofing, e é comum por um motivo simples: não custa nada. Um scraper que quer evitar um desafio só precisa pegar emprestado o nome de um crawler em que você confia. Um cliente que se comporte mal pode afirmar ser um assistente popular. Uma ferramenta legítima pode até enviar uma string genérica de navegador porque um padrão de biblioteca fez isso.
O resultado é que uma lista de permissão de user agent tem dois modos de falha:
- Falsa confiança: um cliente não confiável alega um nome confiável e passa.
- Falsa dúvida: um cliente legítimo envia uma string inesperada ou genérica e falha.
Nenhuma dessas falhas é visível apenas pelo header. Essa é a limitação central, e nenhuma quantidade de manutenção da lista elimina isso.
Para que o header ainda serve
Nada disso significa que você deva ignorar strings de User-Agent. Crawlers e agents bem-comportados se apresentam honestamente, e o nome é um indício útil para roteamento, analytics e depuração. Ele diz o que um cliente afirma ser.
O lugar certo para essa informação é como uma declaração, ponderada junto com outras evidências, e não como uma chave que libera acesso sozinha. Proof of Actor registra isso exatamente dessa forma.
DNS reverso e listas de IP: medidas parciais
Muitos times reforçam uma lista de permissão com verificações de rede. Elas ajudam e valem a pena ser entendidas com precisão.
Verificação de DNS reverso
Alguns operadores de crawler documentam um processo de verificação: consultar o hostname do endereço IP da requisição, verificar se ele pertence ao domínio do operador e então consultar esse hostname e confirmar que ele resolve de volta para o mesmo IP. Quando esse ciclo é concluído com sucesso, você tem evidência real de que a requisição veio da infraestrutura do operador.
Os limites são práticos. Isso só funciona para operadores que documentam e oferecem suporte. Acrescenta consultas de DNS que você precisa armazenar em cache. E isso informa sobre a rede, não sobre qual produto ou agente fez a requisição naquela rede.
Faixas de IP publicadas
Outros operadores publicam as faixas de IP usadas por seus clientes automatizados. Comparar uma requisição com essas faixas é rápido e fornece evidência semelhante à do DNS reverso. Há uma discussão em andamento no IETF sobre um formato padrão para publicar essas faixas, mas até novembro de 2026 não existe um padrão estabelecido, e a cobertura depende de cada operador decidir publicar.
A evidência de IP também fica mais fraca à medida que mais agents passam a rodar em infraestrutura compartilhada de nuvem, atrás de proxies ou a partir do próprio dispositivo de um usuário. Um endereço de nuvem pode hospedar muitos clientes não relacionados, e um agent atuando no navegador de uma pessoa parece a rede dessa pessoa.
O que as verificações de rede realmente acrescentam
DNS reverso e listas de IP transformam algumas declarações em algo mais forte para um subconjunto de operadores conhecidos. Elas não cobrem a cauda longa de agents e ferramentas, e não ajudam em nada com pessoas trabalhando ao lado de IA. São medidas parciais: valem a pena ser usadas, mas não bastam sozinhas.
Assinaturas versus declarações
A forma mais forte de evidência é uma assinatura criptográfica. Com HTTP Message Signatures, definido em RFC 9421, um cliente assina partes selecionadas de cada requisição com uma chave privada. O verificador busca a chave pública publicada do operador e valida a assinatura. Se ela for validada, a requisição foi assinada pelo titular dessa chave e as partes assinadas não foram alteradas no caminho.
O grupo de trabalho IETF Web Bot Auth está padronizando como clientes automatizados usam essas assinaturas e como publicam suas chaves. Nosso guia sobre Web Bot Auth para equipes de produto cobre o status atual.
Proof of Actor usa uma assinatura válida como evidência Verified. Uma string de User-Agent, uma client hint ou uma autodescrição no corpo da requisição contam como Declared. Sinais comportamentais e contextuais contam como Inferred, e são rotulados dessa forma. Cada resultado informa em qual base ele se apoia, para que seu time nunca confunda uma alegação com uma verificação. Veja a entrada base da evidência para as definições completas.
Uma limitação vale até para evidências verificadas. Uma assinatura válida prova qual chave assinou a requisição. Ela não prova que o agente tem permissão para fazer o que está pedindo para fazer. Isso é uma questão de autorização de agent, e ela continua na sua aplicação.
Lidando com Unknown em vez de adivinhar
Uma lista de permissão força toda requisição para uma de duas caixas: na lista ou fora dela. Na prática, isso significa que o tráfego incerto recebe o que quer que seja seu padrão, e o padrão geralmente é escolhido uma única vez para todo o site.
Proof of Actor trata Unknown como um resultado de primeira classe. Quando a evidência não sustenta uma determinação confiável, ele diz isso em vez de adivinhar. Suas políticas então decidem o que Unknown significa em cada rota:
- Em documentação pública ou páginas de marketing, permitir.
- Em endpoints de busca ou listagem, permitir com seus limites normais de rate limit.
- Em mudanças de conta, manter suas verificações existentes.
- Em ações de alto impacto, enviar para revisão ou pedir um sinal mais forte.
O guia sobre lidando com tráfego Unknown e a entrada classificação Unknown mostram esses padrões. Acompanhar sua taxa de Unknown ao longo do tempo também mostra quanto do seu tráfego ainda depende de evidências fracas.
E as pessoas que usam IA como apoio?
Uma lista de permissão de user agent não diz nada sobre uma pessoa que usa um assistente de IA dentro de um navegador comum. O User-Agent dela é uma string normal de navegador. Ainda assim, muitos produtos querem reconhecer essa interação, por exemplo para rotular envios redigidos com IA ou entender como usuários com apoio de IA passam pelo onboarding.
Proof of Actor relata essas interações como Human + AI quando o suporte é declarado ou observado por meio de uma integração suportada. Ele não adivinha apenas pelo estilo de escrita. Leia mais em interação com apoio de IA.
Indo de uma lista de permissão para políticas baseadas em evidências
Você não precisa remover sua lista de permissão no primeiro dia. Um caminho seguro é assim:
- Instale em modo de observação. Proof of Actor não muda nada. Sua lista de permissão continua funcionando.
- Compare. Para cada rota, veja quais requisições permitidas carregam evidência verificada, quais carregam apenas uma declaração e quais acabam como Unknown.
- Pré-visualize políticas. Elabore uma política que trate de forma diferente agentes verificados, agentes declarados e Unknown, e veja seu efeito no tráfego real.
- Implemente rota por rota. Comece pelas rotas em que um nome falsificado teria mais impacto.
- Mantenha a lista de permissão como um indício. Os nomes continuam úteis para roteamento e analytics, agora com sua base visível.
O guia sobre lançar políticas cientes de actor com segurança cobre cada etapa, e requisições automatizadas verificadas explica como clientes assinados se encaixam nisso.
Quando uma lista de permissão é suficiente
Para roteamento de baixo risco, como servir uma página mais leve para um crawler conhecido em conteúdo público, uma lista de permissão de user agent costuma ser suficiente. O custo de um nome falsificado é pequeno.
Quando a decisão tem consequências, como pular um desafio, expor dados mais ricos ou permitir uma escrita, você quer evidência que possa verificar. É aí que Proof of Actor se encaixa, trabalhando junto com as verificações de rede e os controles de borda que você já opera.
Comece agora
Proof of Actor está em beta privada. Equipes selecionadas do Founding Developer Program podem receber até 12 months de acesso gratuito dentro dos limites de uso acordados, sem cobrança automática. Solicite acesso antecipado e nos diga quais clientes você permite hoje e quais rotas quer proteger com evidências melhores.