Los agentes se están convirtiendo en una carga de trabajo de IAM, y tus cuentas de servicio no están preparadas

Primero voy a presentar el mejor argumento posible a favor del enfoque tradicional, porque no es absurdo. Las cuentas de servicio y las claves de API llevan dos décadas soportando cargas de trabajo de máquinas. Se entienden, se auditan, todas las nubes y todas las herramientas SaaS las admiten, y el equipo de seguridad ya tiene una hoja de cálculo con ellas. Cuando alguien dice que los agentes necesitan una nueva categoría de identidad, la respuesta razonable es: ya tenemos una, se llama identidad no humana, sigamos adelante.

Aquí es donde ese enfoque deja de funcionar. Una cuenta de servicio responde a la pregunta "¿qué sistema está llamando?". Un agente obliga a plantear otra más difícil: "¿qué agente está llamando, en nombre de quién, con qué objetivo y quién puede revocarlo en los próximos treinta segundos?". Las propias cifras del sector IAM indican que las identidades no humanas ya superan a las humanas por un orden de magnitud, y el Verizon DBIR de 2026 advirtió que las cuentas de servicio y de máquina son las que hay que vigilar a medida que llega la IA agéntica, según la lectura del informe de Token Security. Este es un análisis de por qué falla el encaje, qué se está construyendo para sustituirlo y qué aspecto tienen ya los fallos.

Conclusiones clave - Las cuentas de servicio y las claves de API presuponen un llamador estable y determinista. Los agentes son efímeros, no deterministas y delegan entre sí, lo que rompe las suposiciones de auditoría, revocación y mínimo privilegio incorporadas a las credenciales compartidas. - La dirección de los estándares apunta a una identidad de carga de trabajo por agente: se está presionando al grupo de trabajo IETF WIMSE para que exija que los agentes sean distinguibles por identidad, no solo por el alcance del token, con identificadores por agente al estilo SPIFFE para políticas, auditoría y revocación. - Los incidentes ya son concretos: tokens OAuth comprometidos en el ecosistema Salesloft Drift se utilizaron para pivotar hacia entornos empresariales de Salesforce, y la brecha de Hugging Face de julio fue ejecutada de extremo a extremo por un agente autónomo. - Las recomendaciones de implementación están convergiendo: identidad dedicada por agente, credenciales de corta duración y limitadas a la tarea emitidas fuera del contexto del modelo, y trazas de auditoría asociadas al agente, no al rol compartido. - Si tus agentes se autentican todos con una única cuenta de servicio compartida, tus registros no pueden decirte qué agente hizo qué. Ese es el test que deberías aplicar esta semana.

Qué ocurrió

Dos cosas convergieron durante las primeras semanas de agosto. Primero, la conversación sobre estándares se volvió concreta. Un issue del borrador de arquitectura IETF WIMSE, presentado el 4 de agosto, sostiene que el lenguaje actual del borrador sobre intermediarios de IA es demasiado débil: permite "separate workload identities or token scopes" para distinguir las acciones de agentes autónomos, pero el issue argumenta que los alcances de token no resuelven el problema. Los scopes restringen lo que un token puede hacer, pero no cambian quién es ese token. Varios agentes que comparten una credencial siguen siendo indistinguibles en los registros de auditoría, los sistemas de revocación y las políticas por agente, por mucho que difieran los scopes. La solución propuesta es que las plataformas gestionadas de agentes asignen a cada agente un identificador único de carga de trabajo, transportado en un claim dedicado y utilizado como clave estable para políticas, auditoría y revocación. Se cita como ejemplo funcional el diseño de identidad de agentes de Google, que asigna a cada agente desplegado una identidad basada en SPIFFE vinculada a su recurso de agente.

Segundo, el ritmo de incidentes continuó. La brecha de Hugging Face de mediados de julio fue la primera intrusión pública en una empresa identificada que un agente autónomo ejecutó de principio a fin: ejecución de código en el pipeline de datasets, recolección de credenciales, movimiento lateral por clústeres internos y miles de acciones durante un fin de semana. A principios de año, Moltbook, una red social para agentes de IA, filtró 1,5 millones de tokens de API desde una base de datos mal configurada pocos días después de alcanzar 1,5 millones de cuentas de agentes, según el resumen de Studio Global. Y el ejemplo recurrente del DBIR sobre ataques a identidades no humanas, el compromiso de tokens OAuth de Salesloft Drift utilizado para acceder a entornos Salesforce de grandes empresas como Google, Cisco y Zscaler, tiene exactamente la forma de las credenciales de las que dependen los agentes.

En agosto de 2026, un issue de IETF WIMSE propuso que las acciones de los agentes debían distinguirse mediante identidades de carga de trabajo separadas, no mediante scopes de token, utilizando identificadores por agente como clave estable para políticas, auditoría y revocación. La propuesta llegó después de la brecha de Hugging Face ejecutada por un agente en julio y de un incidente de enero en el que la plataforma de agentes Moltbook filtró 1,5 millones de tokens de API.

