97 nombres de campo, cero acuerdo: los drafts de delegacion de agentes

OAuth sabe decir quien es el cliente. No sabe decir que ese cliente es un agente actuando por un humano, ni que el agente le paso el trabajo a otro agente. Dieciocho Internet-Drafts activos intentan arreglarlo. Medimos cuanto se parecen entre si.

La respuesta es: casi nada. El 2026-09-02 bajamos todos los drafts activos de OAuth del datatracker del IETF, tomamos los dieciocho cuyo titulo menciona agentes o AI, y diffeamos su vocabulario de wire contra OAuth 2.1 y los RFCs sobre los que todos se apoyan. En 423 paginas de texto normativo encontramos 97 nombres de campo nuevos. Noventa y seis aparecen en un solo draft.

Eso no es un proceso de estandarizacion convergiendo. Son dieciocho respuestas paralelas a la misma pregunta, publicadas mas rapido de lo que nadie puede leerlas.

Metodo

Todo lo que sigue sale de la API REST del datatracker y del texto crudo de los drafts en ietf.org, bajado el 2026-09-02. Sin fuentes secundarias.

Consultamos la API de documentos por drafts activos, filtramos por nombre y por titulo, bajamos cada draft en su revision actual y tokenizamos el texto buscando identificadores snake_case. El vocabulario base — lo que ya existe en OAuth — es la union de los identificadores presentes en draft-ietf-oauth-v2-1-15, RFC 8693 (Token Exchange), RFC 9068 (JWT access tokens) y RFC 9396 (Rich Authorization Requests). Todo lo que queda fuera de esa union, usado tres o mas veces en un draft, cuenta como vocabulario nuevo propuesto.

El conteo es mecanico y reproducible. La interpretacion es nuestra.

El censo

Hay 280 Internet-Drafts en el datatracker cuyo nombre contiene la cadena agent. 166 estan activos ahora mismo. Los 166 tienen su ultima revision fechada en 2026. Los 166 pertenecen al grupo con id 1027, que es el cajon del datatracker para Individual Submissions — ni uno solo es documento de working group.

Achicamos a OAuth. Hay 95 drafts activos con oauth en el nombre. Quince pertenecen al working group Web Authorization Protocol. De las 80 individual submissions restantes, 34 mencionan agentes, AI o autonomia en su titulo o abstract, y 18 lo ponen en el titulo.

Ninguno de los 18 es documento de working group. Los quince que si lo son parecen de otra decada: el propio OAuth 2.1, draft-ietf-oauth-client-id-metadata-document, identity chaining, transaction tokens, first-party apps, attestation-based client auth, SPIFFE client auth, SD-JWT VC, status lists. Utiles, adyacentes, y en varios casos el sustrato real que los drafts de agentes asumen. Pero el working group no adopto nada que nombre a un agente.

Las afiliaciones son un mapa de quien esta preocupado. Huawei tiene tres drafts distintos. China Mobile tiene dos, uno co-firmado con CNNIC y Huawei. Amazon tiene uno. El resto son vendors chicos e independientes: Tenuo, Attest, TwoGenIdentity, Zentity, Jarwin, AgentAdmit, y tres drafts de autores que se listan como Independent.

Cuatro nombres para un entero

La forma mas clara de ver la fragmentacion es tomar una sola decision de diseño que todos estos sistemas tienen que resolver, y contar los nombres.

Tomemos la profundidad de delegacion: el maximo de saltos que una cadena de autoridad puede recorrer antes de que un verificador la rechace. Todo diseño serio de delegacion la necesita, porque sin ella un sub-agente comprometido puede extender la cadena para siempre. Cuatro de los drafts la especifican. La especifican de cuatro maneras distintas.

// draft-niyikiza-oauth-attenuating-agent-tokens-01
{ "del_depth": 0, "del_max_depth": 3, "par_hash": "..." }

// draft-yakung-oauth-agent-attestation-00 (ACAP)
{ "att_depth": 0, "att_chain": ["jti"], "att_pid": null }

