Identidades no humanas (NHI) y gestión de secretos 2026

Una identidad no humana (NHI, por sus siglas en inglés) es cualquier credencial o identidad con la que se autentica el software, no una persona: service accounts, claves de API, tokens OAuth, managed identities o roles. Son el mayor punto ciego de seguridad de 2026, y las cifras lo confirman: en el análisis H1 2025 de Entro Labs sobre 27 millones de identidades no humanas en entornos observados, el ratio fue de 144:1, frente a 92:1 en H1 2024. Mientras las organizaciones invierten en MFA, formación y gestión de contraseñas para sus empleados, un ejército silencioso de service accounts, claves de API y tokens opera con privilegios excesivos, credenciales de larga vida y prácticamente sin supervisión. Desde una perspectiva ofensiva, ese ejército es precisamente por donde entramos.

Qué son las identidades no humanas (NHI)

Una identidad no humana es cualquier credencial o identidad que autentica software, no personas. A diferencia de un usuario, una NHI no teclea una contraseña ni resuelve un segundo factor. Un punto clave que se suele malentender: NO toda NHI tiene un secreto persistente. La forma en que una NHI prueba quién es varía mucho. Algunas presentan un secreto estático (una clave de API o un token de larga vida). Otras (las managed identities, la federación de identidad de cargas de trabajo o workload identity federation y los roles asumibles) obtienen credenciales temporales bajo demanda sin almacenar nunca un secreto estático. Esta distinción es determinante, porque la medida más segura no es proteger mejor el secreto, sino eliminarlo. Las categorías principales que verás en cualquier auditoría son:

• Service accounts: cuentas de máquina en Active Directory, Entra ID, Google Workspace o sistemas Linux que ejecutan servicios, tareas programadas o procesos batch.
• Claves de API (API keys): cadenas estáticas que autentican una aplicación frente a un servicio (Stripe, AWS, GitHub, OpenAI). Son el tipo de secreto que más se filtra.
• Tokens OAuth y refresh tokens: credenciales que una app usa para actuar en nombre de un usuario o de sí misma frente a una API SaaS, sin volver a pedir login.
• Certificados y claves privadas: pares de clave usados en mTLS, firma de código y comunicación máquina a máquina.
• Secretos de infraestructura: credenciales de bases de datos, cadenas de conexión, tokens de Kubernetes, secretos de CI/CD.
• Credenciales de agentes de IA: el vector emergente. Cada agente autónomo, copiloto o pipeline de RAG necesita claves para llamar a modelos, bases de datos vectoriales y herramientas internas. En 2026 esta categoría crece más rápido que ninguna otra.

Si quieres el marco humano equivalente, nuestra guía sobre qué es IAM (gestión de identidades y accesos) cubre autenticación, autorización, RBAC y el stack empresarial. Las NHI son el hermano descuidado de ese modelo.

Por qué las NHI son el mayor punto ciego de 2026

El problema no es que existan las NHI, es que se gobiernan mal. Cuatro factores las convierten en el objetivo preferente de un atacante.

Superan en número a las identidades humanas

Con ratios que llegan a 144:1 en los entornos analizados por Entro Labs en H1 2025, mantener un inventario completo de las identidades de máquina es un reto real. Lo que no se inventaría no se protege. Cada microservicio nuevo, cada integración SaaS y cada agente de IA añade credenciales que rara vez se dan de baja. Este fenómeno tiene nombre: NHI sprawl.

Están sobreprivilegiadas

El 97% de las NHI tienen privilegios excesivos, según el 2025 State of Non-Human Identities. Una service account creada "para que funcione rápido" recibe un rol amplio (a menudo comodín) y nadie lo reduce nunca. En AWS esto se traduce en políticas IAM demasiado permisivas que permiten pivotar y escalar; lo analizamos en detalle en escalada de privilegios en AWS IAM. El principio de mínimo privilegio, tan predicado para humanos, casi nunca se aplica a máquinas.

Son de larga vida y no rotan