Por qué las cuentas de servicio y las claves de API no encajan con los agentes

El desajuste tiene cuatro caras, y merece la pena nombrarlas por separado porque las soluciones son distintas.

La identidad compartida destruye la atribución. Las cuentas de servicio están diseñadas para ser compartidas, estáticas y ampliamente privilegiadas. Pon diez agentes bajo una sola cuenta y tu registro de auditoría mostrará un único actor, como explica el análisis práctico de Cockroach Labs: no puedes saber qué agente tocó qué datos, rotar las credenciales exige coordinar todos los agentes y los permisos de la cuenta terminan convirtiéndose en la unión de todo lo que cualquier agente haya necesitado alguna vez. Su ejemplo anonimizado se parece a variantes que he escuchado en equipos de clientes: un agente de soporte funcionando durante tres meses con una cuenta que tenía acceso de lectura a toda la base de datos de clientes, configurada así durante el desarrollo y nunca restringida antes de pasar a producción.

Los agentes son efímeros; las claves no. Un flujo agéntico puede autenticarse en segundos ante un proveedor de modelos, un almacén vectorial, tres API y un almacenamiento en la nube, y luego desaparecer. Las claves de API de larga duración presuponen un llamador persistente al que merece la pena rotar según un calendario. El desajuste genera proliferación: claves creadas para agentes que nadie recuerda, todavía válidas y todavía demasiado amplias.

La delegación rompe la cadena de "en nombre de". Un agente que actúa para un usuario y otro que actúa de forma autónoma deberían parecer completamente distintos a tu motor de políticas. Con una cuenta de servicio compartida parecen idénticos. La delegación OAuth resuelve razonablemente bien el caso del usuario; el caso autónomo necesita la identidad propia del agente, y la delegación entre varios agentes exige que cada salto reduzca, no amplíe, la autoridad que recibe.

El modelo nunca debe contener el secreto. Esto es estructural, no de configuración. Las credenciales que se introducen en la ventana de contexto quedan expuestas al modelo y a cualquier cosa capaz de manipularlo: una inyección de prompt puede exfiltrarlas a través de las propias salidas del agente. La solución son credenciales de corta duración y alcance limitado, emitidas en el momento de la tarea por un servicio de tokens y custodiadas por la capa de ejecución de herramientas, de modo que el modelo active llamadas sin que el secreto entre en su contexto. Cockroach Labs explica bien este punto, y coincide con lo que digo a clientes que construyen sobre stacks de agentes autoalojados: el harness guarda las claves, el modelo guarda la intención.

Las cuentas de servicio compartidas rompen la atribución del agente porque aparece un único actor en los registros, sobreviven a cargas de trabajo de agentes efímeras, difuminan la diferencia entre acciones delegadas por un usuario y acciones autónomas, y animan a los equipos a pasar credenciales por el contexto del modelo, donde una inyección de prompt puede alcanzarlas, según Cockroach Labs y la comparación de miniOrange.

Qué están construyendo los proveedores y los organismos de estándares

La forma emergente tiene tres capas, y lo alentador es que proveedores y responsables de estándares están convergiendo aproximadamente en la misma.

Identidad de carga de trabajo por agente. La dirección de WIMSE descrita antes es la versión de estándares: cada agente lógico recibe un identificador único y estable, se propone una URI SPIFFE, distinto de cualquier rol de ejecución compartido, y ese identificador se convierte en la clave para políticas, auditoría y revocación. Los agentes gestionados por una plataforma que compartan una credencial de ejecución tendrían que complementarla con un claim por agente. Este es el cambio más importante: identidad por agente, no por despliegue.

Federación en lugar de secretos almacenados. La guía de Descope sobre federación de identidad de cargas de trabajo para agentes muestra el patrón: la identidad de plataforma del agente, como un rol de AWS IAM o una cuenta de servicio de Kubernetes mediante IRSA, se intercambia por un token de corta duración y alcance limitado de la plataforma de identidad, que además crea un registro de directorio para el agente de modo que las trazas de auditoría sobrevivan al token. No hay una clave de larga duración que pueda filtrarse, y el registro de identidad dura más que cualquier credencial concreta.

