Una encuesta a 2.900 líderes de seguridad revela que la mayoría de las organizaciones otorga privilegios permanentes a cuentas automatizadas que nadie supervisa ni puede desactivar sin riesgo.
Palo Alto Networks relevó más de 2.900 líderes de seguridad para su reporte 2026 Identity Security Landscape y encontró un promedio de 109 identidades de máquina por cada identidad humana en las organizaciones encuestadas. El dato más preocupante no es la proporción en sí — que varía según cómo cada proveedor cuente identidades — sino que el 61% de las solicitudes de acceso privilegiado todavía se resuelven otorgando permisos permanentes en lugar de credenciales bajo demanda que expiren después de cada tarea. Entro Labs agregó otra dimensión al problema: cerca del 50% de esas identidades tienen más de un año de antigüedad, y el 7.5% lleva entre cinco y diez años activas, muchas veces sin un responsable claro que pueda justificar su existencia o desactivarlas sin romper algo en producción.
La cuenta de servicio que nadie recuerda haber creado
El escenario típico es una cuenta de servicio configurada para un proceso de migración o un batch nocturno de finanzas. El ingeniero que la creó dejó la empresa hace años. La contraseña quedó en un vault corporativo — o peor, en un archivo de configuración en texto plano — y nadie se anima a tocarla porque los permisos que tiene son más amplios de lo necesario y nadie entiende completamente qué rompería si se desactiva. Ese patrón, multiplicado por decenas o cientos de cuentas similares, explica por qué la rotación de credenciales sigue siendo la única medida de control que muchas organizaciones aplican a identidades no humanas.
La rotación cambia el secreto pero deja intactos los permisos. Entre un cambio y el siguiente — típicamente cada 90 días — la credencial sigue válida con acceso completo, legible desde donde sea que la aplicación la recupere. Si un atacante la copia en los primeros días del ciclo, tiene casi tres meses para usarla sin que nadie note actividad anómala. Las integraciones OAuth empeoran el problema: un refresh token puede seguir renovándose indefinidamente, mucho después de que alguien recuerde haberlo autorizado.
Cómo UNC6395 usó tokens legítimos para robar datos de 700 organizaciones
La campaña Salesloft Drift de agosto de 2025 ilustra el riesgo con precisión. Google Threat Intelligence Group atribuyó el ataque al actor UNC6395, que usó tokens OAuth y refresh tokens robados vinculados a la integración Drift para extraer datos de instancias de Salesforce entre el 8 y el 18 de agosto. Más de 700 organizaciones fueron afectadas. Como los tokens eran legítimos y no había ninguna persona iniciando sesión, no se disparó ningún prompt de autenticación multifactor ni nada que la capa de autenticación pudiera marcar como inusual. Muchas de las organizaciones afectadas probablemente no podían nombrar quién en su equipo había aprobado esa integración originalmente.
Salesloft vinculó el acceso inicial a un compromiso de su cuenta GitHub en marzo de 2025, meses antes de que comenzara el robo de datos. Los clientes afectados recibieron instrucciones de buscar en sus registros de Salesforce secretos como claves de AWS y tokens de Snowflake, porque los casos de soporte son un lugar común donde el personal pega credenciales mientras resuelve problemas. En otras palabras: el token permanente robado se usó para buscar más tokens permanentes en otros sistemas.
Por qué América Latina queda expuesta por dependencia de integraciones SaaS sin auditoría
El reporte de Palo Alto Networks no desglosa datos por región, pero la estructura del problema afecta especialmente a organizaciones en México, Brasil, Colombia y Argentina que adoptaron plataformas SaaS de forma acelerada en los últimos cinco años — muchas veces sin equipos de seguridad con capacidad para auditar integraciones OAuth o revisar scopes de acceso. La práctica común en la región es que equipos de negocio aprueben integraciones con scopes amplios sin intervención de seguridad, y esas autorizaciones quedan activas indefinidamente. En sectores como fintech y retail, donde Salesforce y HubSpot son infraestructura crítica, un token comprometido puede dar acceso a bases de datos completas de clientes sin que se dispare ninguna alerta, porque el acceso es técnicamente legítimo.
Qué significa zero standing privilege para una identidad de máquina
Con zero standing privilege, una identidad de máquina no mantiene acceso utilizable mientras está inactiva. Cuando tiene trabajo que hacer, presenta prueba de identidad a un motor de políticas y recibe una credencial de corta duración limitada a esa tarea específica, que expira automáticamente cuando el trabajo termina. La mayoría de las organizaciones ya implementa algo similar para personas a través de elevación just-in-time en plataformas PAM. Para workloads, el camino típico es workload identity federation: el workload presenta un token firmado por una plataforma que el destino ya confía — como un cluster Kubernetes o un pipeline CI — y lo intercambia por acceso temporal.
El caso más claro es GitHub Actions desplegando en AWS. El pipeline solicita un token OIDC a GitHub, AWS lo verifica contra una política de confianza vinculada a ese repositorio, y el job corre bajo un rol cuyas credenciales duran alrededor de una hora por defecto. Ninguna access key se almacena en el repositorio en ningún momento. Google recomienda federación sobre claves de cuenta de servicio exportadas por la misma razón: esas claves son de larga duración y requieren el mismo cuidado que una contraseña.
Nuestro análisis
El patrón que revela este reporte es que la mayoría de las organizaciones trasladó controles de gestión de identidad privilegiada a usuarios humanos en la última década — PAM, MFA, revisión de accesos — pero dejó las identidades de máquina con las mismas prácticas de hace diez años: un vault, un ciclo de rotación, y la esperanza de que nadie las comprometa entre un cambio y el siguiente. La campaña Salesloft Drift demuestra que esa esperanza no es una estrategia: un token OAuth legítimo robado meses después de su emisión puede operar sin restricciones hasta que alguien note el robo, y para ese momento el atacante ya movió los datos. Lo que todavía no se sabe es cuántas de las 700 organizaciones afectadas tenían capacidad de auditar qué integraciones OAuth estaban activas antes del incidente, o cuántas pueden nombrar hoy un responsable humano por cada cuenta de servicio con acceso a producción.
Zero standing privilege completo para todas las identidades de máquina no es alcanzable en la mayoría de las empresas hoy — aplicaciones legacy que autentican con usuario y contraseña en bases de datos no van a federar, y muchos appliances de proveedores solo aceptan claves API estáticas — pero near-zero standing privilege sí es un objetivo realista si se empieza por un inventario completo con un dueño humano asignado a cada credencial. La pregunta que queda es cuántas organizaciones van a esperar su propio incidente tipo Salesloft antes de hacer ese inventario, y cuánto va a costar descubrir que nadie puede nombrar quién aprobó las integraciones que están moviendo datos ahora mismo.