Durante a maior parte da história da web, o tráfego automatizado tinha uma função na stack de segurança: ser identificado e ser interrompido. O gerenciamento de bots surgiu em torno dessa função. Ele fica na borda da sua infraestrutura, pontua requisições e bloqueia ou desafia as que parecem abusivas. Ele faz isso muito bem, e você deve mantê-lo.
Os agents de IA mudaram o que as aplicações precisam saber. Uma parcela crescente das requisições automatizadas agora vem de agents agindo em nome de clientes reais: um assistente comparando planos, um agent abrindo um ticket de suporte, um cliente chamando seu MCP server para concluir uma tarefa. Ao mesmo tempo, muitas pessoas usam seu produto com um assistente de IA ao lado. Isso não são ataques. São usuários, e merecem a experiência correta em vez de uma página de bloqueio.
Essa é a lacuna que o Proof of Actor preenche. Esta página compara as duas categorias de forma direta, para que você veja onde cada uma se encaixa.
A versão curta
| Gerenciamento de bots | Proof of Actor | |
|---|---|---|
| Pergunta principal | Esta requisição deve ser interrompida? | Quem ou o que está agindo, e qual é a evidência? |
| Onde roda | Na borda, em frente à sua aplicação | Dentro da sua aplicação, API ou MCP server |
| Saída típica | Permitir, bloquear ou desafiar; muitas vezes uma pontuação | Human, Human + AI, Agent ou Unknown, mais uma base |
| Trata pessoas com apoio de IA como | Em geral indistinguíveis de outras pessoas | Uma classe distinta, Human + AI |
| Trata tráfego incerto como | Frequentemente desafiado ou bloqueado | Unknown, com um fallback que você escolhe por route |
| Quem decide a resposta | O conjunto de regras da borda | O código da sua aplicação |
| Comportamento padrão na instalação | Execução | Observação; nada muda até você adicionar uma política |
| Melhor para | Interromper credential stuffing, scraping abusivo e ataques volumétricos | Decisões de produto, análise e política para todo ator |
O restante desta página explica cada linha.
Duas perguntas diferentes
O gerenciamento de bots responde a uma pergunta de proteção. O objetivo é manter automação abusiva longe da sua infraestrutura, das suas contas e do seu inventário. Todo sinal coletado serve a esse objetivo, e a saída é uma decisão: deixar a requisição passar, bloqueá-la ou colocar um desafio na frente dela.
O Proof of Actor responde a uma pergunta de entendimento. O objetivo é dizer à sua aplicação quem ou o que está conduzindo cada interação, para que você possa decidir como atendê-la. A saída não é um veredito sobre a requisição. É uma classificação com sua evidência:
- Human: os sinais observáveis indicam interação dirigida por uma pessoa.
- Human + AI: uma pessoa conduziu a interação com assistência de IA que foi declarada ou observada.
- Agent: interação automatizada ou originada por agent, com suporte de identidade verificável ou de uma inferência qualificada.
- Unknown: a evidência não sustenta uma determinação confiável.
Cada resultado também declara sua base de evidência: verified, declared, inferred ou unknown. Essa é a informação de que uma decisão de produto precisa, e é a informação que uma pontuação de proteção não foi feita para carregar.
Onde cada um roda
O gerenciamento de bots normalmente roda na borda da rede ou em um proxy reverso, em frente a todo o resto. Essa posição é exatamente a certa para proteção. Ela vê o tráfego cedo, absorve ataques antes que eles custem algo, e mantém seus servidores de origem limpos.
O Proof of Actor roda onde a lógica da sua aplicação vive: middleware de servidor, Next.js, a camada de borda que você controla, uma integração de navegador aprovada, uma API HTTP genérica ou seu MCP server. Essa posição dá acesso ao que sua aplicação sabe: qual route está sendo chamada, a que workflow ela pertence, se seu próprio assistente executou uma ação e se um client se declarou. Veja os caminhos de integração para a lista completa.
Como os dois rodam em lugares diferentes, eles não competem pela mesma função. Uma requisição pode passar pelo seu gerenciamento de bots, chegar à sua aplicação e então receber contexto de ator que molda a resposta.
Pontuações versus evidência
Muitos produtos de proteção expressam seu julgamento como uma pontuação. Uma pontuação é eficiente para uma decisão de bloqueio: escolha um limiar, aja acima dele. Ela é muito menos útil quando a pergunta é "que experiência este ator deve receber?"
Uma pontuação não diz se uma requisição de baixo risco veio de uma pessoa, de uma pessoa trabalhando com um assistente ou de um agent bem-comportado. Ela não diz quais partes da conclusão foram verificadas e quais foram inferidas. E não consegue expressar "não sabemos" sem transformar isso em um número.
O Proof of Actor mantém essas distinções. Um resultado de verified para agent significa que uma assinatura de requisição foi verificada contra uma chave publicada, por exemplo por meio de HTTP Message Signatures. Um resultado declared significa que um client ou sua própria aplicação declarou isso. Um resultado inferred é rotulado como inferência. E Unknown é uma resposta de primeira classe, e não um padrão oculto. Sua equipe pode ler cada resultado e ver exatamente no que ele se baseia.
Pessoas com apoio de IA não são bots
O grupo que mais cresce na maioria das aplicações é o de pessoas trabalhando com IA. Elas redigem mensagens com um assistente, preenchem formulários com ajuda e navegam pelo seu produto com uma ferramenta de IA ao lado. Ferramentas de proteção não foram feitas para separá-las de outras pessoas, e não há motivo para isso.
O seu produto muitas vezes foi feito. Você pode querer rotular tickets de suporte redigidos por IA para que a equipe certa os trate, medir como usuários com apoio de IA avançam no onboarding ou oferecer a eles um caminho mais fluido. O Proof of Actor dá a esse grupo sua própria classe, Human + AI, e a reporta apenas quando a assistência é declarada ou observável por meio de uma integração suportada. Saiba mais na entrada de glossário interação com apoio de IA.
Unknown é uma resposta, não uma ameaça
Todo classificador encontra tráfego que não consegue explicar. Sistemas de proteção são construídos para agir com cautela, então o tráfego incerto frequentemente recebe um desafio. Essa é uma escolha sensata na borda.
Dentro da sua aplicação, um único padrão cauteloso costuma ser a escolha errada. Uma requisição unknown para uma página pública de documentação e uma requisição unknown para alterar a senha de uma conta merecem tratamentos muito diferentes. O Proof of Actor retorna Unknown como seu próprio resultado e permite que você defina o fallback por route: permitir em páginas públicas, manter suas verificações existentes em mudanças de conta, encaminhar para revisão em ações de alto impacto. O guia sobre como tratar tráfego Unknown mostra os padrões.
Quem decide a resposta
Com o gerenciamento de bots, quem decide é o conjunto de regras na borda. Isso é eficiente e mantém as decisões consistentes entre suas propriedades.
Com o Proof of Actor, sua aplicação decide. O produto fornece o contexto de ator; seu código aplica a política. Você pode servir agents verificados com uma API estruturada em vez de páginas feitas para pessoas, manter a experiência padrão para sessões humanas, rotular submissões com apoio de IA e solicitar credenciais mais fortes em ações sensíveis quando suas próprias condições pedirem isso. As políticas são escritas por route, por classe de ator e por base, e ficam ao lado do restante da sua lógica de negócio.
Observação primeiro
O gerenciamento de bots geralmente é instalado para executar, porque todo o seu valor está em interromper abuso.
O Proof of Actor começa em modo de observação. Instalá-lo não muda nada no comportamento da sua aplicação. Você vê sua mistura real de atores por route, revisa a evidência, pré-visualiza o efeito de uma política contra tráfego real e só executa quando estiver pronto, uma route de cada vez. O guia sobre implantar políticas sensíveis ao ator com segurança cobre o processo.
Como os dois funcionam juntos
A configuração mais forte usa ambos, cada um na sua camada:
- Na borda, o gerenciamento de bots interrompe credential stuffing, scraping abusivo e ataques volumétricos.
- Na sua aplicação, o Proof of Actor classifica o tráfego que passa como Human, Human + AI, Agent ou Unknown, com sua base.
- No seu código, as políticas usam esse contexto para escolher a experiência: a API estruturada para um agent verificado, o fluxo normal para uma pessoa, um rótulo para uma submissão com apoio de IA, um fallback explícito para Unknown.
- Na sua análise, sua equipe vê quais routes e workflows cada classe de ator usa, para que produto e segurança trabalhem a partir da mesma visão.
Registrar a decisão da borda ao lado do resultado do ator torna a visão completa: o que a proteção fez, e quem realmente estava agindo.
Quando escolher cada um
Escolha gerenciamento de bots quando seu principal problema for abuso: tentativas de account takeover, acúmulo de inventário, scraping agressivo ou floods de tráfego.
Escolha Proof of Actor quando sua principal pergunta for sobre seus usuários: quanto do seu produto os agents já usam, quais agents chamam sua API ou MCP server, onde pessoas com apoio de IA têm dificuldades e quais routes precisam de uma política sensível ao ator.
A maioria das equipes que opera uma aplicação, API ou MCP server em produção precisa de respostas para ambos, e é por isso que os dois pertencem à mesma stack.
Comece
O Proof of Actor está em beta privado. Equipes fundadoras selecionadas podem receber até 12 months de acesso gratuito dentro de limites de uso acordados, com suporte direto da equipe que o constrói. Solicite acesso antecipado e nos conte sobre a aplicação e a interação que você quer entender.