A WorkOS soltou auth.md essa semana — uma spec aberta mais um artifact arquivo concreto pro problema que quase todo shop de agente tava montando na mão: como um agente prova que tá agindo em nome do usuário X, com credenciais user-scoped, revogáveis, e que não sejam uma chave API crua sentada em variáveis de ambiente. A forma: um pequeno arquivo Markdown que uma aplicação publica na raiz do seu serviço (funciona como documentação pra desenvolvedores humanos E como artifact em runtime que agentes podem ler programaticamente), mais extensões de metadata OAuth 2.0. Pra quem deploya agentes em produção que precisam chamar APIs de terceiros em nome de um usuário, essa é a spec que aborda o problema certo.
O discovery é uma cadeia de metadata dois-hops. Um agente bate em `/.well-known/oauth-protected-resource` (Protected Resource Metadata) pra achar o authorization server, depois faz fetch em `/.well-known/oauth-authorization-server` que contém um novo bloco `agent_auth` com quatro URIs: `register_uri`, `claim_uri`, `revocation_uri`, e `identity_types_supported`. O novo grant type é ID-JAG (Identity-scoped JSON Authorization Grant) per RFC 9728 — agent identity providers atestam identidade de usuário via JWTs assinados, o authorization server valida a afirmação, retorna credenciais scoped. Uma resposta 401 num endpoint protegido inclui `WWW-Authenticate: Bearer resource_metadata="..."` pra fazer bootstrap o agente na cadeia de discovery sem configuração prévia. OpenAI, Anthropic e Cursor são citados como identity providers potenciais; a spec não requer nenhum vendor único.
A distinção do RFC 7591 Dynamic Client Registration importa e a spec é explícita sobre isso. RFC 7591 deixa um cliente se registrar com um authorization server — útil, mas o cliente se autentica *como si mesmo*. auth.md resolve um problema diferente: o agente se autentica *como o usuário*, em nome do usuário, com o authorization server entendendo essa distinção e emitindo credenciais user-scoped revogáveis. Esse é o primitivo certo pro mundo agent-loop: um agente que chama `send_email` deveria agir com as permissões de email do usuário, não com permissões globais "eu sou o serviço agente", e o usuário deveria poder revogar o acesso desse agente específico sem rotacionar suas próprias credenciais. Hoje a maioria dos produtos agent ou pede pro usuário colar chaves API cruas (inseguro, não-revogável por-agente) ou roda tudo através do auth próprio do vendor do agente (lock-in). auth.md é o middle padronizado.
Segunda de manhã: se você shippa um agente que precisa chamar APIs de terceiros em nome de usuários, leia a spec em github.com/workos/auth.md e cheque se teu provedor de auth (Auth0, Okta, custom) tem roadmap pra suporte ID-JAG. O gap honesto é status de implementação — early access só, sem servidores produção widespread, e o artigo nota que MCP servers ou chamadas API LLM cruas tipicamente não podem participar do fluxo agent-verified nessa etapa. Compatibilidade com libraries OAuth existentes não é explicitamente abordada no release; espera rough edges. Mas a decisão arquitetural é sã: esse é o user-side do mesmo problema que a ponte IAM-OAuth do servidor AWS MCP resolve no lado do recurso, e a stack agent-infra precisa dos dois. WorkOS tá cedo na spec; a pergunta é se OpenAI, Anthropic e os cloud providers shipam interop em meses ou trimestres.