Descubrimiento y gobernanza como mercado. En el lado comercial, los proveedores de identidad no humana, como Reco, Token Security, Oasis, Aembit y otros, se están reposicionando alrededor de los agentes: descubrir cada credencial de agente, asignarla a un propietario, señalar privilegios excesivos y revocar de forma limpia. El enfoque de Reco es práctico: hacer corresponder el tipo de identidad con el papel del agente, OAuth delegado para acciones de usuario e identidad de carga de trabajo dedicada para acciones autónomas, y revisar los permisos a medida que crecen las responsabilidades, porque los agentes acumulan privilegios igual que los empleados acumulan llaves del edificio. El Top 10 for Agentic Applications de OWASP, publicado en diciembre de 2025, incluye Identity and Privilege Abuse como categoría de riesgo de primer nivel, lo que da a los equipos de seguridad un vocabulario común para los hallazgos de auditoría. El lugar que esto ocupa en el resto de tu stack es una cuestión de gobernanza tanto como de herramientas; cubro la parte organizativa en gobernanza de agentes de IA.

La arquitectura emergente: identidades de carga de trabajo por agente, con identificadores al estilo SPIFFE utilizados como clave para políticas, auditoría y revocación según la discusión de WIMSE; federación de la identidad de plataforma hacia tokens de corta duración y alcance limitado con registros persistentes de agentes según Descope; y un mercado de proveedores para descubrimiento y gobernanza de mínimo privilegio de identidades no humanas.

Cuando la identidad del agente sale mal

Tres incidentes, tres modos de fallo distintos, todos instructivos.

Hugging Face, julio de 2026: el problema de identidad del atacante también era el del defensor. La intrusión ejecutada por un agente recolectó credenciales de nube y clúster desde un worker de ejecución de código y se movió lateralmente, la historia clásica de una carga de trabajo con privilegios excesivos: un componente de procesamiento de datos contenía credenciales que merecía la pena robar. El detalle menos difundido es la asimetría forense que Hugging Face reveló: el agente atacante no estaba sujeto a ninguna política de uso, mientras que el trabajo forense de la propia empresa quedó inicialmente bloqueado por las salvaguardas de los modelos alojados que probaron. Por eso realizaron el análisis forense con un modelo de pesos abiertos, GLM 5.2, en su propia infraestructura. Fallos de identidad y acceso a ambos lados del mismo incidente.

Salesloft Drift, la advertencia del DBIR: tokens como llaves maestras. Tokens OAuth comprometidos de un ecosistema de proveedor se utilizaron para pivotar hacia entornos Salesforce de grandes empresas. Sin contraseñas, sin phishing a humanos: credenciales no humanas, ampliamente confiadas y reutilizadas silenciosamente. Cada agente que conectas a una herramienta SaaS mediante una concesión OAuth de larga duración tiene esta forma de riesgo, y la mitigación tiene la misma forma: corta duración, alcance estrecho, por agente y revocable.

Moltbook, enero de 2026: las plataformas de agentes agregan riesgo de identidad. Una plataforma para cuentas de agentes filtró 1,5 millones de tokens de API, además de direcciones de correo y mensajes entre agentes, desde una base de datos mal configurada, según el relato de Studio Global. Cuando centralizas la identidad de agentes, también centralizas su radio de impacto. Conviene decir que trataría algunos detalles que circulan sobre el incidente como reportados y no auditados: la divulgación de Hugging Face es primaria, mientras que las cifras de Moltbook proceden de cobertura secundaria.

Entre los fallos documentados de identidad de agentes están la brecha de Hugging Face de julio de 2026, en la que un agente autónomo recolectó credenciales de nube y clúster y se movió lateralmente según el análisis de Waxell; el pivot de tokens OAuth de Salesloft Drift hacia tenants empresariales de Salesforce según Token Security sobre el DBIR 2026; y la filtración de 1,5 millones de tokens de API de agentes de Moltbook.

Qué hacer ahora

1. Esta semana: enumera las credenciales de tus agentes y aplica la prueba de atribución: toma cualquier acción de un agente en tus registros y pregunta si puedes saber qué agente la realizó, en nombre de quién y si podrías revocar solo a ese agente sin afectar a los demás. Si la respuesta es no, tienes un problema de identidad compartida y ese es el primer hallazgo que debes corregir.

2. Este mes: mueve un agente autónomo fuera de su credencial de larga duración y pásalo a tokens de corta duración y limitados a la tarea, emitidos por un servicio de tokens o una plataforma de identidad, custodiados en la capa de ejecución de herramientas y nunca presentes en el contexto del modelo. Empieza por el agente con el acceso más amplio; suele ser aquel al que alguien dio permisos "temporales" con prisa.

3. Este trimestre: asigna a cada agente lógico su propia identidad estable, un SPIFFE ID donde tengas la infraestructura o una cuenta de servicio única por agente donde no la tengas, y usa esa identidad como clave para auditoría y alertas. Escribe el runbook de revocación antes de necesitarlo. Si estás en una fase anterior y todavía decides dónde deberían ejecutarse los agentes, la comparación entre agentes locales y en la nube determina cuánto de esto puedes controlar directamente.

Preguntas frecuentes

¿Qué es la identidad de un agente en términos de IAM?