El 47% de las NHI tienen más de un año de antigüedad sin ninguna rotación de credenciales. Una clave de API generada en 2023 puede seguir válida hoy. A diferencia de una contraseña de usuario, que caduca o se cambia tras un incidente, muchos secretos de máquina viven de forma indefinida porque romperlos rompe producción. Esa permanencia es un regalo para el atacante.

No tienen MFA y apenas se monitorizan

Una NHI no puede resolver un segundo factor por diseño. Cuando autentica con un secreto persistente, toda la defensa recae en proteger ese secreto y en detectar su uso anómalo. Por eso la medida más segura, cuando la plataforma lo permite, es eliminar el secreto: sustituir claves estáticas por managed identities, federación de identidad de cargas de trabajo o roles que emiten credenciales de corta duración. Un secreto que no existe no se puede filtrar ni robar. Pero la actividad de una service account comprometida se parece a su actividad legítima, y raramente hay alertas para ello. Aquí es donde la filosofía Zero Trust resulta imprescindible: nunca confiar por defecto, ni siquiera en un proceso interno con una credencial válida.

Riesgos reales: cómo se explotan las credenciales de máquina

En Secra abordamos las credenciales de máquina como uno de los caminos más rentables en un ejercicio ofensivo. Estos son los patrones que vemos una y otra vez.

Secretos filtrados en Git, logs y contenedores

La superficie más grande y la más antigua. En 2025 se añadieron 28,65 millones de secretos hardcodeados a repositorios públicos de GitHub, un 34% más que el año anterior (GitGuardian). Y eso solo es lo público: en repos privados, historiales de commits, variables de entorno, ficheros .env, logs de aplicación y capas de imágenes Docker la densidad es aún mayor. Un git log -p o un simple grep sobre el historial suele devolver claves activas. El commit que "borra" la clave no la elimina: sigue en el historial.

Tokens robados que evaden MFA

Este es el cambio de paradigma de 2025-2026. Un token OAuth o de sesión ya autenticado no necesita pasar por el login, así que robarlo esquiva por completo el MFA. El atacante hereda el contexto autenticado y opera sin ver jamás una pantalla de acceso. A diferencia de los ataques contra humanos, como el MFA fatigue o push bombing, aquí no hay ninguna víctima a la que engañar: el token robado ya lo es todo. Según el Verizon DBIR 2025, en su subconjunto de ataques a Microsoft 365 orientados a sortear el MFA (dentro de los registros de contribuidores del informe), el robo de tokens representó el 31%.

El caso más sonado fue la brecha Salesloft-Drift de agosto de 2025: el grupo UNC6395 usó tokens OAuth robados de la integración Drift para acceder a más de 700 organizaciones de Salesforce, exfiltrar datos y buscar secretos de alto valor como claves de AWS y tokens de Snowflake. Ni una sola contraseña comprometida, ni un solo MFA vencido: solo tokens de máquina válidos usados por quien no debía. Si tu modelo mental de defensa sigue centrado en el login, entiende por qué la MFA resistente al phishing protege el acceso humano pero no salva a una NHI cuyo token ya circula.

Movimiento lateral y encadenamiento

Un secreto filtrado rara vez es el objetivo final: es la primera ficha del dominó. Una clave de CI/CD da acceso al pipeline, el pipeline tiene una service account con permisos en cloud, esa cuenta puede leer un secret manager, y ahí están las credenciales de la base de datos de producción. El encadenamiento de NHI sobreprivilegiadas es lo que convierte una fuga menor en una brecha total. Estos secretos también son la puerta a los ataques a la cadena de suministro de software, cuando el secreto comprometido pertenece a un proveedor o a una dependencia.

Abuso de tokens de API

Las APIs modernas dependen de tokens (JWT, bearer tokens, claves) para autenticar cada llamada. Un token mal validado, sin expiración o con scope excesivo es explotable directamente. Entender cómo se firman y validan estos tokens es clave: nuestra guía de seguridad en JWT detalla los fallos habituales (algoritmo none, secretos débiles, ausencia de rotación de firma), y en pentesting de APIs REST y GraphQL mostramos cómo se abusan estos tokens en la práctica.

