AUTOMAÇÃO VERIFICADA

Reconheça solicitações automatizadas verificadas

Quando um cliente automatizado assina suas solicitações, sua application pode verificar essa assinatura e tratar o solicitante de acordo. Proof of Actor transforma essa verificação em um resultado claro, roteável.

Obter acesso antecipado Explorar como funciona

Por Toshendra SharmaFundador e CEO, AgentCredia · Updated November 13, 2026

Nem todo tráfego automatizado é igual

Clientes automatizados chegam à sua application a cada minuto: rastreadores de busca, ferramentas de monitoramento, integrações de parceiros, assistentes de AI buscando páginas para um usuário e agentes autônomos concluindo tarefas. Por anos, a única forma de a maioria das applications diferenciá-los era pelo cabeçalho user-agent, uma string que qualquer cliente pode definir como quiser.

Isso deixa as equipes de application em um impasse. Tratar toda automação com desconfiança degrada a experiência de agentes legítimos dos quais seus clientes dependem. Confiar no cabeçalho convida qualquer um a se passar por um rastreador conhecido.

Solicitações automatizadas verificadas mudam o quadro. Quando um cliente automatizado assina suas solicitações com uma chave que publicou, sua application pode verificar a assinatura e saber, criptograficamente, qual cliente assinou a solicitação. Proof of Actor transforma essa verificação em um único resultado consistente de actor para o qual seu código pode rotear. Para uma análise mais próxima do que essa verificação estabelece e do que não estabelece, leia o que solicitações assinadas por agentes de AI comprovam.

Como a assinatura de solicitações funciona

A abordagem emergente para tráfego automatizado usa HTTP message signatures, padronizadas em RFC 9421, que define como criar, codificar e verificar assinaturas sobre componentes de uma mensagem HTTP. O cliente assina partes selecionadas de cada solicitação com uma chave privada e inclui a assinatura e seus parâmetros nos headers. Ele publica a chave pública correspondente em um local vinculado a um identificador que controla, normalmente seu domínio.

Quando a solicitação chega, o receptor busca ou localiza a chave publicada, reconstrói o conteúdo assinado e verifica a assinatura. Se ela for validada, a solicitação foi assinada pelo detentor dessa chave. O trabalho sobre assinatura de tráfego automatizado continua no grupo de trabalho IETF Web Bot Auth working group, cujo escopo abrange autenticar criptograficamente clientes automatizados, como rastreadores e agentes de AI agindo em nome de usuários finais; a entrada do glossário Web Bot Auth resume isso. O post o que solicitações assinadas por agentes de AI comprovam percorre uma solicitação verificada do início ao fim, e o caso de uso de APIs mostra onde a verificação traz retorno primeiro.

O guia sobre verificação de solicitações assinadas por agentes cobre a mecânica em detalhe, incluindo timestamps, janelas de replay e cache de chaves.

O que uma assinatura verificada comprova, e o que ela não comprova

Essa distinção é a parte mais importante de lidar bem com solicitações automatizadas verificadas.

Uma assinatura válida comprova que a solicitação foi assinada com uma chave associada ao identificador publicado. Se a chave pertence ao domínio de um operador, a solicitação veio de um cliente que possui a chave desse operador.

Uma assinatura válida não comprova:

quem instruiu o agente, ou se alguma pessoa pediu essa ação;
que uma pessoa delegou autoridade ao agente;
a identidade jurídica no mundo real por trás do operador;
que a ação solicitada é segura ou permitida na sua application.

Essas são questões separadas. Sua application responde a elas com suas próprias credenciais, modelo de autorização e política. Proof of Actor as mantém separadas de forma deliberada, e a página Detecção e Limitações explica exatamente o que cada tipo de evidência pode estabelecer.

Como Proof of Actor lida com solicitações automatizadas verificadas

Detect

Sua integração passa o contexto da solicitação, incluindo quaisquer headers de assinatura, para o Proof of Actor. As assinaturas são verificadas contra chaves publicadas. As solicitações que validam são registradas com base Verified. Clientes que apenas se identificam são registrados como Declared. Padrões comportamentais são registrados como Inferred. Quando não há dados suficientes, o resultado é Unknown. Nada é promovido a Verified sem que uma verificação criptográfica tenha passado.

Understand

Veja quais operadores verificados chamam sua application, quais routes usam, com que frequência e como isso se compara com automação declarada e Unknown. O resumo de evidências em cada resultado informa qual chave e qual identificador estavam envolvidos, para que sua equipe possa investigar qualquer solicitação rapidamente.

Route

Use a base em suas políticas. Padrões comuns incluem:

Dar a agentes verificados uma resposta estruturada em routes somente de leitura, como uma API ou uma versão Markdown de uma página.
Aumentar limites de taxa para operadores verificados que você reconhece, mantendo limites padrão para clientes declarados.
Manter sua autorização existente em toda route de gravação, independentemente do que a assinatura diga.
Definir um fallback explícito para solicitantes sem assinatura e Unknown em cada route.

Suas políticas decidem; Proof of Actor fornece a evidência.

Por que o cabeçalho user-agent não basta

Strings de user-agent são declarações. Qualquer cliente pode enviar qualquer valor, e user-agent spoofing não exige habilidade. É por isso que operadores de rastreadores publicam suas próprias verificações: a Google documenta consultas reversas e diretas de DNS e faixas de IP publicadas para verificar o Googlebot, a Bing documenta uma checagem de DNS para verificar o Bingbot, e a OpenAI publica arquivos de faixas de IP para cada um de seus crawlers and user agents. Proof of Actor trata uma alegação de user-agent como evidência declarada, nunca como verificação. Isso significa que um cliente que afirma ser um rastreador conhecido sem uma assinatura válida é reportado com base declared ou inferred, e sua política pode tratá-lo de forma diferente de um cliente que provou sua identidade.

