Jacob Ideskog, CTO del vendor de identidad Curity, publicó esta semana una pieza argumentando que los stacks IAM que la mayoría de empresas corre fueron diseñados alrededor de un modelo — un humano inicia sesión, obtiene un token de sesión, toma acciones dentro de esa sesión — que la generación actual de agentes de IA está rompiendo. La estadística destacada que cita es que las identidades no humanas ahora representan más del 90% de todas las autenticaciones en sistemas empresariales modernos. Confíes o no en el número exacto de Curity, la afirmación direccional es consistente con lo que todo equipo de seguridad cloud ha estado diciendo durante el último año: cuentas de servicio, pipelines CI/CD, runners de automatización y ahora agentes impulsados por LLM están haciendo la mayor parte del tráfico de auth, y los controles alrededor de ellos están río abajo de suposiciones de diseño centradas en humanos que ya no coinciden con la carga de trabajo.

Los modos de falla arquitectónica específicos que Ideskog cataloga son reales. El IAM actual asume una sola puerta de autenticación al inicio de una sesión. Los agentes no funcionan así; encadenan llamadas API multi-paso a través de servicios, a menudo abarcando minutos u horas, sin humano en el loop entre pasos. Heredan los permisos de quien lanzó al agente, lo que significa que un solo token de agente comprometido le da a un atacante el conjunto amplio de permisos del usuario que inició el agente en lugar del conjunto estrecho de permisos de cualquier acción individual que el agente debía tomar. Los tokens de acceso permanentes que funcionaban bien para un empleado loggeado se vuelven una responsabilidad cuando un agente está tomando decisiones por sí solo sobre qué APIs llamar. Y el problema de doble identidad — el agente tiene su propia identidad Y actúa en nombre de un usuario — no tiene una primitiva limpia en la mayoría de los stacks IAM existentes.

El patrón recomendado es genuinamente sensato y no es realmente propietario de Curity. Autorización centrada en la aplicación en lugar de centrada en el usuario. Credenciales just-in-time, de mínimo privilegio, escopados a acciones específicas y ventanas de tiempo en lugar de tokens permanentes. Autorización continua en runtime en cada llamada API en lugar de una sola puerta al inicio de sesión. Tokens que cargan contexto: identidad del actor, usuario representado, acción intencionada, nivel actual de confianza. Las primitivas técnicas para todo esto existen en OAuth 2.0 hoy — token exchange (RFC 8693) para doble identidad, dynamic client registration (RFC 7591) para credenciales de agente efímeros, y rich authorization requests (RAR, RFC 9396) para tokens escopados por acción. La brecha no son los estándares. Es que la mayoría de los despliegues IAM empresariales ya sea no implementan estos endpoints, o los implementan como toggles que nadie usa.

Para desarrolladores trabajando en plataformas de agentes, la lectura práctica es que el trabajo de control de acceso es ingeniería real y no un detalle de cumplimiento. Los agentes que tu plataforma corre probablemente necesitan sus propias identidades (no prestadas del usuario), credenciales escopados de corta duración emitidos por tarea (no de duración de sesión), y una capa de autorización en runtime que pueda rechazar una acción incluso después de que el token fuera emitido (porque las señales de confianza pueden cambiar a media sesión). Curity vende productos que hacen esto; también Okta con su trabajo Workload Identity, AWS con IAM Identity Center y Verified Permissions, y varios jugadores más pequeños como Aembit y Astrix. El pitch de vendor en la pieza de Ideskog no está equivocado sobre la arquitectura, pero los desarrolladores deberían evaluar las primitivas OAuth 2.0 directamente y elegir un camino de despliegue en lugar de tratar el IAM de agentes como una categoría de fuente única. El número del 90% no humano es la parte que debería hacer que cada equipo de seguridad revise lo que está corriendo, sin importar qué vendor termine comprando.