La gestión de identidades no humanas se ha convertido en un problema de seguridad a nivel directivo, ya que las máquinas, los servicios, los bots, las cargas de trabajo, las claves API y los agentes de IA ya superan en número a los empleados en proporciones abrumadoras. En abril de 2026, la Cloud Security Alliance citó estimaciones de unas 96 identidades no humanas por cada persona en el sector de los servicios financieros, y de hasta 144:1 en entornos con un uso intensivo de la nube. La solución no es otra política de contraseñas. Se necesita un inventario, la asignación de responsabilidades, el principio del privilegio mínimo, la rotación, la supervisión y una retirada rápida de servicio.
La gestión de identidades no humanas se ha convertido en el nuevo punto crítico de la gestión de identidades y accesos (IAM)
La intención de búsqueda en este caso es informativa, con un enfoque práctico en materia de seguridad: quieres saber qué significa la gestión de identidades no humanas, por qué las cifras parecen de repente absurdas y qué controles reducen realmente el riesgo. La respuesta breve resulta incómoda. La mayoría de las organizaciones diseñaron sus programas de identidad en torno a los empleados, los contratistas y los administradores con privilegios, mientras que la verdadera proliferación de identidades se ha extendido a las cuentas de servicio, las claves API, los tokens OAuth, los certificados, las identidades de cargas de trabajo, las credenciales de CI/CD, los bots de automatización y los agentes de IA.
El informe sobre servicios financieros de 2026 de la Cloud Security Alliance cuantificó ese cambio con cifras concretas. Un estudio de proveedores citado por la CSA estimaba que la proporción de identidades no humanas era de aproximadamente 144:1 en todos los sectores y de 96:1 en los servicios financieros. CyberArk informó en abril de 2025 de que las identidades de máquinas superaban a las humanas en una proporción de más de 80:1, por lo que la tendencia no ofrece dudas, aunque las proporciones varíen según el entorno.
Estas son las cifras concretas. Un banco con 12 000 empleados y una proporción de 96:1 podría tener alrededor de 1,15 millones de identidades no humanas. Con una proporción de 144:1, una empresa de software nativa de la nube con 2.000 empleados podría estar gestionando unas 288.000 identidades de máquina. Nadie revisa eso manualmente. Nadie.
Los equipos de seguridad ya se han enfrentado a este problema anteriormente en el ámbito del desarrollo de software, donde la rapidez genera una deuda operativa oculta. El mismo patrón se observa en El desarrollo de software avanza más rápido de lo que los equipos de seguridad pueden controlar: las credenciales se crean por motivos justificados, pero luego se olvidan una vez finalizada una implementación, una migración o un experimento.
¿Qué es una identidad no humana?
Una identidad no humana (NHI, por sus siglas en inglés) es una identidad digital utilizada por algo que no sea una persona para autenticarse, solicitar acceso, ejecutar código o llamar a otro sistema. El informe de la CSA de septiembre de 2024 define las NHI como aquellas que incluyen bots, claves API, cuentas de servicio, tokens OAuth y secretos. IBM también describe esta categoría de forma amplia: aplicaciones, servicios, cargas de trabajo, contenedores, API, bots, agentes de IA y dispositivos.
Esa definición es importante porque los equipos suelen discutir sobre las etiquetas en lugar de sobre la exposición. Una función de carga de trabajo de Kubernetes, una GitHub Acciones secretas, a servicio en la nube Es posible que una cuenta y un rol de aplicación de Microsoft Entra se encuentren en consolas diferentes, pero para un atacante es lo mismo: una forma de actuar dentro de tu entorno sin ser un usuario humano.
La gestión de identidades no humanas es la disciplina que consiste en identificar dichas identidades, vincularlas a sus titulares y a los objetivos empresariales, limitar sus capacidades, rotar o sustituir sus credenciales, supervisar su uso y eliminarlas cuando ya no sean necesarias. Los buenos programas tratan el acceso a los sistemas como un ciclo de vida. Los malos lo tratan como si fuera una simple instalación.
Un escollo del que casi nadie habla: el término «propietario» suele referirse a la persona que creó la identidad, no a la persona responsable de los riesgos que esta conlleva en 2026. Esa diferencia es enorme tras una reorganización. Si el creador abandonó la empresa en 2024 y el servicio sigue teniendo acceso a la base de datos de producción, es posible que tu inventario esté técnicamente completo, pero sea inútil desde el punto de vista operativo.
Las cifras que se esconden tras la crisis de identidad de las máquinas
El informe sobre servicios financieros de CSA de 2026 también reveló que el riesgo relacionado con la identidad no humana ocupaba el puesto 24% entre las preocupaciones de seguridad relacionadas con la nube y la IA en dicha encuesta, lo que equivale aproximadamente a la seguridad de las API y se sitúa por delante del riesgo relacionado con la identidad humana. En el mismo informe, la mejora de la seguridad de la identidad y el acceso fue la principal prioridad de seguridad de la infraestructura en la nube para los próximos 12 meses, con un valor de 48%, seguida de la integración de la seguridad de la IA, con 44%.
Esas dos cifras explican por qué la gestión de identidades no humanas está pasando de ser una actividad de nicho dentro de la gestión de identidades y accesos (IAM) a convertirse en un programa de seguridad fundamental. La seguridad de las API, la seguridad en la nube, la gobernanza de la inteligencia artificial y la gestión de secretos se reducen todas a la misma pregunta: ¿qué identidad está realizando esta acción y debería permitirse?
| Fuente y año | Cifra reportada | Por qué es importante |
|---|---|---|
| CyberArk, 2025 | Las identidades de las máquinas superan en número a las de los seres humanos en una proporción de más de 80 a 1. | Esto demuestra que la magnitud del problema ya superaba los procesos de revisión de IAM realizados por personas |
| Informe de CSA sobre servicios financieros, 2026 | Aproximadamente 96:1 en el sector de los servicios financieros | Los sectores regulados no están exentos de la proliferación de identidades de máquinas |
| Informe de CSA sobre servicios financieros, 2026 | El proveedor estima una proporción de aproximadamente 144:1 en todos los sectores | Los entornos con un uso intensivo de la nube pueden albergar muchas más cuentas de máquinas que de personal |
| Encuesta de la CSA/Oasis, 2026 | 78% carece de políticas documentadas para la creación o eliminación de identidades de IA | Se están incorporando agentes de IA antes de que se haya formalizado el marco de gobernanza |
| Encuesta de la CSA/Oasis, 2026 | El 79% de los profesionales de TI se sienten poco preparados para prevenir los ataques basados en el NHI | La brecha en materia de competencias y herramientas sigue siendo amplia |
Los ratios pueden parecer algo abstractos, así que compruébalos con tu propio parque de activos. Cuenta el número de empleados y multiplícalo por 80, 96 y 144. Si tu inventario conocido está muy por debajo de esos rangos, es posible que tu entorno esté inusualmente limpio. Lo más probable es que te falten identidades en los sistemas de CI/CD, las plataformas SaaS, los inquilinos de la nube, los entornos de pruebas de los desarrolladores o la automatización abandonada.
Por qué los agentes de IA hacen que los antiguos controles de cuentas de máquinas parezcan ineficaces
Las cuentas de servicio tradicionales ya entrañan riesgos, pero muchas de ellas tienen un comportamiento predecible. Realizan copias de seguridad, sincronizan un directorio, implementan una versión o transfieren datos entre sistemas. Los agentes de IA complican el modelo, ya que sus acciones pueden ser dinámicas, delegadas y encadenadas entre distintas herramientas.
El informe técnico de CSA sobre la gobernanza de la IA agentiva, de mayo de 2026, afirma que los agentes de IA pueden obtener permisos en tiempo de ejecución, generar subagentes, invocar API externas, escribir o ejecutar código y encadenar acciones entre sistemas. La documentación de Entra de Microsoft de 2026 define las «identidades de agente» como cuentas de identidad para agentes de IA, y señala que los agentes de IA no utilizan contraseñas, SMS, claves de acceso ni aplicaciones de autenticación para autenticarse.
Ese último punto descarta cualquier respuesta a la ligera. No se puede garantizar la seguridad de un agente de la misma forma que se garantiza la de un comercial mediante avisos de autenticación multifactorial (MFA) y formación sobre phishing. Microsoft también describe el acceso a la identidad de los agentes a través de los permisos de Microsoft Graph, los roles de RBAC de Azure, los roles de directorio de Microsoft Entra y los roles de aplicación de Microsoft Entra, lo que significa que el acceso de los agentes puede llegar a los mismos planos de control de alto valor que los de los administradores humanos.
Los servicios financieros añaden un elemento de mayor complejidad. En junio de 2026, la CSA advirtió de que los pagos por medio de agentes obligan a las instituciones a determinar si la identidad que se esconde tras una transacción autónoma es la del consumidor, la del agente, la del comerciante o la de la plataforma. ¿Quién es responsable cuando un agente autoriza un pago erróneo?
Para contextualizar, el riesgo de seguridad no se limita a los almacenes de identidades. Ya se están estudiando los agentes de IA como herramientas operativas que los atacantes pueden manipular, tal y como se explica en el artículo sobre cómo los hackers están utilizando los agentes de IA como arma, y los protocolos de las herramientas de los agentes establecen sus propios límites de permisos, tal y como se indica en las directrices sobre la seguridad de los servidores MCP.
¿Cómo se protegen las identidades de las máquinas sin sobrecargar al equipo?
La respuesta no consiste en adquirir un panel de control y dar la batalla por ganada. La gestión de identidades no humanas requiere controles «aburridos» que realmente se mantengan bajo presión: inventario, titularidad, normas de ciclo de vida, principio del privilegio mínimo, rotación, supervisión y auditabilidad. Las directrices de IBM para 2026 y los materiales de la CSA para 2026 coinciden en torno a esas mismas familias de controles.
Empieza por el inventario, pero no lo conviertas en un proyecto de «arqueología de hojas de cálculo». Critical Start recomendó en mayo de 2026 un inventario unificado del NHI que abarcara cuentas de servicio, claves API, tokens OAuth, certificados, identidades de cargas de trabajo, credenciales de CI/CD, bots de automatización y agentes de IA, vinculados al propietario, la función empresarial, el alcance de los privilegios, la fuente de creación y el registro de último uso.
- Identifica identidades en distintos proveedores de servicios en la nube, plataformas SaaS, sistemas de código fuente, herramientas de CI/CD, gestores de secretos, directorios y plataformas de gestión de terminales.
- Asigna una persona o un equipo responsable, además de una función empresarial, y no te limites a un campo de «creador».
- Registra el alcance de los privilegios, la fuente de creación, el tipo de credencial, la fecha y hora de la última utilización y los sistemas afectados.
- Elimina las identidades que no se utilicen, sobre todo aquellas que no tengan actividad reciente o que no tengan titular.
- Rota las claves secretas y las credenciales según un calendario establecido en la política, con una rotación de emergencia en caso de sospecha de exposición.
- Aplicar el principio del privilegio mínimo mediante roles con ámbito limitado, credenciales de corta duración y la aprobación de permisos de alto riesgo.
- Supervisa el comportamiento para detectar llamadas a la API inusuales, nuevas ubicaciones geográficas, cambios en los privilegios o accesos que se salgan del patrón de servicio esperado.
Sinceramente, la primera ronda de limpieza es donde muchos programas fracasan. Los equipos detectan miles de identidades, entran en pánico y, a continuación, excluyen las peores porque nadie quiere interrumpir el servicio de producción. Un enfoque más adecuado consiste en clasificarlas según el riesgo: credenciales expuestas externamente, roles privilegiados en la nube, claves obsoletas, propietarios desconocidos e identidades que pueden crear otras identidades.
Las plataformas de seguridad en la nube pueden ser de gran ayuda, sobre todo cuando ofrecen una visión global de las cargas de trabajo, las identidades y el comportamiento en tiempo de ejecución; si estás comparando herramientas, esta descripción general de plataformas de seguridad en la nube para empresas destinadas a equipos de DevOps es un aliado útil. Las adquisiciones en el ámbito de la identidad y la consolidación de la gestión de identidades y accesos (IAM) también son importantes, por lo que la decisión de Accenture de expandirse con IAMConcepts resulta relevante para la creciente demanda de conocimientos especializados en materia de seguridad de la identidad.
La filtración de secretos es la vía de intrusión que se esconde a plena vista
El «Top 10 de identidades no humanas» de OWASP, publicado para 2025, enumera riesgos como la filtración de secretos. Esto no es sorprendente, pero sigue sin valorarse lo suficiente. La filtración de secretos es el vector de ataque silencioso: sin correos electrónicos de phishing, sin activación de malware, sin ataques de fuerza bruta ruidosos. Solo una credencial válida que realiza acciones que parecen legítimas.
El informe sobre el NHI de 2024 de la CSA definió las claves API, los tokens OAuth, las cuentas de servicio y los secretos como objetos de seguridad fundamentales, lo cual es una perspectiva acertada. A simbólico En un repositorio, un secreto de CI/CD de larga duración o una cuenta de servicio con privilegios excesivos pueden resultar más útiles para un atacante que una contraseña introducida manualmente, ya que pueden eludir la autenticación multifactorial (MFA), las comprobaciones del estado de los dispositivos y los análisis del comportamiento habitual de los usuarios.
Hay un contraargumento que merece ser tenido en cuenta: no todas las identidades de máquina son un desastre en potencia. Muchas tienen permisos limitados, de corta duración y bien registrados. La crisis proviene de ese grupo intermedio no gestionado: identidades con amplios derechos, titularidad poco clara y sin fecha de caducidad, ya que se crearon bajo la presión de un plazo y luego se normalizaron.
La detección también requiere contexto. Una cuenta de servicio que consulte una tabla de clientes cada noche a las 02:00 puede no suponer ningún problema. Sin embargo, si esa misma cuenta exporta datos al mediodía, crea una nueva aplicación OAuth o realiza una llamada a una API externa desconocida, esto merece una atención inmediata.
Un modelo de gobernanza práctico para 2026
La gestión de identidades no humanas debería situarse entre la gestión de identidades y accesos (IAM), la seguridad en la nube, DevSecOps, la ingeniería de plataformas y la gobernanza de la IA. Si se asigna a un solo equipo, se dejará de lado la mitad del entorno. Los desarrolladores crean muchas de estas identidades, los equipos de la nube conceden permisos, el equipo de seguridad redacta las políticas y los responsables de negocio asumen el riesgo.
Haz que el ciclo de vida sea el eje central del modelo operativo. Cada nueva identidad de máquina debe tener un propósito, un responsable, unos límites de permisos, un comportamiento esperado, una fecha de revisión y un criterio de retirada del servicio. En el caso de los agentes de IA, añade un registro de la autoridad delegada, las herramientas aprobadas, las clases de datos permitidas y si el agente puede generar subagentes o ejecutar código.
Las credenciales de corta duración suelen ser mejores que los secretos de larga duración, pero no son la panacea. Si un agente puede generar nuevos accesos repetidamente sin comprobaciones significativas de las políticas, lo que has hecho es desplazar el riesgo en lugar de reducirlo. En este punto, resulta difícil defender cualquier NHI con privilegios elevados sin una supervisión continua y decisiones de acceso auditables.
Los informes dirigidos al consejo de administración deben evitar las métricas de vanidad. «Hemos detectado 400 000 identidades de máquinas» es algo interesante una vez. Entre las métricas recurrentes más adecuadas se incluyen el porcentaje de identidades con titular, el porcentaje de identidades con datos de último uso, el número de identidades privilegiadas obsoletas eliminadas, la mediana de antigüedad de las credenciales, los secretos de alto riesgo rotados y los agentes de IA con políticas documentadas de creación y eliminación.
La conclusión de CSA/Oasis de enero de 2026, según la cual el 78% de las organizaciones carece de políticas adoptadas formalmente para la creación o eliminación de identidades de IA, constituye una señal de alerta. La creación de identidades de IA es cada vez más sencilla. La eliminación de identidades de IA sigue siendo una tarea de gobernanza, y las tareas de gobernanza rara vez se llevan a cabo por casualidad.
Preguntas frecuentes
¿Qué es la gestión de identidades no humanas?
La gestión de identidades no humanas es el proceso de control de las identidades digitales que utilizan las aplicaciones, los servicios, las cargas de trabajo, las API, los bots, los dispositivos y los agentes de inteligencia artificial. Abarca la detección, la titularidad, los permisos, la rotación de credenciales, la supervisión y la eliminación.
¿Por qué hay más identidades no humanas que empleados?
Los entornos modernos de nube, SaaS, CI/CD y automatización crean identidades para prácticamente cada integración, carga de trabajo y conexión entre servicios. En 2026, la CSA citó estimaciones que oscilaban entre 96:1 en el sector de los servicios financieros y 144:1 en algunos entornos con un uso intensivo de la nube.
¿Son los agentes de IA identidades no humanas?
Sí. La documentación de Microsoft sobre Entra 2026 describe las identidades de los agentes como cuentas de identidad para agentes de IA, con patrones de autenticación distintos a los de los usuarios humanos. Necesitan sus propios permisos, propietarios, supervisión y reglas de eliminación.
¿Cuál es el mayor riesgo asociado a las identidades de las máquinas?
La filtración de información confidencial y el acceso con privilegios excesivos son dos de los mayores riesgos. La filtración de una clave API, un token OAuth o las credenciales de una cuenta de servicio puede permitir que un atacante actúe como un usuario de confianza sin necesidad de iniciar sesión manualmente.
¿Cómo se debería empezar a proteger las identidades no humanas?
Empieza por crear un inventario unificado vinculado al titular, la finalidad empresarial, el alcance de los privilegios, la fuente de creación y la fecha de último uso. A continuación, elimina las identidades obsoletas, renueva los secretos expuestos o antiguos, reduce los privilegios y supervisa el comportamiento de forma continua.
ES 
EN 
FR