WorkOS soltó auth.md esta semana — una spec abierta más un artifact archivo concreto para el problema que casi cada shop de agentes estaba armando a mano: cómo un agente prueba que está actuando en nombre del usuario X, con credenciales user-scoped, revocables, y que no sean una clave API cruda sentada en variables de entorno. La forma: un pequeño archivo Markdown que una aplicación publica en la raíz de su servicio (funciona como documentación para desarrolladores humanos Y como artifact en runtime que los agentes pueden leer programáticamente), más extensiones de metadata OAuth 2.0. Para quien deploya agentes en producción que necesitan llamar APIs de terceros en nombre de un usuario, esta es la spec que aborda el problema correcto.
El discovery es una cadena de metadata dos-hops. Un agente pega en `/.well-known/oauth-protected-resource` (Protected Resource Metadata) para encontrar el authorization server, luego hace fetch a `/.well-known/oauth-authorization-server` que contiene un nuevo bloque `agent_auth` con cuatro URIs: `register_uri`, `claim_uri`, `revocation_uri`, y `identity_types_supported`. El nuevo grant type es ID-JAG (Identity-scoped JSON Authorization Grant) per RFC 9728 — los agent identity providers atestiguan identidad de usuario vía JWTs firmados, el authorization server valida la afirmación, retorna credenciales scoped. Una respuesta 401 en un endpoint protegido incluye `WWW-Authenticate: Bearer resource_metadata="..."` para hacer bootstrap al agente en la cadena de discovery sin configuración previa. OpenAI, Anthropic y Cursor son citados como identity providers potenciales; la spec no requiere ningún vendor único.
La distinción del RFC 7591 Dynamic Client Registration importa y la spec es explícita al respecto. RFC 7591 deja a un cliente registrarse con un authorization server — útil, pero el cliente se autentica *como sí mismo*. auth.md resuelve un problema diferente: el agente se autentica *como el usuario*, en nombre del usuario, con el authorization server entendiendo esa distinción y emitiendo credenciales user-scoped revocables. Ese es el primitivo correcto para el mundo agent-loop: un agente que llama `send_email` debería actuar con los permisos de email del usuario, no con permisos globales "yo soy el servicio agente", y el usuario debería poder revocar el acceso de ese agente específico sin rotar sus propias credenciales. Hoy la mayoría de productos agent o piden al usuario pegar claves API crudas (inseguro, no-revocable por-agente) o corren todo a través del auth propio del vendor del agente (lock-in). auth.md es el middle estandarizado.
Lunes por la mañana: si shippas un agente que necesita llamar APIs de terceros en nombre de usuarios, lee la spec en github.com/workos/auth.md y chequea si tu proveedor de auth (Auth0, Okta, custom) tiene roadmap hacia soporte ID-JAG. El gap honesto es estado de implementación — early access solamente, sin servidores producción widespread, y el artículo nota que MCP servers o llamadas API LLM crudas típicamente no pueden participar en el flujo agent-verified en esta etapa. Compatibilidad con librerías OAuth existentes no es explícitamente abordada en el release; espera rough edges. Pero la decisión arquitectónica es sana: este es el user-side del mismo problema que el bridge IAM-OAuth del servidor AWS MCP resuelve en el lado del recurso, y la stack agent-infra necesita ambos. WorkOS es temprano en la spec; la pregunta es si OpenAI, Anthropic y los cloud providers shippean interop en meses o trimestres.