La investigación de Unit 42 sobre identidades en la nube expone los límites de la seguridad basada en permisos

Unit 42 analizó más de 40.000 identidades en la nube y reveló un conflicto que las revisiones de permisos por sí solas no pueden resolver. La investigación de Unit 42 sobre identidades en la nube sostiene que los equipos de seguridad deben comprender qué hace realmente una identidad, no solo qué puede hacer.

Publicado el 14 de septiembre de 2026, el estudio mapea la actividad de 125 entornos en la nube durante un periodo de observación de dos meses. Su modelo agrupa las identidades según las operaciones registradas en AWS CloudTrail. Esos grupos corresponden a roles reconocibles, incluidos administradores, agentes de respaldo, herramientas de seguridad, usuarios de DevOps y sistemas de entrega continua.

La disputa central es la inferencia de roles mediante el comportamiento frente a las etiquetas estáticas de identidad. Un nombre confiable, una política conocida o una credencial legítima pueden mantenerse después de que un atacante cambie el propósito de la identidad. Unit 42 propone convertir el comportamiento observado en contexto de rol y, posteriormente, utilizar las desviaciones de ese contexto para mejorar la detección automatizada.

Unit 42 mapeó las identidades según sus acciones, no sus nombres

La investigación transforma el análisis de identidades al tratar la actividad de las API como evidencia del rol operativo de una identidad.

La investigación sobre identidades conductuales parte de un problema práctico. Los entornos en la nube ahora incluyen empleados, aplicaciones, pipelines de despliegue, productos de seguridad y agentes autónomos. Sus nombres y permisos asignados suelen revelar poco sobre su función actual.

Una identidad llamada “backup” podría leer legítimamente un bucket de almacenamiento cada noche. Más tarde, esa misma identidad podría enumerar usuarios, inspeccionar políticas o crear recursos de cómputo. Esas acciones importarían incluso si su nombre y sus permisos permanecieran sin cambios.

Unit 42 representó cada identidad mediante las operaciones de AWS que invocó durante el periodo de estudio. Luego, los investigadores compararon esos perfiles conductuales entre los entornos participantes. Combinaciones similares de operaciones reunieron a las identidades en grupos distintos.

El mapa resultante incluyó 30 grandes clústeres que representaban aproximadamente 20.000 identidades. Los investigadores asociaron esos clústeres con funciones recurrentes como administración, automatización de infraestructura, redes, seguridad, respaldo, FinOps y servicios de datos.

El clúster administrativo ofreció el ejemplo más claro. Contenía cerca de 5.000 identidades en más de 100 proyectos en la nube. Aproximadamente el 94 por ciento de sus identidades generó eventos ConsoleLogin, frente a menos del 1 por ciento en otros clústeres.

Alrededor del 60 por ciento también invocó operaciones asociadas con la actividad normal de la consola, incluidas GetCostAndUsage y GetCostForecast. Estas operaciones ayudaron a distinguir a los administradores interactivos de las identidades de máquina que utilizan un conjunto más limitado de API.

Esta evidencia importa porque ningún evento individual establece la intención. ConsoleLogin indica un inicio de sesión interactivo, pero no demuestra que el usuario sea administrador. Las solicitudes de gestión de costos podrían producirse automáticamente cuando se carga la consola.

Unit 42 combinó cuatro formas de análisis para evitar depender de una única señal conveniente. Examinó la frecuencia de las operaciones, las operaciones distintivas, los atributos de identidad y los patrones de nombres repetidos dentro de cada clúster.

Un patrón de nombres fue especialmente revelador. AWS IAM Identity Center crea un prefijo reconocible cuando AdministratorAccess se asigna mediante su conjunto de permisos estándar. El prefijo apareció con frecuencia dentro del clúster administrativo, respaldando la interpretación conductual.

Los nombres fueron evidencia de apoyo, no la base del modelo. Esta distinción evita que el método simplemente redescubra las etiquetas ya asignadas a las identidades. También hace que el enfoque sea más útil cuando los nombres son ambiguos, están desactualizados o son deliberadamente engañosos.

La investigación no anuncia una brecha o vulnerabilidad recién observada. Presenta un diseño de detección construido a partir de telemetría operativa real. Su valor informativo proviene de hacer que la clasificación de identidades en la nube sea más escalable y explicable.