// draft-valverde-oauth-pact-00, dentro de delegation_chains
{ "depth": 1, "max_depth": 3, "chain": [...], "parent_jti": "..." }

// draft-araut-oauth-transaction-tokens-for-agents-02, dentro de chain_metadata
{ "hop_count": 2, "current_actor": "...", "min_assurance_level": "..." }

El mismo entero. La misma invariante — un verificador compara la profundidad actual contra un tope y rechaza. Cuatro nombres, cuatro formas de contenedor, cuatro juegos de reglas de procesamiento. Un resource server que quiera aplicar limites de profundidad tiene que implementar los cuatro o elegir un ganador antes de que exista uno.

El patron se sostiene en todo el corpus. De los 97 identificadores nuevos que extrajimos, exactamente uno lo usa mas de un draft: agent_id, que aparece ocho veces en el draft de attestation ACAP y nueve en el draft de revocacion de China Mobile — y ni siquiera ahi significa del todo lo mismo.

Cinco mecanismos para un problema

La colision de nombres es consecuencia de una mas profunda. Los drafts ni siquiera coinciden en que capa del stack vive la cadena de delegacion.

Cada uno es defendible. Juntos son inimplementables. Un gateway que se sienta entre agentes y modelos no puede soportar a la vez una cadena en header, un claim act anidado, un capability token atenuado offline y un flujo de consentimiento por CIBA, y llamar interoperable al resultado.

Como se ven las implementaciones

Tres de los drafts incluyen seccion de implementation status. Las verificamos.

El draft de Agent-Delegation es honesto sobre su propio estado: una prueba de concepto de un solo autor, en Node.js sin dependencias, en hamr0/justabit, que el texto describe como no revisada externamente y no adoptada por ninguna organizacion. El repo se creo el 2026-08-14 y tiene cero estrellas.

El draft de attestation ACAP cita un servidor en Go en chudah1/attest-dev mas SDKs de TypeScript y Python. El repo existe, tiene una estrella y su ultimo push es del 2026-05-06. El paquete npm @attest-dev/sdk es real, en version 0.1.0-beta.6, publicada el 2026-04-14. El paquete de PyPI attest-sdk esta en 0.1.0b5 con cinco releases.

El profile de agent grants aclara que un producto llamado Grantex ofrece "an implementation-specific JSON API inspired by this profile" al 2026-08-30 — que es una forma cuidadosa de decir que el profile no esta implementado tal como esta escrito.

Y el draft que arranco toda la linea, la extension on-behalf-of de WSO2, expiro el 2026-02-27 y nunca fue adoptado. Sus ideas sobrevivieron; su documento no.

Mientras tanto, en produccion

Aca esta el numero que reencuadra todo lo demas. La especificacion de authorization 2026-07-28 de MCP — cuatro archivos, 53.622 bytes, la capa de auth sobre la que corren los deployments de agentes hoy — contiene cero ocurrencias de las palabras delegation, on-behalf y actor, y cero referencias a token exchange o RFC 8693.

Contiene diecisiete referencias a client-id-metadata-document.

Ese es el estado del juego en dos numeros. El stack que esta en produccion resolvio que cliente es este apuntando el client ID a una URL, algo que medimos la semana pasada en 3.450 authorization servers. Todavia ni empezo con por cuenta de quien, a traves de cuantas manos. Y la correlacion corre tambien al reves: solo dos de los dieciocho drafts de agentes mencionan CIMD, mientras nueve referencian DPoP y diez referencian token exchange. Los que escriben drafts de delegacion de agentes y los que despliegan authorization de agentes estan leyendo documentos distintos.

El gap que toca el dinero

El unico documento del conjunto con una pretension plausible de consenso no es un mecanismo. draft-chen-oauth-agent-authz-use-cases-03, revisado el 2026-08-25 por autores de China Mobile, CNNIC y Huawei, es un analisis de casos de uso y gaps con once escenarios. Nombra seis gaps mayores. Dos importan directamente a cualquiera que mueva valor.

