Identidades No Humanas: 109 Cuentas de Máquina por Cada Empleado, y Nadie las Cuenta

Cuando una empresa audita su seguridad, casi siempre empieza por las personas: quién tiene acceso a qué, quién se ha ido y sigue con una cuenta activa, quién comparte contraseñas. Lo que casi nadie audita es lo que de verdad ha crecido sin control en los últimos dos años: las identidades que no son de ninguna persona. Claves de API, cuentas de servicio, tokens OAuth y, ahora, agentes de IA que actúan solos dentro de los sistemas de la empresa.

«Las identidades de máquina superan a las humanas en una proporción de 109 a 1.» — Identity Security Landscape 2026, Palo Alto Networks (antes CyberArk)

Ese dato no es una curiosidad técnica. Es el tamaño real de la superficie que hay que vigilar, y casi ninguna empresa sabe cuántas de esas 109 identidades por empleado siguen activas, para qué sirven o quién podría revocarlas hoy mismo si hiciera falta.

El número que no sale en la demo de ningún proveedor

El mismo informe de Palo Alto Networks, con datos de 2026, da tres cifras que conviene leer juntas:

• 109 identidades de máquina por cada persona en la empresa media — claves de API, cuentas de servicio, certificados, agentes de IA.
• 9 de cada 10 organizaciones sufrieron una brecha de seguridad relacionada con identidades en los últimos 12 meses.
• Cuando los sistemas de identidad están desconectados entre sí (lo habitual: un proveedor de IAM, otro de secretos, otro de nube), cada incidente tarda 12 horas más en resolverse solo por la fricción de cruzar datos entre herramientas que no se hablan.

Ninguna de las tres cifras depende de que la empresa use IA generativa de forma visible. Dependen de que cualquier sistema moderno —CRM, ERP, un simple script de automatización— ya necesita credenciales propias para hablar con otros sistemas. Lo que ha cambiado con los agentes de IA es la velocidad a la que se crean identidades nuevas: un agente que antes necesitaba una persona para configurarlo ahora se despliega solo, con su propia clave, en minutos.

Por qué los agentes de IA no son la causa, pero sí el acelerador

Aquí es donde el problema deja de ser teórico. GitGuardian, en su informe The State of Secrets Sprawl 2026 (basado en el rastreo de commits públicos de GitHub durante 2025), mide algo muy concreto: cuántas claves y contraseñas quedan escritas por error dentro del código, listas para que cualquiera las use.

• 28,65 millones de secretos nuevos quedaron expuestos en GitHub público en 2025 — un 34% más que el año anterior.
• Dentro de esa cifra, los secretos ligados a servicios de IA llegaron a 1.275.105, un salto del 81% interanual. El informe destaca un caso concreto: 113.000 claves de la API de DeepSeek expuestas públicamente.
• El dato más incómodo para cualquier equipo que ya usa un asistente de código con IA: los commits hechos con ayuda de Claude Code tuvieron una tasa de fuga de secretos del 3,2%, frente al 1,5% de referencia de todos los commits públicos — más del doble.
• Y el problema no se cierra solo: casi el 70% de las credenciales que eran válidas en 2022 seguían siéndolo en enero de 2025. Al repetir la comprobación en enero de 2026, seguía habiendo más de un 64% todavía activas, años después de haberse filtrado.

La lectura de negocio es sencilla: cada agente de IA que se pone en marcha, cada integración nueva, cada script «rápido» que un equipo técnico conecta a un proveedor de IA, deja detrás una credencial más. Y esa credencial, salvo que alguien la revoque a mano, sigue viva indefinidamente — válida, con los mismos permisos, años después de que el proyecto que la creó ya nadie lo recuerde.

No es lo mismo que «permisos de agentes» ni que «gobernanza de datos»

Es fácil confundir este problema con dos que ya hemos tratado en este blog, y conviene separarlos bien porque se arreglan de forma distinta:

• Permisos de agentes de IA es un problema de diseño: qué puede hacer un agente concreto, dentro de una tarea concreta, en el momento en que se configura.
• Gobernanza de datos para agentes es un problema de uso: qué datos toca ese agente mientras funciona, y si alguien puede cortarle el acceso en caliente.
• El inventario de identidades no humanas es anterior a los dos: es saber, simplemente, cuántas credenciales existen, para qué se crearon, si siguen haciendo falta y quién sería responsable de apagarlas. Sin ese inventario, diseñar permisos o vigilar el uso de datos se hace sobre una lista incompleta — se protege lo que se conoce y se deja fuera lo que ya nadie recuerda que existe.

La mayoría de empresas con las que hablamos tiene bien resuelto el segundo problema (controlan lo que ven) y casi ninguna tiene resuelto el primero (no saben cuánto hay que no ven).

Qué hacemos en Optima Quantum

Antes de diseñar o reforzar cualquier despliegue de agentes de IA, hacemos el trabajo que casi nadie hace primero: un inventario real de identidades no humanas — claves de API activas, cuentas de servicio, tokens de integración, credenciales de agentes — cruzado contra quién las usa hoy y desde cuándo. De ahí sale una lista con tres columnas: lo que hay que revocar ya, lo que hay que rotar, y lo que hay que vigilar porque sigue siendo necesario. Solo entonces tiene sentido hablar de permisos de agentes o de gobernanza de datos: sobre una base completa, no sobre la parte que ya se veía.

Si tu empresa ha desplegado agentes de IA, asistentes de código o integraciones nuevas en el último año y nadie ha hecho este inventario, probablemente tienes más credenciales activas de las que crees — y alguna, años después de crearse, sigue abierta. Puedes pedir una auditoría de seguridad gratuita o ver el resto de nuestros servicios de ciberseguridad, y contactar con nosotros para revisar tu caso concreto.

Relacionado: un agente de codificación con IA que tiene acceso a tu repositorio y a producción es, en sí mismo, una identidad no humana que conviene auditar — y el código que escribe tiene su propio riesgo: el 44% de las tareas de generación de código con IA sale con una vulnerabilidad real. Lo tratamos en el riesgo de seguridad del código generado por IA.

Preguntas frecuentes

¿Qué es exactamente una identidad no humana? Cualquier credencial que un sistema usa para autenticarse ante otro sin que haya una persona escribiendo la contraseña en ese momento: claves de API, cuentas de servicio, certificados, tokens OAuth y, cada vez más, las credenciales propias de un agente de IA.

¿Por qué 109 identidades de máquina por empleado y no una cifra menor? Porque cada sistema moderno —no solo la IA— necesita credenciales propias para hablar con otros sistemas: un CRM con el correo, una pasarela de pago con la contabilidad, un agente de IA con el calendario. Cada integración nueva suma identidades; casi ninguna se da de baja cuando deja de usarse.

¿Esto solo afecta a empresas que programan su propio software? No. Afecta a cualquier empresa que haya conectado un agente de IA, un asistente de atención al cliente o una automatización a sus sistemas internos, aunque no tenga un equipo de desarrollo propio: cada una de esas conexiones crea al menos una credencial nueva.

¿Qué pasa si no se revisa nunca? Las credenciales siguen activas de forma indefinida. Los datos de GitGuardian muestran que más del 64% de las credenciales filtradas sigue siendo válida años después — nadie las revocó porque nadie sabía que existían.

¿Cómo se empieza a arreglar? Con un inventario: localizar todas las credenciales no humanas activas, comprobar cuál sigue en uso y por quién, y decidir para cada una si se revoca, se rota o se vigila. Es el primer paso, antes de diseñar permisos de agentes o políticas de gobernanza de datos.