auth.md e o Movimento de Linhagem OAuth para Registro de Agentes

Em 25 de maio de 2026, a WorkOS publicou o auth.md, um protocolo aberto que permite a agentes se registrarem em qualquer serviço web sem que um humano precise abrir o cliente de email e copiar um código de uso único. O mecanismo é pequeno. Um serviço publica um arquivo Markdown em servico.com/auth.md, expõe dois endpoints well-known, e qualquer agente compatível pode descobrir como se registrar, obter credenciais e revogá-las.

Esta é a segunda entrega da WorkOS em três semanas. O Project Horizon, publicado em 6 de maio, foi o runtime governado e produtizado para agentes de código. O auth.md é a jogada paralela de padrões abertos. Lidas juntas, a estratégia fica legível: um stack produtizado para vencer a briga de plataforma, um protocolo aberto para vencer a briga de padrões, e nenhum dos dois dependendo do outro.

O protocolo em si é o movimento certo na camada de infraestrutura. Também é o tipo de movimento que devolve em silêncio o trabalho difícil para o comprador. Todo serviço que publicar um auth.md ainda precisa decidir em quais provedores de agente confia, quais escopos cada novo registro recebe por padrão e o que acontece quando uma credencial se revela errada. O protocolo é encanamento. A política é sua.

O Que o auth.md de Fato Especifica

A especificação publicada, conforme descrita pelo time da WorkOS e pelo artigo do MarkTechPost:

Um arquivo Markdown em texto puro no caminho well-known servico.com/auth.md. É documentação legível para humanos e configuração parseável por máquina ao mesmo tempo. Engenheiros leem, runtimes de agente fazem parsing.
Descoberta em dois saltos via metadados OAuth. O agente busca /.well-known/oauth-protected-resource (Protected Resource Metadata, conforme a RFC 9728) e em seguida /.well-known/oauth-authorization-server, que carrega um bloco agent_auth com register_uri, claim_uri, revocation_uri e identity_types_supported. Qualquer resposta 401 inclui um cabeçalho WWW-Authenticate: Bearer resource_metadata="..." para que um agente que bata numa porta fechada saiba exatamente onde está a fechadura.
Dois fluxos de registro, mapeados para dois modelos de confiança. Registros Agent Verified usam ID-JAG (Identity Assertion Authorization Grant). O provedor de identidade do agente, OpenAI, Anthropic ou Cursor por exemplo, emite uma asserção assinada. O serviço verifica o JWT contra o JWKS do provedor, valida aud, exp, iat, jti e client_id, e emite credenciais de forma síncrona. Sem OTP. Sem humano. Registros User Claimed usam OTP, em duas variantes: Anonymous Start (o agente se registra sozinho e o usuário associa o registro depois via OTP, com escopos sendo elevados no mesmo registro) e Email Required (nenhuma credencial sai até o OTP ser concluído).
Um modelo de credencial limitado para o caminho ID-JAG. Access tokens emitidos a partir de uma asserção ID-JAG verificada não podem incluir refresh tokens. O agente apresenta uma nova asserção para estender o acesso. O raio de impacto de um token roubado encolhe para o tempo de vida da asserção.
Um formato de auditoria recomendado. registration.created, claim.requested, otp.generated, claim.confirmed, registration.expired, registration.revoked. Fluxos ID-JAG incluem iss, sub e agent_platform para que serviço e provedor de agente possam correlacionar logs depois de um incidente.

Nenhuma dessas primitivas é nova. O auth.md compõe RFC 9728 com ID-JAG e escreve o caso de uso de registro de agente como uma camada fina por cima. Esse é o ponto. O protocolo não está amarrado à infraestrutura da WorkOS. A especificação do auth.md vive no GitHub. Qualquer serviço pode implementar, e qualquer runtime de agente pode falar o protocolo.

Dois Fluxos, Dois Modelos de Confiança

A escolha de design mais consequente do auth.md não é o formato do arquivo. É a separação entre registros Agent Verified e User Claimed, porque esses dois caminhos codificam respostas diferentes para a mesma pergunta: quem está afirmando que esse agente deve ter acesso.

Fluxos Agent Verified confiam no provedor do agente. Quando a Anthropic assina uma asserção ID-JAG e o serviço verifica o JWT, o serviço está dizendo, na prática, que o provedor de identidade da Anthropic é uma testemunha suficiente. O usuário não aparece no loop. A credencial é emitida de forma síncrona porque o serviço decidiu de antemão que esse emissor é confiável para esse escopo. Isso é rápido e limpo. Também concentra risco: todo serviço que aceita ID-JAG de um dado provedor passa a ficar exposto à higiene de identidade daquele provedor.

Fluxos User Claimed confiam no usuário. O agente se registra de forma anônima ou com email, e o usuário precisa concluir uma cerimônia de OTP antes que qualquer escopo significativo se abra. Mais lento. Mais atrito. Menor raio de impacto. O usuário está no loop por design, e a ligação entre agente e conta acontece por um canal que o usuário controla.

Um time de produto adotando o auth.md precisa decidir quais provedores aceita no caminho Agent Verified, quais força pelo caminho User Claimed e como os escopos diferem entre os dois. Essas decisões não estão na especificação. Não poderiam estar. São política, e a política pertence ao serviço.

O Que o Protocolo Não Resolve

