Google publica ARD y la IETF perfila la autenticación de agentes de IA
La especificación ARD cubre el descubrimiento de capacidades y el borrador de la IETF ordena credenciales, identidad de carga y autorización delegada. Ninguna de las dos sustituye a OAuth.
La autenticación de agentes de IA no se resuelve con un protocolo único. Es una pila, y en 2026 se han movido dos piezas: Google publicó la especificación abierta Agentic Resource Discovery (ARD) para localizar y verificar capacidades de agentes, y un borrador de la IETF propone una arquitectura con credenciales de agente, autoridad delegada del usuario, identidad de carga de trabajo, autorización y rastro de auditoría. Ninguna de las dos sustituye a OAuth ni convierte por sí sola a un bot firmado en algo fiable. Lo que hacen es dibujar cómo tiene que ser una arquitectura de identidad seria para agentes.
Cuatro capas, cuatro preguntas
Cada capa responde a algo distinto. El descubrimiento contesta dónde está la capacidad y quién publica sus metadatos; ahí entra ARD, con catálogos alojados en dominios y descubrimiento federado, y no demuestra que quien llama tenga permiso para invocar nada. La identidad de carga de trabajo contesta qué software en ejecución es este, y para eso están credenciales WIMSE, identificadores SPIFFE y SVID, o mTLS. La autenticación de petición contesta si esa petición HTTP viene del cliente automatizado que dice ser: Web Bot Auth, firmas de mensajes HTTP, mTLS. Y la autorización delegada contesta qué puede hacer el agente, para qué audiencia y en nombre de quién, con tokens de acceso OAuth, intercambio de tokens y tokens de transacción.
Debajo de las cuatro hay una quinta: observabilidad. Si el operador no puede encadenar el resultado del descubrimiento, la credencial de la carga, la delegación del usuario, la decisión de autorización, la llamada a la herramienta y el efecto final, el sistema no es auditable de verdad.
Por qué la API key no llega
El modelo clásico se apoya en dos cosas: una cabecera User-Agent que nombra al bot y una API key. La primera la copia cualquiera. La segunda suele ser credencial de identidad y permiso bearer comprimidos en un secreto de larga duración; si se filtra desde un log, una variable de entorno, una imagen de contenedor o la transcripción de un agente, quien la tenga hereda su autoridad.
Con agentes eso empeora porque una sola acción involucra a varios sujetos: el operador que despliega el software, la carga del agente, que necesita identidad propia y estable, el usuario o sistema que delega autoridad y el propietario del recurso que decide qué se permite. Meterlos todos en la misma clave destruye justo la información que necesita el motor de autorización y deja un registro que solo dice que la clave hizo algo, sin decir qué carga corrió, quién autorizó ni dónde cambió de manos la autoridad.
El borrador de la IETF parte de una premisa razonable: los agentes son cargas de trabajo. Deberían recibir credenciales criptográficas en tiempo de ejecución, autenticarse como ellos mismos, llevar la autoridad delegada por separado y conservar ambas identidades a lo largo de la cadena de llamadas. En la segunda capa, SPIFFE es el ejemplo maduro: la carga recibe un SPIFFE ID y un SVID de vida corta a través del Workload API, y con eso hace mTLS o autenticación de aplicación sin arrastrar un secreto permanente junto al código. Esto sirve incluso sin humano detrás: un agente de monitorización programado también necesita identidad propia para que la política lo distinga del resto.
ARD, en cambio, es infraestructura previa a la invocación y su alcance está acotado. Puede decir qué dominio reclama una capacidad, dónde está el endpoint y qué material de confianza publica el editor. No puede decir si quien llama es el agente que afirma ser ni si el usuario autorizó la operación. Conviene además mirar la versión: el repositorio de la especificación describía la v0.91 como especificación en evolución, así que toca versionar los catálogos y no dar por fijos los campos actuales.
Para quien opera esto no hay atajo: identidad de carga y autorización delegada son problemas distintos y se resuelven con piezas distintas. Lo que queda por ver es cómo aterrizan los perfiles de Web Bot Auth en sitios reales y si ARD estabiliza su esquema, porque hasta entonces cualquier catálogo que se monte encima habrá que revisarlo. El borrador de la IETF es el mejor sitio para seguir por dónde va la discusión.