La mayoría de los inventarios de identidades responden quién posee una credencial y qué acciones permite su política. Unit 42 añade una tercera pregunta: ¿qué rol funcional revela la actividad de la identidad? Esta capa adicional crea la tensión que impulsa todo el estudio.

Los permisos estáticos dejan abierta la pregunta más importante

Un permiso indica a los defensores qué es posible, mientras que el comportamiento revela qué capacidades está ejerciendo ahora una identidad.

Las políticas de gestión de identidades y accesos siguen siendo esenciales. Determinan si un principal puede leer un secreto, iniciar una instancia, modificar el registro o asumir otro rol. El principio de mínimo privilegio reduce el daño que puede ocasionar una credencial comprometida.

Sin embargo, el análisis de políticas no puede describir por completo la realidad operativa. Las organizaciones conceden con frecuencia accesos amplios para evitar bloquear despliegues o trabajos de emergencia. Los roles antiguos también acumulan permisos a medida que cambian los proyectos, equipos y responsabilidades.

Algunas identidades con privilegios excesivos operan de forma inocua durante años. Otras se convierten en valiosos puntos de entrada tras el robo de credenciales. El documento de permisos parece riesgoso en ambos casos, pero no puede mostrar qué identidad ha empezado a actuar fuera de su función establecida.

El contexto conductual aporta esa distinción faltante. Un proceso de respaldo que accede repetidamente a un destino protegido genera una línea base estrecha. La enumeración de recursos, el descubrimiento de identidades o los cambios administrativos representarían una desviación significativa de esa línea base.

La misma llamada a una API puede implicar un riesgo diferente en otro contexto. ListBuckets podría ser esperable en un producto de inventario de seguridad. Merecería una atención más estrecha si procede de una carga de trabajo que históricamente ha escrito registros de aplicaciones en un solo bucket.

Por eso la investigación de Unit 42 sobre identidades en la nube presiona a los programas de seguridad centrados únicamente en la postura. La gestión de la postura de seguridad en la nube identifica permisos excesivos y problemas de configuración. No explica automáticamente si las acciones observadas corresponden al trabajo real de una identidad.

Los atacantes se benefician de esa brecha. Pueden utilizar credenciales existentes, políticas heredadas y nombres de recursos que parecen inofensivos. Su actividad aparece entonces bajo una identidad que los equipos de seguridad ya reconocen.

La suplantación no requiere cambiar el nombre de la cuenta. Un atacante solo necesita realizar operaciones maliciosas mediante una identidad que los defensores consideran confiable. Los inventarios estáticos pueden conservar esa confianza después de que el comportamiento haya cambiado.

AWS ya aplica análisis conductual en su servicio gestionado de detección de amenazas. Según su documentación sobre detección de anomalías, GuardDuty perfila campos de eventos de CloudTrail para identificar actividad anómala o no autorizada.

GuardDuty también considera factores como la identidad solicitante, la API y la ubicación. Sus hallazgos pueden identificar actividades asociadas con acceso a credenciales, descubrimiento, persistencia, escalada de privilegios, exfiltración e impacto.

Esa capacidad existente valida la dirección general, pero no elimina la contribución de Unit 42. Las detecciones gestionadas normalmente presentan hallazgos después de que los modelos y reglas de un proveedor identifican actividad sospechosa. Los clientes tienen una visibilidad limitada sobre la línea base exacta o el proceso de clasificación.

Unit 42 se centra en asignar un rol funcional que los defensores puedan comprender y reutilizar. El modelo pregunta si una identidad se comporta como un administrador, un sistema de despliegue, un escáner o un servicio de respaldo. Ese rol puede enriquecer las detecciones posteriores.

La distinción también cambia la clasificación inicial de alertas. Una llamada a una API desconocida no es automáticamente maliciosa, y una llamada común a una API no es automáticamente inocua. Los analistas deben comparar la acción con la función esperada de la identidad.

Esto genera presión sobre los proveedores de seguridad en la nube, los equipos internos de detección y las plataformas de gobierno de identidades. Todos deben conectar los datos de autorizaciones con la actividad en tiempo de ejecución. Un producto que expone solo una parte obliga a los analistas a reconstruir manualmente la otra.