O auth.md acerta o handshake de registro. Não diz nada sobre as decisões de política que determinam se o handshake deveria ter acontecido.

Em quais provedores de agente você confia por padrão. A verificação ID-JAG é uma checagem criptográfica. Ela diz que a asserção é genuína. Não diz que é seguro honrá-la. Um provedor de agente novo pode ser tecnicamente compatível e operacionalmente perigoso no primeiro dia. O serviço precisa manter uma lista de confiança, uma matriz de escopo por provedor e um processo para promover provedores de Anonymous Start para Email Required e depois para Agent Verified. Nada disso vem no auth.md.

Quais escopos novos registros recebem. A especificação descreve como emitir credenciais. Não descreve o que essas credenciais deveriam deixar um agente fazer no primeiro contato. Um serviço que concede escopos de leitura e escrita para qualquer asserção verificada construiu um caminho rápido para um incidente grande. Um serviço que concede só leitura e força elevações de escopo com consentimento explícito construiu um caminho mais lento com raio de impacto menor. Os dois são implementações válidas do auth.md. Só um sobrevive a uma auditoria.

O que acontece quando algo dá errado. A revogação está no protocolo. A detecção de anomalias não. Se as chaves de um provedor de agente vazam, todo serviço que confia nele precisa saber em minutos, não em horas. Os eventos de auditoria recomendados dão a matéria-prima. Não dão a lógica de detecção, o roteamento de alerta ou o playbook de resposta.

Tratamos esse mesmo padrão no post sobre o protocolo de pagamentos máquina: uma especificação limpa na camada de infraestrutura, sem resposta de governança na camada de política. A mesma forma aparece aqui, e a mesma resposta de engenharia se aplica. O protocolo é necessário. Não é suficiente. O registro governado que decide quais agentes admitir, com quais escopos, sob quais condições, é uma decisão de produto e uma disciplina operacional. O imposto de integração que descrevemos no post sobre o imposto de integração de agentes não desaparece porque o handshake de descoberta ficou mais barato. Ele sobe na pilha.

A Estratégia de Duas Trilhas da WorkOS

Olhe as duas entregas de maio juntas e a aposta da WorkOS fica visível. O Project Horizon é o runtime produtizado: uma integração fechada de sandboxes, orquestração dirigida a eventos, contexto baseado em MCP e aprovação humana em todo merge. O auth.md é o protocolo aberto: uma especificação que qualquer um pode implementar, com a infraestrutura WorkOS sendo uma opção entre várias.

Stacks produtizados vencem quando o comprador quer um único fornecedor para chamar quando algo quebrar. Padrões abertos vencem quando o comprador quer evitar exatamente essa dependência. A WorkOS está entregando os dois. O cliente do Horizon ganha um runtime gerenciado. Quem adota o auth.md ganha uma especificação aberta que pode implementar contra qualquer backend, incluindo o da WorkOS. Nenhuma jogada mina a outra, porque elas atacam decisões diferentes no mesmo comprador.

Padrões vencem plataformas em escala, quando o padrão é bom o suficiente para compor. RFC 9728 mais ID-JAG mais uma especificação Markdown fina é bom o suficiente para compor. A pergunta dos próximos 12 meses é quais outros fornecedores vão publicar endpoints auth.md, quais provedores de agente vão emitir asserções ID-JAG e quão rápido a camada de política vai amadurecer ao redor do protocolo. Até essa camada amadurecer, todo serviço que publica um arquivo auth.md está escrevendo suas próprias respostas para as perguntas de confiança que a especificação deixa em aberto.

Faça Isso Agora

Se o seu serviço vai ser consumido por agentes em 2026, leia a especificação do auth.md ainda esta semana. Depois escreva três documentos antes de implementar qualquer coisa.

O primeiro documento é uma lista de confiança. De quais provedores de agente você está disposto a aceitar asserções ID-JAG no primeiro dia? Quais exigem User Claimed pelos primeiros 90 dias? Quais ficam excluídos por completo? Escreva os nomes e escreva os critérios para mover um provedor entre os níveis.

O segundo documento é uma matriz de escopo. Para cada nível de confiança, quais escopos um novo registro recebe? Quais escopos exigem um passo explícito de consentimento do usuário? Quais escopos nunca são concedidos via Anonymous Start? Mapeie as respostas para a sua superfície de API real, não para um vocabulário genérico de escopos OAuth.

O terceiro documento é um playbook de anomalias. Se os eventos registration.created disparam para um único agent_platform numa janela de 10 minutos, o que acontece? Quem aciona quem? Qual é o limite de auto-throttle? Qual é o kill switch? O auth.md entrega os eventos. O playbook é seu para escrever.

Implemente o auth.md quando esses três documentos existirem, não antes. O protocolo são algumas centenas de linhas de código. As políticas das quais ele depende são o produto de verdade.

Fontes

MarkTechPost. “WorkOS Releases auth.md: An Open Agent Registration Protocol Built on OAuth Standards.” Maio de 2026.
WorkOS. “auth.md: detalhes técnicos.” Maio de 2026.
WorkOS (GitHub). “Especificação auth.md.” Maio de 2026.
IETF. “RFC 9728: OAuth 2.0 Protected Resource Metadata.” Abril de 2025.

A Victorino ajuda empresas a desenhar as políticas de confiança e escopo que ficam sobre os protocolos abertos de agentes: contato@victorino.com.br | www.victorino.com.br