Cómo gestionar las NHI: bóveda, rotación y mínimo privilegio

La buena noticia es que el gobierno de NHI es un problema resoluble con disciplina. Este es el programa que recomendamos, en orden de eficacia.

Elimina el secreto persistente (la medida más segura)

Antes que pensar en bóveda o rotación, pregúntate si el secreto necesita existir. En la mayoría de plataformas cloud modernas, no. Las managed identities (Azure), los roles de IAM asumibles (AWS) y las service accounts con identidad federada (Google Cloud) permiten que una carga de trabajo se autentique sin almacenar ninguna clave estática: la plataforma emite credenciales temporales de corta duración y las revoca sola. La federación de identidad de cargas de trabajo (workload identity federation) extiende esto a CI/CD y a cargas fuera del cloud, que intercambian un token de confianza por credenciales efímeras en lugar de guardar una clave de larga vida. Es el mismo principio de confianza federada que sustenta el inicio de sesión con SAML para humanos, llevado al plano máquina a máquina. Un secreto que no existe no se puede filtrar en Git, ni robar de un log, ni reutilizar meses después. Esta debe ser siempre la primera opción; la bóveda y la rotación son para los secretos que, por limitaciones técnicas, no puedes eliminar todavía.

Bóveda de secretos (secrets vault)

Ningún secreto debe vivir en código, en un fichero de configuración ni en una variable de entorno persistente. Céntralo todo en una bóveda: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault o Google Secret Manager. La aplicación pide el secreto en tiempo de ejecución, con acceso auditado, y nunca lo almacena en disco. El objetivo final son los secretos dinámicos: credenciales de vida corta que la bóveda genera bajo demanda y revoca automáticamente.

Rotación automática

Un secreto que no rota es una bomba de relojería. Automatiza la rotación de claves de API, contraseñas de service accounts y certificados con periodicidad corta. Si rotar un secreto rompe un servicio, ese acoplamiento es en sí mismo el problema a resolver. La rotación limita drásticamente la ventana de utilidad de una credencial robada.

Mínimo privilegio para máquinas

Aplica a cada NHI el permiso exacto que necesita, nada más. Nada de roles comodín, nada de Administrator "por si acaso". Revisa periódicamente los permisos y retira los que no se usan. Las herramientas de análisis de accesos de los cloud providers muestran qué permisos concedidos nunca se ejercen: esos son los primeros que hay que eliminar.

Detección de secretos (secret scanning)

Integra escaneo de secretos en el flujo de desarrollo: pre-commit hooks que bloqueen el commit antes de que el secreto entre en el historial, escaneo continuo del repositorio y de las imágenes de contenedor, y monitorización de repos públicos por si algo se filtra fuera. Herramientas como GitGuardian, TruffleHog o el secret scanning nativo de GitHub cubren estas capas. Este control es parte esencial de una cultura DevSecOps madura.

Gobierno de NHI: inventario y ciclo de vida

Todo empieza por el inventario. No puedes gobernar lo que no ves. Descubre todas las NHI de tu entorno, asígnales un propietario humano responsable, documenta para qué sirven y establece un ciclo de vida completo: alta, revisión periódica y baja. Una NHI sin propietario y sin uso reciente debe desactivarse. Es la misma disciplina de gobernanza de identidades que aplicamos a los humanos con IGA, extendida por fin a las máquinas.

Detección de anomalías en tiempo de ejecución

Como una NHI comprometida se comporta casi igual que una legítima, la detección exige contexto: ¿por qué esa service account accede a un recurso nuevo?, ¿por qué ese token OAuth conecta desde una IP o país inusual?, ¿por qué el volumen de llamadas se multiplica de golpe? Establecer una línea base de comportamiento por cada NHI y alertar sobre las desviaciones es lo que habría acortado la ventana de la brecha Salesloft-Drift.

NHI, Zero Trust y el nuevo perímetro

