(2/3) El mejor mapa del problema de identidad agéntica
En el primer post de esta serie expliqué por qué la IA agéntica rompe el stack de identidad: los sistemas de identidad que hemos construido dan por hecho que hay una persona al teclado, y los agentes se llevan ese supuesto por delante desde el primer día. También avancé que trazaría la cartografía más clara del terreno que pudiera encontrar. Este es ese mapa.
La mayor parte del contenido sobre "identidad en IA" que circula ahora mismo por ahí es de gente vendiendo cosas y explicando por qué la solución está en su sistema propietario. El paper que comento aquí es lo contrario, y por eso me fío. Identity Management for Agentic AI fue preparado para la OpenID Foundation, con Tobin South como editor principal, redactado a lo largo de 2025 con el AI Identity Management Community Group y la Loyal Agents Initiative de Stanford, y revisado por un nutrido plantel de ingenieros de primer nivel. Es el análisis de un organismo de estándares, no un pitch. Te dice qué funciona ya, qué está emergiendo y — la parte escasa — qué todavía nadie ha resuelto. Lo he leído más de una vez. Y esto es lo que me ha quedado.
El stack de hoy funciona — dentro de una empresa, para un agente que espera confirmaciones
El paper se divide en dos mitades: soluciones inmediatas para los agentes que desplegamos hoy, y los problemas de futuro para los que estamos a punto de desplegar. El veredicto honesto sobre la primera mitad cabe en una sola frase, y la cito porque es oro:
«Los agentes y los patrones de autenticación y autorización actuales pueden funcionar para agentes síncronos que usan múltiples herramientas dentro de un único dominio de confianza, pero no para contextos asíncronos o de múltiples dominios.»
Léela dos veces. Dentro de una sola empresa, para un agente que actúa mientras esperas, las bases aguantan. OAuth 2.1 con PKCE asegura el flujo. Externalizas la decisión a un proveedor de identidad o a un punto de decisión de política en lugar de codificarla — la separación entre Policy Enforcement Point y Policy Decision Point que NIST documentó hace una década. Gestionas el ciclo de vida del agente con la misma maquinaria que usas para los empleados: SSO para iniciar sesión, y SCIM para provisionar y, lo que es crítico, para desprovisionar. El paper apunta a trabajo experimental para dar a SCIM un tipo de recurso AgenticIdentity de primera clase, de modo que un agente se convierte en una entidad gestionada con propietarios y membresías en grupos en lugar de una API key huérfana. Nada de esto es exótico o complicado. Un equipo de infra competente puede construirlo sin problemas.
Sin embargo, dos condiciones sostienen toda esa imagen: síncrono y dominio de confianza único. Rompe cualquiera de las dos y estás en la segunda mitad del paper, donde los problemas resueltos se agotan.
Nombrar los problemas futuros con precisión
Nombra un problema con precisión y estás a mitad del camino de resolverlo — y este paper, como mi propio trabajo, no rehúye las dificultades. Las enumera, con la franqueza de quienes han intentado construir y conocen el fracaso.
Empieza por la pregunta más básica — ¿qué es la identidad de un agente, exactamente? — y en lugar de pretender que hay una respuesta, despliega cuatro modelos arquitectónicos: la cuenta de servicio mejorada (una identidad de workload enriquecida con metadatos agent_model, agent_version — probablemente el patrón empresarial de corto plazo); la subidentidad de usuario delegado (una identidad derivada y vinculada a la sesión del usuario, el flujo de «en nombre de» real); la confianza federada (un tejido interoperable entre dominios, construido sobre algo como OpenID Federation); y la identidad soberana y portable (cada agente con sus propias claves y un identificador globalmente único, mediante esquemas como los DIDs). Propuestas como OpenID Connect for Agents están intentando estandarizar las claims de identidad por debajo. El paper no se moja por ninguno todavía — mejor aprenderse el terreno antes de aventurarse en él.
Delegación, no suplantación: esa es la columna vertebral
Si tuviera que comprimir el argumento del paper en una sola pincelada, sería así: no dejes que los agentes suplanten a los usuarios; empieza a dejar que transporten autoridad delegada. Hoy un agente actúa con tus credenciales y el registro de auditoría no puede distinguiros (el agujero negro que describí en el primer post). La solución es un flujo real de «en nombre de» donde el token de acceso transporta dos identidades distintas: el usuario que delegó (en el claim sub) y el agente que actúa (en el claim act). Un enlace limpio y auditable desde el primer paso.
El poder, y la dificultad, aparece con la delegación recursiva — un agente entregando una subtarea, y una porción de su autoridad, a otro. Como una muñeca rusa, dice el paper, y lo dice como advertencia. Un servidor de recursos al final de una cadena de cinco saltos tiene que verificar criptográficamente todo el camino de vuelta hasta el humano original, no solo el último agente que lo llamó. Eso exige atenuación de scope: estrechar provablemente el permiso en cada paso. El paper es refrescantemente concreto sobre las opciones — OAuth 2.0 Token Exchange para setups centralizados en hub-and-spoke, y tokens de capacidad como Biscuits y Macaroons para los descentralizados, donde el portador puede acuñar una versión más restringida de un token offline, con la autoridad embebida en la propia credencial bajo un modelo de object-capability. Esta es la parte que la mayoría de los sistemas de agentes en producción en 2026 hacen mal. Ejecutan cada agente al mismo nivel de autorización con todas las herramientas, y llaman frontera a un system prompt.
Y el problema que ensombrece todo esto: la revocación, que los autores llaman directamente «un problema crítico y, en gran medida, sin resolver». Los tokens atenuados offline lo empeoran — revoca el padre y no hay manera limpia de llegar a los hijos ya delegados aguas abajo. Las respuestas hasta ahora son claras pero parciales: el Shared Signals Framework para propagar eventos de revocación casi en tiempo real, y la medida pragmática de acotar una credencial por número de ejecuciones para que una revocación retrasada siga limitando el daño.
La gobernanza tiene que pasar de los clics al código
En el primer post de esta serie argumenté que la supervisión humana en el bucle (human-in-the-loop) colapsa a escala por la fatiga del consentimiento. La respuesta del paper es la misma que daría yo, y es estructural. No se arregla la fatiga del consentimiento pidiendo a la gente que preste más atención. Se mueve la gobernanza del clic al código.
Tres patrones que despliega, en sofisticación creciente. Política como código: un administrador define el entorno operativo del agente una sola vez — límites de presupuesto, niveles de datos, velocidad de llamadas — y el sistema lo hace cumplir de forma programática. Autorización basada en intención: el usuario aprueba una intención de alto nivel en lenguaje natural («reserva mi viaje para la conferencia»), y el sistema la compila en un conjunto de permisos de mínimo privilegio. Autorización dinámica basada en riesgo: las acciones rutinarias pasan automáticamente, y solo una petición anómala dispara una aprobación humana fuera de banda mediante CIBA. La idea central es un híbrido — usar el modelo para traducir la intención humana difusa en una política formal y legible por máquina, y luego dejar que el sistema determinista mantenga la línea aunque el agente malinterprete la instrucción. El humano aprueba algo intuitivo; el runtime hace cumplir algo exacto. En esa brecha — entre intuitivo y exacto — es donde vive realmente la seguridad.
Y luego está el dinero
La sección más inspiradora del paper es la económica. La utilidad real de un agente aparece cuando puede hacer transacciones — comprar datos, pagar por una API, cerrar una compra — y todo el modelo de seguridad del comercio electrónico da por hecho que hay un humano presente en el punto de venta. Quita al humano y necesitas nuevas vías.
El paper mapea tres capas que ya se están formando. FAPI, el perfil de alta seguridad de la OpenID Foundation, endurece OAuth para acciones financieras irreversibles con tokens vinculados al emisor. El Agent Payments Protocol de Google introduce el Mandate — un artefacto criptográficamente firmado de intención, dividido en un Intent Mandate («esto es lo que autoricé») y un Cart Mandate («esta es la compra específica que lo cumplió»), de modo que existe una traza de auditoría no repudiable para una transacción autónoma. Y KYAPay propone un proceso de «Know Your Agent» que, en palabras del paper, extiende «la verificación de identidad tradicional KYC/KYB al propio agente», emitiendo un token que agrupa identidad verificada con información de pago. Quédate con esa frase — Know Your Agent. El mercado ya está alcanzando la accountability con forma de KYC para los agentes. Solo que todavía no ha llegado a hacerlo de una manera que proteja al humano detrás del agente. Nota mental.
El nudo que el paper deja abierto
Con todo lo amplio que es, el documento vuelve a una tensión que es incapaz de resolver, y es a la que llevo días dando vueltas.
«La trazabilidad necesaria para las auditorías permite el rastreo entre dominios que puede crear perfiles de comportamiento completos y potencialmente sensibles. Los mecanismos de divulgación selectiva — que aprovechan técnicas criptográficas como las pruebas de conocimiento cero y las credenciales anónimas — ofrecen un camino a seguir… pero integrar estas técnicas con los estándares de identidad existentes y los requisitos regulatorios sigue siendo un desafío significativo.»
Ahí está de nuevo, dicho por quienes más saben. Para hacer a un agente responsable le adjuntas identidad; adjunta identidad y te cargas la privacidad. Las pruebas de conocimiento cero y las credenciales anónimas se perfilan como el camino a seguir — demostrar que «hay un humano real y responsable detrás de mí» sin revelar cuál — y luego se nombran, con la misma claridad, como todavía no integradas en los estándares y los reguladores que las harían reales.
La propia conclusión del paper enmarca el trabajo de esta década como tres desplazamientos: delegación real sobre suplantación, gobernanza escalable sobre fatiga del consentimiento, y confianza interoperable sobre silos propietarios. Añadiría la línea que los autores ponen casi de pasada, porque es la restricción que elimina las respuestas fáciles: lo que sea que construyamos, «no debe convertirse en un jardín vallado». El movimiento con financiación es un servicio centralizado de identidad de agentes que alquilas. El paper, con razón, dice que la economía abierta de agentes no puede funcionar sobre el permiso de una sola empresa.
Así que ese es el mapa: las bases son reales, los problemas futuros están nombrados seriamente y con rigor, y el más difícil de todos — responsabilidad y privacidad al mismo tiempo, sin un guardián central — se deja como un desafío abierto con una dirección criptográfica y sin un camino construido.
Estoy construyendo ese camino. En el tercer y último post esbozaré, a alto nivel, cómo desharía ese nudo abierto — cómo un agente puede demostrar que hay un humano real, responsable y verificado detrás de él sin que nadie descubra nunca quién. No como un resumen de las ideas de otros esta vez. Como el enfoque en el que llevo noches trabajando — y al que vengo dando vueltas desde 2014, cuando empecé a construir por primera vez con identidades digitales.
Fuente: OpenID Foundation, Identity Management for Agentic AI (editor principal Tobin South, con el AI Identity Management Community Group y la Loyal Agents Initiative de Stanford), octubre de 2025. Todo el texto entrecomillado proviene del paper.