La presión aumenta a medida que se multiplican las identidades no humanas. Las cargas de trabajo, los sistemas de CI/CD, las cuentas de servicio, las herramientas de automatización y los agentes de IA pueden actuar continuamente. Su volumen de comportamiento hace impracticable la clasificación manual.

La respuesta de Unit 42 no es descartar los permisos. Es combinar las capacidades permitidas con las operaciones observadas. Ambas perspectivas responden preguntas diferentes y se vuelven más útiles cuando se evalúan conjuntamente.

Cómo funciona el clustering de identidades en la nube de Unit 42

Unit 42 utiliza clustering no supervisado para descubrir roles conductuales y luego condensa esos hallazgos en clasificadores más simples.

La primera etapa comienza con registros de auditoría en la nube. AWS CloudTrail registra eventos generados por usuarios, roles y servicios, incluida la identidad y la API involucradas. AWS explica estos campos en su referencia de eventos de CloudTrail.

Unit 42 convierte cada identidad en un vector booleano. Cada posición representa una operación disponible, mientras que verdadero o falso registra si la identidad invocó esa operación durante la ventana de observación.

Esto produce un conjunto de datos difícil. AWS expone más de 15.000 operaciones posibles en aproximadamente 240 servicios, según la investigación. La mayoría de las identidades invoca solo un subconjunto pequeño, lo que genera vectores grandes y mayormente vacíos.

El pipeline utiliza Uniform Manifold Approximation and Projection, o UMAP, para reducir esos vectores. UMAP convierte observaciones de alta dimensionalidad en representaciones más pequeñas, al tiempo que intenta preservar una estructura de vecindad significativa.

Los investigadores utilizaron la similitud del coseno como medida de distancia. Esta medida compara la dirección de dos vectores en lugar de su magnitud absoluta. Destaca qué operaciones comparten las identidades, en vez de favorecer a la identidad que generó más actividad.

Una ejecución de UMAP creó representaciones densas que contenían 32 valores continuos. Una ejecución independiente proyectó las identidades en dos dimensiones para su visualización. Estos dos resultados tienen propósitos distintos y no deben tratarse como intercambiables.

La representación densa pasa luego a HDBSCAN, un método de clustering que identifica regiones con alta densidad de puntos. A diferencia de los algoritmos que requieren un número fijo de grupos, HDBSCAN puede descubrir clústeres y marcar puntos inusuales como ruido.

Ambos métodos tienen fundamentos establecidos en la investigación. El artículo original de UMAP describe la técnica de reducción de dimensionalidad, mientras que el artículo sobre HDBSCAN aborda el clustering jerárquico basado en densidad.

Una vez que las identidades reciben asignaciones de clúster, los analistas aún deben interpretar cada grupo. Un identificador de clúster no llega con una etiqueta que diga “administrador” o “servicio de respaldo”. Por ello, la investigación aplica múltiples pruebas para inferir su rol.

La frecuencia de operaciones muestra qué API aparecen en todo un clúster. Un método de puntuación basado en clases identifica operaciones que ocurren con frecuencia dentro de un grupo, pero siguen siendo poco comunes en otros lugares. Esto separa las API meramente populares de las señales realmente distintivas.

El mapeo de atributos añade otra perspectiva. Los investigadores pueden destacar identidades que utilizan determinados servicios, invocan operaciones específicas o contienen cadenas recurrentes. Los atributos concentrados aportan evidencia para una etiqueta funcional propuesta.

Finalmente, la minería de subcadenas identifica fragmentos repetidos entre nombres de identidades. Esto puede revelar convenciones creadas por sistemas de despliegue o productos de gestión de identidades. Es más seguro que declarar un rol basándose únicamente en el nombre de una identidad.

En conjunto, estos métodos convierten un patrón visual en una categoría de comportamiento interpretable. Esa interpretación sigue siendo un juicio analítico, pero se apoya en varias formas de evidencia.

Por tanto, el enfoque de agrupación de identidades en la nube de Unit 42 no es un decodificador mágico de identidades. Es un proceso estructurado para encontrar patrones operativos repetidos. El análisis humano sigue conectando esos patrones con funciones organizativas reales.

