EXPLICADOR

Web Bot Auth para equipes de produto: o que requests assinadas por agentes significam para seu roadmap

Agentes de IA e crawlers cada vez mais precisam de uma forma de provar quem são sem depender de uma string de User-Agent que qualquer pessoa pode copiar. O trabalho do IETF em Web Bot Auth é o esforço líder para padronizar isso. Aqui vai uma explicação direta para product managers e líderes de engenharia: como funciona, o que comprova, seu status em novembro de 2026 e como se preparar.

Obter acesso antecipado Explorar como funciona

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

Durante anos, a única forma de um cliente automatizado dizer a um site quem era consistia em um nome no header User-Agent e, para alguns operadores grandes, uma lista publicada de endereços IP ou uma checagem de reverse DNS. Nomes são fáceis de copiar. Listas de rede cobrem apenas os operadores que as mantêm. À medida que agentes de IA passam a agir por pessoas reais na web, essa lacuna virou um problema de produto, não apenas de segurança.

Web Bot Auth é o esforço líder para fechar essa lacuna. Ele oferece aos clientes automatizados uma forma de assinar suas requests com uma chave que controlam e publicam, para que um site possa verificar a assinatura em vez de confiar em um nome. Este explicador é para product managers e líderes de engenharia que precisam entender o que é, o que muda e o que não muda, sem ler as especificações de ponta a ponta.

A versão curta

O que é: um working group do IETF, webbotauth, e a abordagem que ele está padronizando para autenticar clientes HTTP automatizados.
Como funciona: o cliente assina partes de cada request usando HTTP Message Signatures (RFC 9421) e aponta para um diretório de suas chaves públicas. O site busca a chave e verifica a assinatura.
O que comprova: qual chave assinou a request e que as partes assinadas não foram alteradas em trânsito.
O que não comprova: que o agente está autorizado a fazer o que está pedindo, que ele age em nome de um usuário específico ou que vai se comportar bem.
Status em novembro de 2026: RFC 9421 é um Proposed Standard publicado. O documento de protocolo Web Bot Auth é um Internet-Draft de working group, ainda não um RFC.
O que fazer: planeje tratar assinaturas válidas como evidência forte, continue lidando com tráfego não assinado e mantenha as decisões de autorização no seu próprio código.

O que é o trabalho do IETF em Web Bot Auth

O IETF criou o working group Web Bot Auth para padronizar métodos de autenticação criptográfica de clientes automatizados e para fornecer aos sites mais informação sobre os operadores por trás deles. A charter concentra-se em sites que atendem principalmente pessoas e inclui um conjunto amplo de clientes no escopo: crawlers, web archivers, link checkers, crawlers de treinamento de IA e agentes de IA atuando para usuários finais.

Há duas exclusões na charter que valem atenção para equipes de produto. A autenticação de usuário final está fora do escopo, então isso não é uma forma de fazer login de uma pessoa. Rastrear reputação de bot também está fora do escopo, então o standard informa quem assinou uma request, não se esse operador é confiável.

A charter lista três tipos de entregáveis:

Documentos no standards track sobre técnicas para autenticar clientes automatizados em sites construídos para pessoas.
Documentos no standards track sobre como transmitir mais informações sobre um bot solicitante usando um identificador existente, como um domínio ou URL.
Documentos de best current practice ou informativos sobre tópicos operacionais como gerenciamento de chaves, ciclo de vida e deployment.

Em que ponto estão os documentos, em novembro de 2026

Em novembro de 2026, o working group tem um documento adotado: draft-ietf-webbotauth-httpsig-protocol, intitulado "HTTP Message Signatures for automated traffic", na revisão 01, datado de 29 de outubro de 2026. Ele é um Internet-Draft, o que significa que é um trabalho em andamento que ainda pode mudar. Não é um RFC.

Vários drafts individuais também estão associados ao grupo e em discussão, incluindo propostas sobre um registry e formato de agent card, autenticação anônima de bots, um formato JSON para publicar as faixas de IP de clientes automatizados e um header para metadados de agente assinados. Drafts individuais são propostas; nenhum deles foi adotado pelo grupo até esta data.

A charter definiu marcos ao longo de 2026 para enviar especificações ao IESG para aprovação. Em novembro de 2026, o documento de protocolo continua sendo um draft de working group. Você pode acompanhar o estado atual na página do datatracker do IETF para o working group e no draft de protocolo.

Como HTTP Message Signatures funciona