Una identidad distinta y verificable asignada a un agente de IA individual, separada de la plataforma en la que se ejecuta y de los usuarios en cuyo nombre actúa. Se utiliza como clave estable para autenticación, políticas de autorización, trazas de auditoría y revocación, del mismo modo que una identidad de carga de trabajo identifica un microservicio, pero adaptada a llamadores efímeros, no deterministas y capaces de delegar entre sí.

¿Por qué los agentes no pueden compartir simplemente una cuenta de servicio?

Técnicamente pueden, y la mayoría lo hace hoy. Los fallos son estos: los registros de auditoría muestran la cuenta compartida en lugar del agente actuante, por lo que pierdes atribución; los permisos de la cuenta crecen hasta convertirse en la unión de las necesidades de todos los agentes; revocar a uno obliga a rotar credenciales para todos; y no puedes distinguir acciones delegadas por usuarios de acciones autónomas. Funciona hasta el primer incidente, y entonces no tienes forma de reconstruir qué ocurrió.

¿Qué están haciendo los organismos de estándares respecto a la identidad de agentes?

El grupo de trabajo IETF WIMSE está ampliando la arquitectura de identidad de cargas de trabajo a intermediarios de IA, con una propuesta activa que exige identificadores por agente, con URI SPIFFE como mecanismo sugerido, en lugar de depender de scopes de token. OWASP publicó en diciembre de 2025 un Top 10 for Agentic Applications que incluye el abuso de identidad y privilegios como categoría, y la Cloud Security Alliance tiene un marco de gobernanza de identidad de agentes que recomienda una identidad única por agente.

¿Deberían aparecer alguna vez las credenciales de un agente en el contexto del modelo?

No. Todo lo que está en la ventana de contexto es visible para el modelo y puede ser exfiltrado mediante inyección de prompt. El patrón aceptado es emitir credenciales en el momento de la tarea mediante un servicio de tokens, mantenerlas en la capa de ejecución de herramientas entre el modelo y la API, limitarlas a la tarea y hacerlas de corta duración. El modelo solicita la acción; el harness guarda el secreto.

En resumen

En identidad se suele decir que la identidad es el plano de control, y los agentes están a punto de poner esa idea a prueba con más dureza que los microservicios. La dirección está lo bastante clara como para empezar a construir hacia ella hoy: identidad por agente, secretos fuera del modelo, tokens que caduquen más rápido de lo que se propagan los incidentes y auditoría capaz de responder "qué agente, en nombre de quién, con qué objetivo". Las organizaciones que se quemaron este verano no ejecutaban configuraciones exóticas; utilizaban credenciales compartidas y confiaban en que nada saliera mal. Esa es la brecha que hay que cerrar, y puede cerrarse con tecnología que en gran medida ya existe.

Si estás encajando identidad de agentes en un entorno IAM existente y quieres a alguien con experiencia práctica en la sala, es un trabajo que hago. Ponte en contacto.

Fuentes

• IETF WIMSE WG, issue #139 de draft-ietf-wimse-arch, "AI and ML-Based Intermediaries: token scopes do not create per-agent identity": https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/issues/139 (presentado 2026-08-04, consultado 2026-08-29)

• Cockroach Labs, "AI Agent Identity Security": https://www.cockroachlabs.com/blog/ai-agent-identity-security/ (publicado 2026-07-17, consultado 2026-08-29)

• Token Security, "The 2026 Data Breach Investigations Report Confirms It: Identity Is the Control Plane for Agentic AI": https://www.token.security/blog/the-2026-data-breach-investigations-report-confirms-it-identity-is-the-control-plane-for-agentic-ai (publicado 2026-05-20, consultado 2026-08-29)

• Descope, "What Is Workload Identity Federation for AI Agents?": https://www.descope.com/learn/post/workload-identity-federation-for-agents (publicado 2026-06-22, consultado 2026-08-29)

• miniOrange, "Why AI Agents Need Workload Identity, Not Shared Secrets": https://www.miniorange.com/blog/workload-identity-ai-agents/ (publicado 2026-05-20, consultado 2026-08-29)

• Reco, "Non-Human Identities for AI Agents: How to Govern Access": https://www.reco.ai/blog/non-human-identities-for-ai-agents (publicado 2026-07-20, consultado 2026-08-29)

• Waxell, "Hugging Face Breach: How an AI Agent Ran the Attack": https://www.waxell.ai/blog/hugging-face-agentic-attacker-ai-breach-2026 (publicado 2026-07-17, consultado 2026-08-29)

• Studio Global, "EU AI Act August 2026: Enforcement Powers Go Live as Autonomous Agent Breach Tests Regulators": https://www.studioglobal.ai/discover/answers/what-key-enforcement-powers-and-transparency-obligations-6a6bff1f2240a0fb8c880846 (publicado 2026-08-17, consultado 2026-08-29)