El gap tres es la incapacidad de representar cadenas de delegacion: los tokens estandar no pueden expresar de forma segura Usuario a Agente A a Agente B, lo que el draft llama un bloqueante critico para procesos de negocio multi-agente. Su ejemplo trabajado es una cadena de pago — un agente de viajes que delega a un buscador de vuelos que delega a un procesador de pagos que pega contra la API de un banco.

El gap seis es mas filoso. El draft distingue la autoridad de capa de grant, que es en lo que OAuth es bueno, de la evidencia de capa de ejecucion: una prueba criptografica no repudiable de que el usuario sanciono esta accion especifica en el momento en que ocurrio. En el escenario del reclamo de seguro el requisito esta enunciado con precision — la evidencia debe atar los detalles concretos del pago, monto y destinatario, a la cadena de delegacion verificable completa. Los tokens de capa de grant, dice el draft, prueban potencial, no la legitimidad de una transaccion ejecutada.

Leelo desde el lado de los pagos y aparece algo raro. La evidencia de capa de ejecucion es la unica parte de este problema que ya esta resuelta y desplegada. Una autorizacion EIP-3009 es exactamente una declaracion firmada que ata emisor, destinatario, monto y ventana de validez a un nonce, y x402 la transporta sobre HTTP como payload de pago. La capa de settlement tiene evidencia no repudiable por accion desde antes del boom de agentes. Lo que no tiene es la otra mitad, la de identidad: la firma prueba que una llave autorizo una transferencia, no que un humano autorizo al agente que tiene la llave.

Las dos mitades se estan construyendo en edificios distintos, por gente distinta, a velocidades muy distintas. Onchain, las primitivas de delegacion se despliegan y se usan — las delegaciones de ERC-7710 y los spend permissions son contratos desplegados con transacciones reales. Offchain, la pregunta equivalente tiene 97 nombres de campo candidatos y ningun working group.

Hacia donde va el IETF de verdad

Hay movimiento institucional, solo que no donde estan los drafts. Existen tres esfuerzos relacionados con agentes como grupos y no como documentos: catalist, un BOF de coordinacion creado el 2026-06-11 y ya concluido; agentproto, un BOF de Agent Communication Protocols creado el 2026-07-24; y DAWN — Discovery of Agents With Names — un working group propuesto creado el 2026-08-24, cuyo charter llego a la revision 00-03 el 2026-08-28.

DAWN es el mas cerca de ser chartered, y su alcance es discovery: como un cliente encuentra un agente, aprende su tipo, su reachability y sus opciones de protocolo, probablemente sobre DNS y mDNS. Lee la lista de out of scope y aparece la forma de los proximos dos años. Excluidos explicitamente de la fase inicial: identificadores estables de agentes, tools y skills; registro de agentes en servidores de discovery; y trust management y metodos de evaluacion de trust mas alla de definir protocolos de intercambio.

Osea que el primer working group de agentes que el IETF charter-ee va a estandarizar como encontrar un agente, y va a declinar explicitamente estandarizar como nombrarlo de forma durable o como confiar en el. La pregunta de la cadena de delegacion todavia no tiene casa.

Que significa para LLM4Agents

La conclusion practica es negativa, y conviene decirla sin vueltas: ninguno de estos dieciocho drafts deberia implementarse hoy en un gateway. Noventa y seis de 97 nombres de campo propuestos tienen exactamente un autor detras. Adoptar cualquiera compra interoperabilidad con nadie y un costo de migracion despues.

Lo que si cambia para nosotros es el threat model. Somos un gateway compatible con OpenAI donde los agentes pagan por uso en stablecoins. Hoy un request llega con una key o con un payload de pago x402, y ambos responden quien paga. Ninguno responde quien autorizo este gasto, a traves de cuantos intermediarios. Cuando un sub-agente a tres saltos de un humano quema un presupuesto, nuestros logs registran al pagador, no la cadena. Eso alcanza mientras las flotas son chicas y de un solo tenant. Deja de alcanzar en el momento en que un agente que nuestro cliente no opera gasta el dinero de nuestro cliente, y la disputa aterriza sobre nosotros.

