Resumen

  • El IETF anunció que el grupo OAuth celebrará el 28 de septiembre de 2026 una reunión provisional virtual con la agenda «Anthropic & OpenAI Agentic Use Cases». El aviso no acredita que las empresas respalden un borrador ni que el grupo haya adoptado una solución.
  • RAR puede describir una cantidad y un beneficiario exactos, mientras DPoP vincula un token a una clave. La brecha aparece cuando el modelo genera la llamada: esos mismos valores no deben definir el acto y otorgarse su propio permiso. Una fuente independiente debe autorizar los parámetros finales y el primer punto capaz de producir el efecto debe verificarlos y consumir la autoridad.

Un token para payments.write responde qué clase de puerta puede abrir un cliente. No decide qué cuenta debe estar al otro lado. Si el agente extrae el IBAN de un correo manipulado, todo el armazón de autenticación puede funcionar como fue diseñado y aun así ejecutar la orden equivocada.

El anuncio del IETF fija la reunión para las 17:00–18:00 UTC. Su agenda, de una línea, confirma un tema de trabajo. No revela qué expondrán Anthropic u OpenAI, si apoyan un texto o si existe consenso. Tampoco convierte una contribución individual en documento del grupo.

La carta de OAuth define delegación limitada sin compartir credenciales duraderas ni necesariamente la identidad. RFC 9396 añade authorization_details para requisitos finos. Su ejemplo de pago incluye importe y acreedor. Cuando esos datos ya son conocidos y aprobados, el servidor puede rechazar una petición que no coincida. La precisión de la autorización no es el vacío.

La pregunta enviada el 1 de septiembre se refiere a otro momento: el nombre y los argumentos nacen después de la inferencia. Una inyección puede conservar el recurso y la acción permitidos, pero sustituir la dirección, el archivo o la cuenta. En la discusión posterior sobre RAR se admite que copiar esa salida a un objeto detallado representa bien los valores; no crea una decisión ajena al modelo.

La fuente de autoridad puede ser una orden validada, un mandato previo, una política empresarial versionada o una aprobación de excepción. No exige una persona ante cada llamada. Exige que la propuesta no se convierta en permiso por el solo hecho de tener JSON válido.

El borrador Chen ilustra el colapso de contexto: Alice pide organizar un pícnic el lunes y recibe el martes una pantalla con parks.book y calendar.write, sin el motivo, el parque o el precio. El documento no encarga a OAuth interpretar lenguaje natural; intenta conservar la relación entre límites anteriores y ejecución posterior.

El borrador Liu separa una propuesta estructurada en JWT, sin el texto natural original, del token que representa una operación específica confirmada. El planteamiento Yossif llama T0 al mandato humano y T1 al acto autónomo. Volver al usuario miles de veces destruye la autonomía; no llevar sus límites a T1 deja los actos sin control verificable. Este último texto declara que no especifica comportamiento de protocolo.

Todos son Internet-Drafts, trabajos en curso. Sus verbos normativos no son obligaciones del IETF. El encuentro de septiembre no los eleva a estándar.

La unión técnica necesita canonicalización. Orden de claves JSON, números, valores implícitos, URL o campos vivos de un formulario pueden cambiar la huella o el efecto. Hay que versionar la regla y cubrir herramienta, destino, cantidad, objeto y clase de consecuencia. Pero el digest solo prueba igualdad: una cuenta maliciosa bien resumida sigue siendo maliciosa. El hash no aporta al principal ausente.

El borrador Das describe una opción concreta: mantener el Candidate Act sin efecto, canonicalizar y resumir, validar, emitir autoridad acotada, verificarla y consumirla en el dispatch sink, y solo después invocar. Es un borrador informativo individual con nota de propiedad intelectual, no una arquitectura aprobada. Su criterio de ubicación sí es útil: tool_use no equivale a invoke().

El sink es el primer lugar que puede cambiar el mundo. A veces será el servidor HTTP; otras, la tabla de funciones local, el controlador que pulsa «enviar» o el cliente MCP. Si un wrapper antiguo conserva credenciales y evita la barrera, esa ruta define la seguridad real. Un mensaje de seguimiento formula, como opinión de un participante, que no debe invocarse si el digest final no coincide con una policy assertion autorizada.

RFC 9449 aporta DPoP: reduce el replay de tokens robados al exigir la clave esperada. No juzga las decisiones del poseedor legítimo. RFC 8693 transporta identidad y delegación mediante intercambio de tokens; tampoco certifica los últimos argumentos.

La cadena continúa después de invocar. Si la autoridad se consume y el host cae antes de recibir respuesta, no se sabe si hubo efecto. Reintentar puede duplicar un pago; no reintentar puede perderlo. Hace falta identidad idempotente y separar autorizado, enviado, aceptado, confirmado y observado. Un 200 es una respuesta, no el objetivo humano.

El recibo mínimo incluye principal y versión de política, mandato, contexto, herramienta candidata, consecuencia, canonicalización y digest; fuente independiente, emisor, audiencia, caducidad y clave; sink, digest vivo, replay y consumo; respuesta, estado persistente, compensación y resultado visible. Sin ese mapa, «cancelar tarea» no sabe qué autorizaciones derivadas o efectos debe retirar.

La especificación inicial mínima de Heng Lu aconseja estandarizar solo la estructura necesaria para reconocer mandato, acto, vínculo, sink y recibo, y mantener local la política de riesgo. Sus capas de realidad impiden confundir token, autorización, dispatch, estado externo y resultado. La primacía del código operativo exige probar cambios de beneficiario, carreras, bypass y caídas. Si el efecto aparece sin el recibo correspondiente, hay vocabulario de autorización, no control.

Fuentes