Esa limitación también es una fortaleza. Los equipos de seguridad pueden examinar por qué un grupo recibió una etiqueta. Pueden comprobar si las operaciones distintivas coinciden con su propio entorno antes de utilizar la clasificación en producción.

El proceso se parece a la cartografía exploratoria. El aprendizaje no supervisado dibuja el mapa sin recibir una lista predefinida de roles. Después, los analistas identifican qué regiones corresponden a comportamientos operativos conocidos.

Sin embargo, ejecutar repetidamente todo el proceso de mapeo introduciría costes computacionales y operativos. También podría producir identificadores de grupos cambiantes a medida que varían los conjuntos de datos y los parámetros. Unit 42 aborda ese problema en la siguiente etapa.

El verdadero avance es el camino de los modelos a SQL

El paso más importante desde el punto de vista operativo es destilar los grupos descubiertos en reglas pequeñas e interpretables que los sistemas de datos existentes puedan ejecutar.

Después de identificar un grupo útil, Unit 42 entrena un clasificador de regresión logística usando los vectores booleanos originales de operaciones. La regresión logística calcula cómo las características individuales modifican la probabilidad de que una observación pertenezca a una clase determinada.

Un equipo podría entrenar un clasificador para el comportamiento de administrador y otro para herramientas de seguridad. Las nuevas identidades se evaluarían entonces frente a los modelos pertinentes sin reconstruir el mapa completo de comportamiento.

Unit 42 también aplica regularización L1. Esta penalización empuja hacia cero los coeficientes de características poco útiles. Las operaciones restantes forman un conjunto mucho menor de indicadores positivos y negativos.

Esa dispersión es importante para las operaciones de seguridad. Un modelo con miles de características interrelacionadas sería difícil de inspeccionar, explicar o reproducir. Un clasificador basado en varias decenas de operaciones ponderadas es mucho más fácil de operacionalizar.

Los analistas pueden ver qué llamadas API acercan una identidad a una clasificación de administrador. También pueden ver qué operaciones la alejan. Esa visibilidad facilita la revisión antes de que la lógica afecte a las alertas.

Los investigadores afirman que esta lógica ponderada puede expresarse mediante consultas SQL estándar. La mayoría de las organizaciones de seguridad ya centralizan los registros en la nube en almacenes de datos, lagos de datos de seguridad o plataformas analíticas. SQL reduce la barrera de despliegue.

Esto no significa que desaparezca todo el flujo de trabajo de aprendizaje automático. La etapa original de agrupación sigue descubriendo grupos significativos y proporcionando etiquetas de entrenamiento. El clasificador ligero es una aproximación local de ese análisis previo.

La distinción protege al artículo de una conclusión engañosa. Unit 42 no redujo todos los problemas de seguridad en la nube a una sentencia SQL. Mostró cómo un límite de clasificación aprendido puede convertirse en una lógica de consulta transparente.

Este diseño presenta un compromiso práctico entre el aprendizaje automático a medida y las reglas rígidas escritas manualmente. Las detecciones totalmente manuales dependen de que los analistas anticipen de antemano las combinaciones relevantes. Los modelos complejos pueden ser costosos y difíciles de explicar.

La agrupación por comportamiento descubre patrones candidatos a partir de datos observados. Los clasificadores dispersos conservan después los patrones seleccionados en un formato inspeccionable. Los equipos de detección obtienen contexto reutilizable sin mantener continuamente el proceso exploratorio.

Consideremos el ejemplo del servicio de copias de seguridad. Un clasificador podría reconocer operaciones asociadas con actividad periódica de respaldo y asignar un rol funcional. La lógica de detección puede entonces tratar el descubrimiento administrativo o los cambios de políticas como comportamientos incompatibles con ese rol.

La alerta es más sólida porque describe una discrepancia, no solo un evento poco frecuente. “La identidad de respaldo realizó comportamiento de administrador” aporta a un analista más contexto que “se observó una API inusual”. Conecta la línea base del actor con la acción sospechosa.

El mismo enfoque podría servir para sistemas de CI/CD. Las identidades de despliegue suelen realizar operaciones recurrentes de infraestructura en servicios predecibles. El abuso de credenciales podría introducir actividad de consola, descubrimiento amplio o acceso a datos no relacionados.

