As APIs costumavam ter um modelo simples de tráfego. Um desenvolvedor se cadastrava, recebia uma chave, escrevia uma integração e essa integração chamava seus endpoints em uma agenda ou quando um usuário clicava em algo. A gestão de bots para APIs cresceu em torno desse modelo: autenticar a chave, limitar o volume, filtrar o tráfego claramente abusivo e manter o serviço disponível para todo mundo.
Esse modelo ainda vale, e as ferramentas criadas para ele continuam importantes. O que mudou foi quem está por trás das chamadas. A mesma chave de API agora pode carregar requisições de uma pessoa usando o app do seu cliente, de uma pessoa que pediu a um assistente de IA para fazer o trabalho, e de um agente autônomo executando uma tarefa em várias etapas durante a noite. Seus controles existentes veem uma chave e uma taxa de requisições. Suas decisões de produto, suporte e policy muitas vezes precisam saber mais.
Proof of Actor preenche essa lacuna. Ele diz à sua API quem ou o que está agindo em cada requisição e informa a evidência, e então deixa a decisão para o seu código. Esta página o compara com as principais camadas de proteção contra bots em APIs para que você veja onde cada uma se encaixa.
A versão curta
| proteção contra bots em API | Proof of Actor | |
|---|---|---|
| Pergunta principal | Esta requisição é permitida, autenticada e está dentro dos limites? | Quem ou o que está agindo, e qual é a evidência? |
| Camadas típicas | gateway de API, regras de bot em WAF, chaves de API, limites de taxa | Classificação de ator dentro da sua API ou MCP server |
| Identifica | A conta ou integração dona da chave | O ator por trás de cada requisição: Human, Human + AI, Agent ou Unknown |
| Saída | Allow, rejeitar, limitar; às vezes uma pontuação de bot | Uma classe mais uma base: verified, declared, inferred ou unknown |
| Tráfego incerto | Normalmente permitido se a chave for válida, ou rejeitado por uma regra | Unknown, com um fallback que você escolhe por rota |
| Quem decide a resposta | Configuração do gateway e do WAF | O código da sua aplicação |
| Padrão na instalação | Aplicação | Observação; nada muda até você adicionar uma policy |
| Melhor para | Disponibilidade, filtragem de abuso, cotas, responsabilização | Atender cada ator corretamente e entender o uso da API |
As seções abaixo explicam cada parte.
O que a proteção contra bots em API faz bem
Vale a pena ser específico sobre o trabalho que cada camada faz, porque o Proof of Actor foi projetado para ficar ao lado de todas elas, não para substituir nenhuma.
Gateways de API
Um gateway é a porta de entrada da sua API. Ele encerra conexões, autentica chaves de API ou tokens, roteia requisições para o serviço certo, aplica cotas e muitas vezes registra o uso para cobrança e analytics. Ele responde a "este chamador pode entrar, e por qual porta?" de forma rápida e consistente em cada endpoint.
Regras de bot em WAF
Um firewall de aplicação web com regras de bot inspeciona o tráfego em busca de padrões conhecidos de ataque e automação abusiva. Ele pode filtrar tentativas de injeção, bloquear tráfego de fontes com histórico de abuso e desafiar ou descartar requisições que pareçam scraping ou ataques de credencial. É sua melhor defesa contra tráfego que nunca deveria alcançar seu código.
Chaves e tokens de API
Chaves e tokens dão responsabilização. Cada requisição é mapeada para uma conta, então você sabe qual integração fez uma chamada, pode revogar acesso e pode atribuir uso. Tokens com escopo vão além e restringem o que um chamador pode fazer.
Limites de taxa
Limites de taxa protegem a disponibilidade. Eles impedem que uma integração consuma a capacidade destinada a todos e desaceleram tentativas de força bruta e enumeração. Limites por chave e por rota são um controle padrão e eficaz.
Juntas, essas camadas respondem muito bem às questões de proteção e responsabilização. Mantenha-as.
A pergunta para a qual elas não foram criadas
Nenhuma dessas camadas foi projetada para dizer que tipo de ator está por trás de uma requisição autenticada. Uma chave válida diz qual conta é dona da integração. Ela não diz:
- se esta chamada específica veio de uma pessoa tocando um botão no app do seu cliente,
- se uma pessoa pediu a um assistente de IA para executar a ação,
- se um agente autônomo fez a chamada como uma etapa de uma tarefa mais longa,
- ou se ninguém consegue dizer.
Essa distinção importa cada vez mais. Uma API que atende uma integração de CRM, uma ferramenta de agendamento ou uma plataforma para desenvolvedores recebe cada vez mais tráfego de agentes pelas mesmas chaves que atendem apps conduzidos por humanos. Se você quer dar aos agentes uma resposta estruturada, exigir confirmação para escritas de alto impacto conduzidas por agentes, rotular envios assistidos por IA ou simplesmente medir quanto do uso da sua API é conduzido por agentes, você precisa de contexto de ator.
O que o Proof of Actor adiciona a uma API
O Proof of Actor retorna uma das quatro classes para cada interação:
- Human: os sinais observáveis indicam uma interação conduzida por humanos.
- Human + AI: uma pessoa conduziu a interação com assistência de IA que foi declarada ou observada por meio de uma integração suportada.
- Agent: interação automatizada ou originada por um agente.
- Unknown: a evidência não sustenta uma determinação confiável.
Cada resultado também informa sua base de evidência:
- Verified: por exemplo, uma assinatura HTTP Message (RFC 9421) verificada em relação a uma chave publicada.
- Declared: o cliente ou a sua própria aplicação informou isso.
- Inferred: sinais comportamentais ou contextuais, claramente rotulados como inferência.
- Unknown: nenhuma base confiável.
Para APIs, a base verified é especialmente útil. Agentes que assinam suas requisições podem ser verificados em relação às suas chaves publicadas, que é a abordagem por trás do trabalho do IETF Web Bot Auth. Leia o texto explicativo sobre Web Bot Auth para equipes de produto para entender o contexto, e o guia sobre verificar requisições de agente assinadas para a parte de implementação.
Há um limite importante aqui. Uma assinatura válida prova qual chave assinou a requisição. Ela não prova que o agente está autorizado a executar a ação. A autorização continua onde deve ficar, no controle de acesso da própria sua API. A entrada sobre autorização de agentes explica a diferença.
Pontuações e chaves versus evidência de ator
Alguns produtos de proteção contra bots atribuem uma pontuação a cada requisição. Uma pontuação é eficiente para uma decisão de bloqueio. Ela é menos útil para decisões de produto de API, porque não diz se uma requisição legítima foi conduzida por um humano ou por um agente, e não separa fatos verificados de inferência.
As chaves de API têm a limitação oposta. Elas são precisas sobre propriedade e silenciosas sobre o ator. A chave de um cliente pode carregar todas as quatro classes em uma única hora.
O Proof of Actor mantém ambas as distinções visíveis. Sua API vê a conta pela chave, a classe do ator pelo Proof of Actor e a base que a sustenta. Cada camada responde à pergunta em que é boa.
Onde cada um roda
Gateways e WAFs rodam na borda da sua rede ou na frente dos seus serviços. Essa posição é a certa para proteção e cotas.
O Proof of Actor roda onde vive a lógica da sua API. Equipes fundadoras podem integrar por meio de middleware em Node.js, Next.js, uma camada de edge que você controla, a HTTP API genérica ou uma integração com MCP server. Veja integrações para a lista completa. Como ele roda dentro da sua aplicação, pode usar o que sua API sabe: a rota, o workflow, se um cliente se declarou e se uma assinatura foi verificada.
As decisões de roteamento permanecem no seu código
O Proof of Actor não bloqueia nada por padrão. Ele começa em modo de observação, então a instalação não muda nada na forma como sua API responde. Você vê a mistura de atores por endpoint, revisa a evidência de resultados individuais e acompanha sua taxa de Unknown.
Quando estiver pronto, você escreve policies definidas pela aplicação por rota, por classe de ator e por base. Os resultados típicos são:
- Allow: atender a requisição normalmente.
- Adapt: retornar uma resposta estruturada ou reduzida para um agente verified.
- Challenge: exigir uma etapa extra de confirmação, por exemplo uma aprovação humana em uma escrita de alto impacto.
- Review: colocar a ação em fila para que uma pessoa analise.
- Rate-limit: aplicar um limite mais rígido a uma classe e base específicas em uma rota específica.
Você pode pré-visualizar uma policy em tráfego real antes de aplicá-la, e então aplicar rota por rota. O guia sobre implantar policies conscientes de ator com segurança cobre o processo, e proteger ações sensíveis sem bloquear agentes mostra padrões comuns.
Lidando com chamadores Unknown da API
Toda API recebe tráfego que não pode ser classificado com confiança. Com controles tradicionais, uma chave válida geralmente significa que a requisição passa, e uma inválida significa que não passa. Não há nada no meio.
O Proof of Actor fornece um resultado explícito Unknown e permite que você escolha o fallback por rota. Endpoints de catálogo somente leitura podem permanecer abertos. Alterações de conta podem manter suas verificações mais rígidas existentes. Exportações em massa podem ir para revisão. Veja lidando com tráfego Unknown e tráfego automatizado Unknown para os detalhes.
Como eles se combinam
A configuração mais forte de API usa cada camada para seu próprio trabalho:
- Na borda, o WAF filtra tráfego abusivo e malformado.
- No gateway, as chaves são autenticadas, as cotas são aplicadas e o uso é registrado.
- Dentro da API, o Proof of Actor classifica cada requisição que passa e informa sua base.
- Nos seus handlers, as policies usam a classe e a base para escolher a resposta: tratamento normal para uma chamada conduzida por um humano, uma resposta estruturada para um agente verified, uma etapa de confirmação para uma escrita de alto impacto conduzida por um agente, um fallback para Unknown.
- Em analytics, sua equipe vê quais endpoints e workflows cada classe de ator usa, junto com os dados da conta vindos do gateway.
Nada nessa stack é duplicado. O gateway conhece a conta, o WAF conhece os padrões de ameaça, e o Proof of Actor conhece o ator.
Quando focar em cada um
Foque primeiro em proteção contra bots em API quando seus principais problemas forem abuso, disponibilidade ou uso não medido: ataques de credencial contra endpoints de autenticação, scraping agressivo ou uma integração consumindo a capacidade das outras.
Foque em Proof of Actor quando suas principais perguntas forem sobre seus chamadores: quanto do tráfego da sua API é conduzido por agentes, quais agentes chamam quais endpoints, onde o uso conduzido por humanos e por agentes diverge e quais rotas precisam de uma policy consciente de ator. O caso de uso APIs e identificação de agentes de IA para APIs vão mais fundo.
A maioria das equipes que operam uma API em produção precisa de respostas para os dois.
Comece
O Proof of Actor está em beta privada. Equipes fundadoras selecionadas podem receber até 12 meses de acesso gratuito dentro de limites de uso acordados, sem cobrança automática. Candidate-se ao acesso antecipado e nos conte sobre a API e os chamadores que você quer entender.