La identidad es el nuevo perímetro, y en 2026 esa identidad es mayoritariamente no humana. Un modelo Zero Trust que solo verifica humanos está incompleto: cada servicio, cada agente y cada llamada de API debe autenticarse con una identidad fuerte, autorizarse con mínimo privilegio y estar sujeto a verificación continua. Las mismas tres preguntas de Zero Trust (¿quién eres?, ¿qué puedes hacer?, ¿sigues comportándote como deberías?) aplican íntegras a una service account o a un agente de IA.

Con la explosión de la IA agéntica, este problema no hará más que crecer. Cada agente autónomo es una NHI con acceso a datos y herramientas, y a menudo con capacidad de actuar sin supervisión humana en el bucle. Gobernar sus credenciales, limitar sus permisos y auditar sus acciones es la frontera de la seguridad de identidad para los próximos años. Los secretos que estos agentes manejan son, además, un objetivo directo para malware de robo de credenciales como los infostealers, que ya no buscan solo contraseñas humanas sino también tokens y claves de sesión.

Preguntas frecuentes

¿Qué diferencia hay entre una identidad humana y una identidad no humana?

Una identidad humana pertenece a una persona que se autentica de forma interactiva, normalmente con contraseña más un segundo factor (MFA). Una identidad no humana (NHI) es un principal asignado a una carga de trabajo, servicio, aplicación, dispositivo o automatización, no a una persona, y opera sin intervención humana ni MFA. Cómo prueba quién es depende de mecanismos de autenticación separados de la propia identidad: puede presentar un secreto (una clave de API o un token), un certificado o tokens efímeros, o autenticarse sin secreto estático mediante managed identities, federación de identidad de cargas de trabajo o roles asumibles. Las NHI suelen ser más numerosas, más privilegiadas, de vida más larga y mucho menos monitorizadas que las humanas.

¿Por qué un token OAuth robado evade el MFA?

Porque el MFA se comprueba durante el proceso de login, y un token OAuth ya representa una sesión autenticada posterior a ese login. Si un atacante roba un token válido (de un log, de una integración comprometida o de la memoria de un equipo), lo presenta directamente a la API y hereda el contexto autenticado sin pasar de nuevo por el acceso. Por eso la defensa se traslada a proteger, acortar la vida y monitorizar el uso de los tokens, no solo a reforzar el login.

¿Qué es una bóveda de secretos y por qué la necesito?

Una bóveda de secretos (secrets vault) es un sistema centralizado y cifrado que almacena credenciales de máquina y las entrega a las aplicaciones en tiempo de ejecución, con acceso auditado y, en el mejor caso, con secretos dinámicos de vida corta. La necesitas para que ningún secreto viva en código, ficheros de configuración o logs, donde acaba filtrándose. Ejemplos: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault y Google Secret Manager.

¿Cada cuánto debo rotar las credenciales de máquina?

Cuanto más corto, mejor. Lo ideal son secretos dinámicos de vida efímera generados bajo demanda. Cuando no sea posible, rota claves de API, contraseñas de service accounts y certificados de forma automática y periódica (semanas, no años). Recuerda que el 47% de las NHI llevan más de un año sin rotar: ese es exactamente el estado que un atacante espera encontrar.

¿Cómo empiezo a gobernar las NHI si no tengo ninguna visibilidad?

Empieza por el descubrimiento e inventario. Localiza todas las identidades de máquina de tu entorno (cloud, on-premise, SaaS, CI/CD), asigna a cada una un propietario humano y documenta su función. A partir de ahí, prioriza por riesgo: primero las sobreprivilegiadas y de larga vida, aplica mínimo privilegio, activa la rotación y despliega escaneo de secretos. Un ejercicio de red team ayuda a validar qué NHI son realmente explotables antes que un atacante lo descubra.

Pon a prueba tus identidades no humanas

En Secra evaluamos las NHI desde la perspectiva de quien las ataca: buscamos secretos filtrados, permisos excesivos y tokens explotables antes de que lo haga un adversario real. Si quieres saber qué credenciales de máquina exponen tu organización, descubre nuestro servicio de pentesting o contacta con nuestro equipo para diseñar una evaluación a medida.