Los productos de seguridad representan otra categoría útil. Enumeran recursos e inspeccionan configuraciones con regularidad. Sin contexto de rol, esas acciones pueden parecer reconocimiento de un atacante y generar ruido evitable.

Por tanto, la clasificación funcional puede reducir dos errores distintos. Puede disminuir los falsos positivos cuando un acceso amplio coincide con un escáner conocido. Puede aumentar la sospecha cuando una automatización con propósito limitado empieza a comportarse como un administrador.

Aquí es donde la inferencia de roles por comportamiento compite más directamente con el etiquetado estático. Un nombre como “security-scanner” pide a los analistas que confíen en la configuración. Un patrón observado les proporciona evidencia de que la identidad continúa realizando esa función.

El método también complementa el análisis de permisos. Un escáner de seguridad puede comportarse normalmente y, aun así, conservar privilegios excesivos. Las herramientas de postura deben seguir informando de esa exposición, incluso cuando las detecciones en tiempo de ejecución no encuentren nada sospechoso.

A la inversa, una identidad con permisos estrictamente limitados aún puede comportarse de forma inesperada dentro de su ámbito permitido. La supervisión del comportamiento debería marcar ese cambio, incluso cuando una revisión de políticas no detecte ninguna infracción.

Por tanto, el modelo crea una capa de datos adicional, no un control sustitutivo. Los permisos definen límites. La agrupación infiere roles. La lógica de detección identifica desviaciones que merecen investigación.

Unit 42 afirma que la metodología puede extenderse más allá de AWS CloudTrail a otros proveedores de nube, Kubernetes y servicios de software. Esta extensión es plausible porque estos sistemas también generan eventos de auditoría vinculados a identidades.

Sin embargo, la portabilidad exige una nueva validación. Azure, Google Cloud, Kubernetes y las plataformas SaaS exponen vocabularios de eventos y estructuras de identidad diferentes. Un clasificador entrenado con operaciones de AWS no puede transferirse sin cambios.

Lo que la investigación aún no demuestra

El conjunto de datos demuestra grupos de comportamiento coherentes, pero no establece una precisión de detección universal entre organizaciones, proveedores o cargas de trabajo cambiantes.

Unit 42 informa de una escala considerable, incluidas más de 40.000 identidades y 125 entornos. Esa amplitud respalda la afirmación de que aparecen roles de comportamiento repetidos en múltiples infraestructuras de nube. No responde a todas las preguntas de producción.

La publicación no proporciona una evaluación comparativa completa con precisión, recall, tasas de falsos positivos y rendimiento en todos los roles identificados. Afirma que la regresión logística puede identificar con precisión determinados grupos, pero los lectores públicos no pueden reproducir de forma independiente todos los resultados.

El estudio también se centra en una ventana de observación de dos meses. Ese período captura operaciones recurrentes, pero algunas identidades legítimas actúan únicamente durante pruebas trimestrales de recuperación, migraciones o respuesta a incidentes. Las líneas base cortas pueden clasificar erróneamente trabajo poco frecuente pero autorizado.

Los vectores booleanos introducen otra compensación. Conservan si una operación ocurrió, pero omiten la frecuencia con la que sucedió. Una identidad que llama a una API una vez parece idéntica en esa característica a otra que la llama miles de veces.

Esta simplificación ayuda a controlar la dimensionalidad y favorece la interpretabilidad. También puede borrar señales de volumen que distinguen el trabajo rutinario del abuso. La frecuencia, el momento, la ubicación geográfica, los parámetros de solicitud y los recursos objetivo pueden ser relevantes durante una investigación.

La deriva conceptual plantea otro problema. El comportamiento funcional cambia cuando los equipos adoptan nuevos servicios, revisan procesos o migran arquitecturas. Un clasificador entrenado con las operaciones de ayer puede tratar cambios legítimos de despliegue como sospechosos.

Los atacantes también pueden adaptarse. Si comprenden el rol de comportamiento esperado, pueden elegir operaciones que se parezcan a su actividad normal. La clasificación por comportamiento eleva el coste de la suplantación, pero no elimina la evasión.