El analisis de gaps le pone el nombre correcto: autoridad de capa de grant contra evidencia de capa de ejecucion. Nosotros ya producimos excelente evidencia de capa de ejecucion — cada request liquidado tiene una autorizacion firmada que ata monto y destinatario. Lo que no podemos producir es la cadena por encima. Esa es la asimetria a cerrar, y se puede cerrar sin esperar al IETF, porque la cadena se puede registrar y atestar localmente mucho antes de que se pueda verificar de forma interoperable.

Tambien hay una oportunidad en la fragmentacion. Un gateway que ya ve cada request que hace un agente es el lugar natural para observar una cadena de delegacion aun cuando no exista estandar para aplicarla. Los dieciocho drafts no se ponen de acuerdo en el formato de wire; se ponen de acuerdo casi por completo en el modelo de datos — una cadena ordenada de actores, una profundidad, un link al padre y un conjunto de constraints que solo se estrechan. Ese modelo es lo bastante estable como para registrar contra el hoy.

Como mantenerse en la frontera

Pasos concretos, en el orden en que los hariamos.

Primero, registrar la cadena que ya vemos. Agregar un campo opcional de caller-chain a la metadata del request: una lista ordenada de identificadores de actor, un conteo de saltos y el identificador del principal raiz. Emitirlo en spans de OTel y en los registros de facturacion. No cuesta nada en riesgo de estandares porque es telemetria propia, y convierte "quien gasto esto" en "quien autorizo esto" el dia que un cliente pregunte.

Segundo, aplicar profundidad localmente. Los cuatro drafts no coinciden en el nombre del campo y si coinciden en la invariante. Implementar un tope por API key — maximo de saltos antes de rechazar un request — con el limite fijado por el dueño de la cuenta. El limite de profundidad es la primitiva de mayor valor de todo el corpus y no necesita que ninguna contraparte coopere.

Tercero, apostar solo a documentos de working group. Las integraciones seguras son los quince drafts adoptados, no los dieciocho individuales. CIMD ya es el camino de MCP para identidad de cliente. Identity chaining y el Identity Assertion JWT Authorization Grant son la respuesta adoptada a la delegacion cross-domain para empresas. Los transaction tokens son la respuesta adoptada a propagar contexto de llamada entre servicios. Si necesitamos una historia de delegacion para un cliente enterprise el trimestre que viene, se arma con esos tres, no con ningun draft de esta auditoria.

Cuarto, usar el claim anidado act como formato neutral. Cuando tengamos que serializar una cadena, el act de RFC 8693 es la unica representacion que a la vez esta publicada y la referencia mas de la mitad de las propuestas. Es descriptiva y no aplicativa, que es una limitacion real, pero es el formato con mas chances de sobrevivir a cualquiera que sea el draft que termine ganando.

Quinto, vigilar dos documentos, no dieciocho. El draft de casos de uso y gaps es donde va a aparecer primero el consenso del working group — si el WG de OAuth adopta algo con forma de agente, lo mas probable es que sea ese documento o un mecanismo escrito contra su lista de gaps. Y el charter de DAWN nos dice cuando la identidad de agentes finalmente tenga casa, porque en el momento en que los identificadores estables de agentes pasen de su lista de out of scope a un charter, la pregunta de la delegacion tendra a donde ir.

Sexto, cerrar el circuito con la capa de pagos. Nuestro diferencial es que ya tenemos evidencia de capa de ejecucion para cada request. Atar una cadena de llamadas registrada a la autorizacion de pago del mismo request — mismo nonce, mismo monto, mismo destinatario — produce algo que ninguno de los dieciocho drafts puede producir solo: prueba de que una cadena especifica de agentes causo una transferencia especifica. Eso vale construirlo antes de que exista el estandar, no despues.