Web Bot Auth se baseia em RFC 9421, HTTP Message Signatures, publicado em fevereiro de 2024 como Proposed Standard. RFC 9421 é um mecanismo geral: ele define como assinar partes selecionadas de uma HTTP message e como transportar a assinatura em headers. Web Bot Auth o adapta para clientes automatizados.

Em termos simples, uma request assinada por um agente funciona assim:

O operador cria um par de chaves. Ele mantém a chave privada em segredo e publica a chave pública.
O cliente escolhe o que assinar. Ele seleciona componentes da request, como o host ou URI de destino e um tempo de criação. O draft atual exige cobrir a authority ou o target URI, então uma assinatura para um site não pode ser simplesmente reaproveitada em outro.
O cliente assina e envia. A request carrega um header Signature-Input descrevendo o que foi assinado e com qual chave, e um header Signature com o valor da assinatura. O draft usa uma tag web-bot-auth e espera tempos de criação e expiração em cada assinatura.
O site verifica. Ele encontra a chave pública, reconstrói os componentes assinados a partir da request recebida e checa a assinatura. Se a verificação passar, a request foi assinada pelo detentor daquela chave e as partes cobertas não foram alteradas.

O draft também permite que um site peça uma assinatura. Uma origin pode enviar um header Accept-Signature, normalmente com uma recusa, para sinalizar que deseja requests assinadas.

A ideia de diretório de chaves

Uma assinatura só é útil se o site conseguir encontrar a chave pública correta. Web Bot Auth responde a isso com um diretório de chaves.

No draft atual do working group, o cliente adiciona um header Signature-Agent contendo uma URL HTTPS. Essa URL serve um diretório das chaves públicas do operador como um JSON Web Key Set. O site busca o diretório, seleciona a chave que corresponde ao identificador de chave na assinatura e verifica. O draft também define um caminho conhecido, /.well-known/http-message-signatures-directory, onde um operador pode servir seu diretório.

A ideia útil para equipes de produto é que a URL se torna a identidade. Um operador de agente é identificado pelo local onde publica suas chaves, o que vincula a assinatura a um domínio que o operador controla. A rotação de chaves funciona publicando uma nova chave junto com a antiga e depois removendo a antiga.

Os sites verificadores precisam lidar com diretórios com cuidado: armazená-los em cache seguindo as regras normais de HTTP, definir limites de tamanho e timeouts e evitar buscar em endereços de rede privada. Essas são preocupações de engenharia padrão e fazem parte do motivo pelo qual muitas equipes preferem um componente que faça a verificação por elas.

O que uma assinatura válida comprova e o que ela não comprova

Esta é a seção mais importante para qualquer pessoa que esteja escrevendo policy de produto.

Uma assinatura válida comprova:

Que a request foi assinada pelo detentor de uma chave privada específica.
Que essa chave está publicada em uma URL de diretório controlada pelo operador.
Que as partes assinadas da request não foram alteradas em trânsito e que a assinatura está dentro de sua janela de validade.

Uma assinatura válida não comprova:

Que o agente está autorizado a executar a ação. Ser identificável não é permissão. Veja autorização de agente.
Que o agente atua para uma pessoa específica, ou dentro da autoridade que essa pessoa lhe concedeu. Veja autoridade delegada.
Que o operador é confiável ou que o agente vai se comportar bem. Reputação está explicitamente fora do escopo do working group.
Nada sobre requests que não estejam assinadas. Tráfego não assinado ainda precisa de tratamento próprio.

Trate uma assinatura válida como evidência forte de quem enviou uma request e então deixe o controle de acesso da sua própria aplicação decidir o que esse remetente pode fazer.

O que as equipes de produto devem fazer com isso

Você não precisa esperar um RFC para se planejar. Tráfego de agentes assinado é algo para o qual você pode se preparar agora, com a expectativa de que alguns detalhes do draft ainda mudem.

1. Meça antes de decidir

Descubra quanto do seu tráfego é automatizado, quais routes os agentes usam e quanto dele é assinado. Comece no modo de observação para que a medição não altere nada para seus usuários.

2. Separe evidência de policy

Registre o que a evidência diz, verified, declared, inferred ou unknown, separadamente do que você decide fazer. Isso mantém as policies legíveis e permite endurecê-las ou flexibilizá-las sem reinstrumentar. A entrada basis da evidência explica os quatro níveis.

3. Dê aos agentes verified um caminho melhor

Quando fizer sentido, sirva conteúdo estruturado ou um fluxo amigável para agentes em vez de páginas feitas para pessoas. O guia sobre servir conteúdo estruturado para agentes de IA cobre os padrões.