El enfoque depende de telemetría fiable. La cobertura incompleta de CloudTrail, el registro desactivado, la retención incoherente o la recopilación incompleta entre cuentas distorsionarán los vectores de identidad. Un modelo limpio no puede recuperar eventos que nunca se registraron.

Los límites de identidad también pueden volverse ambiguos. Los roles asumidos, las sesiones federadas, las credenciales de cargas de trabajo y las rutas de automatización compartidas podrían condensar varios actores en un único principal aparente. La inferencia de roles es tan precisa como los identificadores de los registros de origen.

Los datos entre organizaciones añaden otra incertidumbre. El comportamiento compartido puede revelar patrones sectoriales estables, pero cada empresa configura las cuentas de manera diferente. Operaciones muy asociadas con administradores en una infraestructura podrían surgir automáticamente en otra.

El grupo administrativo ilustra este riesgo. ConsoleLogin es muy distintivo en el conjunto de datos comunicado. Sin embargo, las solicitudes automáticas de consola, los diseños de acceso federado y los cambios en la interfaz del proveedor pueden alterar qué operaciones acompañan a una sesión interactiva.

Incluso la expresión “rol funcional” puede implicar más certeza de la que sustentan las pruebas. Un grupo describe similitud de comportamiento durante un período de observación. No demuestra propiedad organizativa, autorización ni propósito empresarial.

Por tanto, los equipos de seguridad deberían tratar los roles asignados como metadatos contextuales. Deben combinarlos con datos de permisos, alcance de recursos, indicadores de red, señales de autenticación e inteligencia de amenazas. Ninguna dimensión individual establece una intención maliciosa.

El contexto comercial también merece escrutinio. Unit 42 es la organización de investigación de amenazas de Palo Alto Networks, y la publicación vincula la metodología con Cortex Cloud y productos relacionados. Sus hallazgos técnicos siguen siendo valiosos, pero las afirmaciones sobre productos requieren validación por parte de los clientes.

Las organizaciones deberían preguntar si las clasificaciones se mantienen estables entre cuentas y a lo largo del tiempo. Deberían medir la calidad de las alertas antes de permitir que las discrepancias de rol activen una contención automatizada. Una respuesta equivocada podría interrumpir copias de seguridad, despliegues o la supervisión de seguridad.

La evaluación en modo de prueba ofrece una vía de adopción más segura. Los equipos pueden calcular roles inferidos, compararlos con la propiedad conocida de los activos y observar desviaciones sin modificar el acceso de producción. Después, los analistas pueden refinar umbrales y excepciones.

La mejor prueba no es si la visualización parece convincente. Es si el contexto de rol acorta las investigaciones mientras preserva detecciones significativas. Ese resultado exige evidencia operativa más allá de la publicación de investigación.

Tres señales mostrarán si la detección de identidad por comportamiento se sostiene

La próxima prueba es si la inferencia de roles por comportamiento sigue siendo precisa, portable y útil después de salir del entorno de investigación.

La primera señal es un rendimiento de detección medible. Unit 42 o sus clientes deben publicar resultados de precisión, recall y falsos positivos para varios roles. La clasificación de administradores por sí sola no puede establecer el rendimiento para agentes de respaldo, sistemas de despliegue o agentes autónomos.

Los resultados deberían incluir entornos no vistos, en lugar de identidades extraídas de la misma población organizativa. Un rendimiento sólido en infraestructuras externas respaldaría la afirmación de que los patrones funcionales se generalizan. Descensos pronunciados revelarían supuestos específicos de cada entorno.

La segunda señal es la validación multiplataforma. Los investigadores afirman que su metodología puede extenderse a Kubernetes, aplicaciones SaaS y otros proveedores de nube. Una implementación documentada fuera de AWS pondría a prueba esa afirmación.

La portabilidad debe significar más que procesar un formato de registros diferente. El método debe descubrir roles reconocibles, generar clasificadores estables y mejorar las decisiones reales de detección. De lo contrario, las convenciones de las API de AWS podrían estar haciendo más trabajo que el marco general.