É isso que torna as solicitações automatizadas verificadas valiosas: elas oferecem uma forma confiável de estender confiança aos clientes que a conquistam, sem estendê-la a todos que copiam o cabeçalho.

Evidência de identidade, credenciais e autorização

Três camadas trabalham juntas em qualquer application que atenda clientes automatizados:

Evidência de identidade: qual cliente assinou esta solicitação? Uma assinatura verificada responde a isso.
Credenciais: qual account é responsável? Sua API key, token ou session responde a isso.
Autorização: esse solicitante pode fazer isso? Seu modelo de permissões responde a isso.

Proof of Actor fortalece a primeira camada e a torna visível. Ele não emite credenciais de identidade ou delegação, e não substitui sua autorização. Manter as camadas separadas é o que permite ser generoso com agentes verificados em routes de baixo risco e cuidadoso nas de alto impacto.

Onde ele se encaixa

Proof of Actor fica ao lado do seu gateway, da autenticação e do rate limiting. As integrações rodam como middleware do lado do servidor, na edge, no seu MCP server ou por meio de uma integração HTTP genérica, com acompanhamento prático junto de cada equipe fundadora. Se seu tráfego é composto principalmente por APIs e ferramentas, os casos de uso de APIs e MCP Servers mostram os padrões que mais importam.

Comece em modo de observação

Toda integração começa em modo de observação. Os resultados são registrados sem alterar como sua application responde, para que você veja quanto do seu tráfego automatizado é verificado, quais operadores estão assinando e onde a taxa de Unknown é maior. As políticas vêm depois, route por route, quando a evidência as sustenta. How It Works percorre o fluxo completo.

Detalhes práticos que tornam a verificação confiável

A verificação de assinatura é tão boa quanto os detalhes ao redor dela. Algumas práticas tornam as solicitações automatizadas verificadas confiáveis em produção.

Verifique a frescura

RFC 9421 define parâmetros de assinatura created e expires, e solicitações assinadas normalmente os carregam. Rejeite assinaturas fora de uma janela curta, para que uma solicitação capturada não possa ser reutilizada depois.

Faça cache de chaves de forma sensata

Buscar as chaves publicadas de um operador em cada solicitação adiciona latência. Faça cache delas por um período razoável e atualize quando uma assinatura falhar com um identificador de chave desconhecido, para que a rotação de chaves não cause falhas falsas.

Assine as partes certas da solicitação

Uma assinatura que cobre apenas um timestamp prova muito pouco. Verifique se os componentes assinados incluem o method, o path e o host, para que a assinatura esteja vinculada à solicitação que sua application realmente recebeu.

Registre a evidência

Mantenha o identificador da chave, o identificador publicado e o resultado junto de cada solicitação verificada. Quando algo incomum acontecer, sua equipe poderá ver exatamente qual cliente assinou o quê e quando.

Proof of Actor lida com essas verificações como parte da etapa Detect e reporta o resultado como uma base que suas políticas podem ler, para que o código da sua application permaneça simples.

Junte-se ao programa de desenvolvedores fundadores

Proof of Actor está em private beta. As equipes fundadoras selecionadas podem receber até 12 months de acesso gratuito, dentro dos limites de uso acordados, com suporte direto de integração dos nossos engenheiros.

Se clientes automatizados chegam à sua application e você quer tratar os verificados de forma diferente, solicite acesso antecipado. Conte-nos sobre sua application e os solicitantes automatizados que você vê, e mostraremos como Proof of Actor se encaixa.

Fontes

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
Verifying Googlebot and other Google crawlers, Google Search Central.
How to verify that Bingbot is Bingbot, Bing Webmaster Blog.
Overview of OpenAI crawlers, OpenAI.

PARA DESENVOLVEDORES

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent ou Unknown.
basis: Quão forte é a evidência: Verified, Declared, Inferred ou Unknown.
evidence: Os sinais por trás do resultado, para que sua equipe possa ver o motivo.

Comece no modo de observação: registre os resultados ao lado dos seus logs e não altere nada até escolher uma policy. Leia o guia de integração do Node.js

Perguntas frequentes

O que é uma solicitação automatizada verificada?

É uma solicitação de um cliente automatizado cuja assinatura criptográfica é validada contra uma chave publicada para um identificador conhecido, como o domínio do operador. Ela mostra qual cliente assinou a solicitação.

Uma assinatura verificada significa que o agente está autorizado?

Não. Uma assinatura associa uma solicitação a uma chave e ao identificador publicado dessa chave. Se esse cliente pode executar uma ação é uma decisão separada de autorização, tomada pela sua application.

E quanto a clientes automatizados que não assinam suas solicitações?

Proof of Actor ainda os classifica, usando evidências Declared e Inferred quando disponíveis, e retorna Unknown quando a evidência não é forte o suficiente. Todo resultado informa sua base.

Uma string de user-agent pode verificar um cliente?

Não. Strings de user-agent são fáceis de imitar, então contam como uma declaração, não uma verificação. As assinaturas criptográficas é que tornam uma solicitação verificável.

Como começo?

Solicite acesso antecipado. As equipes fundadoras começam em modo de observação e as equipes selecionadas podem receber até 12 meses grátis dentro dos limites de uso acordados.

Saiba quem está usando seu app.

Private beta para um pequeno grupo de founding developers.

Obter acesso antecipado Ver preços

Prefere falar primeiro? Fale com os fundadores