4. Mantenha a autorização no seu código

Use a assinatura para saber quem está pedindo. Use suas permissões, scopes e confirmações existentes para decidir o que essa entidade pode fazer. Ações de alto impacto ainda podem exigir confirmação humana, quem quer que tenha assinado a request. Veja proteger ações sensíveis sem bloquear agentes.

5. Planeje para tráfego não assinado e Unknown

O suporte a assinatura varia entre agentes e ferramentas, então espere uma mistura de requests assinadas e não assinadas por algum tempo. Decida por route o que acontece com tráfego declared, inferred e Unknown, em vez de escolher uma única regra para todo o site. O guia sobre lidar com tráfego Unknown mostra o passo a passo.

Como o Proof of Actor usa Web Bot Auth

Proof of Actor diz à sua aplicação quem ou o que está agindo em cada interação, Human, Human + AI, Agent ou Unknown, e informa a base da evidência. Assinaturas Web Bot Auth são uma de suas fontes mais fortes de evidência.

Quando um agente assina sua request com HTTP Message Signatures, o Proof of Actor verifica a assinatura em relação à chave publicada pelo operador. Se a verificação passar, o resultado recebe uma base verified, junto com a evidência que sua equipe pode revisar. Se um cliente apenas se nomeia em um header, o resultado é declared. Se a conclusão depende de sinais comportamentais ou contextuais, ela é rotulada como inferred. Se a evidência não for suficiente, o resultado é Unknown.

Sua aplicação decide o que fazer com esse contexto. As policies são escritas por route, por classe de actor e por base, com resultados como allow, adapt, challenge, review e rate-limit. Nada é aplicado por padrão: você faz um preview da policy sobre tráfego real e a enforce route por route, no seu próprio código.

As equipes fundadoras podem coletar evidências por meio de middleware Node.js, Next.js, uma integração edge, um collector de navegador em páginas aprovadas, a HTTP API genérica ou uma integração de MCP server. Veja integrações e o guia sobre verificar requests assinadas de agentes para os passos práticos.

O Proof of Actor segue o mesmo limite que o standard segue: uma assinatura verified informa qual chave assinou a request, não se o agente está autorizado. A autorização continua com você. A página evidência e limites descreve exatamente o que cada resultado pode e não pode suportar.

Comece agora

Proof of Actor está em private beta. Equipes fundadoras selecionadas podem receber até 12 months de acesso gratuito dentro de limites de uso acordados, sem cobrança automática. Candidate-se ao acesso antecipado e nos diga quais routes você espera que agentes assinados usem e o que deseja fazer com eles.

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 é Web Bot Auth?

Web Bot Auth é o nome de um working group do IETF, webbotauth, e da abordagem que ele está padronizando: clientes automatizados assinam requests HTTP com HTTP Message Signatures (RFC 9421) e publicam suas chaves públicas, para que sites possam verificar qual operador enviou uma request.

Web Bot Auth já é um standard concluído?

Ainda não. Em novembro de 2026, o principal documento de protocolo, draft-ietf-webbotauth-httpsig-protocol, é um Internet-Draft de working group na revisão 01. RFC 9421, o formato de assinatura sobre o qual ele se apoia, é um Proposed Standard publicado.

Uma assinatura válida de Web Bot Auth significa que o agente está autorizado a agir?

Não. Ela comprova qual chave assinou a request e que as partes assinadas não foram alteradas. Se esse agente pode ler dados, enviar um formulário ou agir em nome de um usuário específico continua sendo uma decisão de autorização que sua aplicação ainda toma.

As equipes de produto precisam implementar Web Bot Auth por conta própria?

Os sites verificam assinaturas; não precisam assinar nada, a menos que também executem clientes automatizados. A verificação envolve buscar diretórios de chaves, armazená-los em cache com segurança e checar as assinaturas, algo que uma ferramenta como Proof of Actor pode fazer por você.

O que devemos fazer com agentes que não assinam suas requests?

Trate-os de acordo com a evidência disponível: declared, inferred ou Unknown. Espere uma mistura de tráfego assinado e não assinado por algum tempo e defina um fallback por route em vez de uma única regra para todo o site.

Como o Proof of Actor usa Web Bot Auth?

Ele verifica HTTP Message Signatures em relação à chave publicada e, quando a checagem passa, reporta o resultado com uma base verified. Suas políticas podem então tratar agentes verified de forma diferente do tráfego declared ou Unknown.

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