La tercera señal es la adopción operativa mediante flujos de trabajo de detección transparentes. Los equipos de seguridad deberían buscar integraciones que expongan el rol inferido, las operaciones que contribuyen, el nivel de confianza y los comportamientos conflictivos dentro de una alerta.

Una puntuación de riesgo simple ocultaría la principal ventaja de la investigación. El valor reside en explicar que una identidad de copia de seguridad conocida ha empezado a actuar como administrador. Los analistas necesitan esa relación para evaluar la urgencia y elegir una respuesta.

Las implementaciones más sólidas también realizarán un seguimiento de los cambios de rol a lo largo del tiempo. Una cuenta de despliegue puede ampliar legítimamente su uso a nuevos servicios. Los sistemas necesitan calendarios de reentrenamiento, supervisión de la deriva, clasificadores versionados y procesos de revisión para los cambios de comportamiento.

Los equipos deberían evitar tratar cada discrepancia como un incidente. Algunas desviaciones reflejarán mantenimiento, migraciones o lanzamientos de nuevos productos. La señal de rol debe priorizar la investigación, mientras que otras evidencias determinan si la contención está justificada.

Las identidades humanas y de máquina también deberían evaluarse por separado. Los administradores interactivos, los servicios programados y los agentes autónomos generan actividad a ritmos distintos. Es posible que requieran diferentes ventanas de observación y umbrales.

Los agentes autónomos hacen que esta cuestión sea especialmente urgente. Un agente puede realizar secuencias variables en muchos servicios mientras persigue un único objetivo aprobado. Las etiquetas estáticas de trabajo describirán mal ese comportamiento.

Sin embargo, el comportamiento variable también dificulta la agrupación. El espacio de acciones legítimas de un agente puede solaparse con el reconocimiento, los cambios de configuración y el acceso a datos. Los defensores necesitarán contexto sobre objetivos, aprobaciones, recursos e historiales de ejecución.

La propuesta de Unit 42 sobre identidades en la nube aporta una parte de ese contexto. Crea una descripción empírica de cómo se comporta una identidad entre sus pares. No determina si el objetivo subyacente estaba autorizado.

Para los desarrolladores, la cuestión inmediata es si las identidades de despliegue y servicio presentan patrones claros y observables. Los equipos deberían revisar si los eventos de auditoría pueden conectarse de forma coherente entre roles asumidos y sesiones de automatización.

Los compradores empresariales deberían preguntar a los proveedores cómo se infieren los roles funcionales. También deberían solicitar evidencia que explique qué eventos impulsan cada clasificación. «Detección de anomalías impulsada por IA» no es información suficiente para una decisión de seguridad de alto impacto.

Los responsables de seguridad deberían comparar los hallazgos de comportamiento con las revisiones de acceso. Una identidad que parece operativamente limitada pero conserva permisos amplios representa una exposición prevenible. Una identidad que cambia de rol de forma repentina representa una posible amenaza activa.

Los trabajadores del conocimiento y los usuarios de productos de IA tienen un interés relacionado. Las aplicaciones empresariales conectan cada vez más asistentes y agentes con datos corporativos. Cada conexión crea una identidad cuyo comportamiento efectivo puede extenderse más allá de una simple etiqueta de usuario.

Los próximos uno a tres meses deberían revelar si Palo Alto Networks publica más validación, amplía la cobertura de roles o expone la lógica más directamente en los flujos de trabajo de los clientes. Las pruebas independientes reforzarían aún más el caso.

Los lectores deberían seguir tres preguntas concretas: ¿Funcionan los clasificadores en entornos no vistos? ¿Se transfieren más allá de AWS? ¿Mejoran las decisiones de los analistas? Las respuestas determinarán si los mapas de identidad basados en el comportamiento se convierten en contexto habitual de seguridad.

El juicio central del estudio ya se sostiene: los documentos de permisos son necesarios, pero no ofrecen una explicación completa del riesgo de identidad. Los defensores también necesitan evidencia de lo que realmente hacen las credenciales, las cargas de trabajo y los agentes.

Revise su propio inventario en la nube desde esa perspectiva. ¿Qué identidades tienen nombres y permisos, pero carecen de un rol de comportamiento verificado? Las brechas en esa respuesta identifican dónde más importa la investigación de Unit 42 sobre identidades en la nube.