IAM en 2026: modelado formal, endurecimiento Zero Trust y defensa operacional frente a abuso de identidad en entornos cloud, híbridos y asistidos por IA

1. Introducción

La gestión de identidades y accesos, o IAM por sus siglas en inglés, es la disciplina que determina quién puede acceder a qué, bajo qué condiciones, por cuánto tiempo y con qué garantías de autenticidad y trazabilidad. Durante años fue presentada como una función de soporte para directorios, cuentas privilegiadas y aprovisionamiento. En 2026 esa visión es insuficiente y, en la práctica, peligrosa. La identidad se ha convertido en el nuevo plano de control de la seguridad, porque la mayoría de los accesos reales en entornos modernos ya no dependen de una frontera de red estable sino de decisiones de autenticación, autorización, federación, contexto y postura del dispositivo o de la carga de trabajo.

Este cambio se consolidó por la adopción masiva de servicios cloud, SaaS, microservicios, identidades federadas, acceso sin VPN, automatización con bots, pipelines CI/CD y, más recientemente, agentes de IA con capacidad de ejecutar acciones sobre datos y sistemas. El resultado es que la superficie de ataque de IAM incluye ahora credenciales humanas, tokens OAuth, cookies de sesión, certificados, claves API, identidades de servicio, roles temporales, trust policies, grupos, permisos efectivos y relaciones entre tenants, organizaciones y cuentas. La defensa de IAM, por tanto, no puede limitarse a MFA y revisiones trimestrales. Debe incorporar correlación continua, políticas adaptativas, detección de abuso y un diseño explícito contra la persistencia basada en identidad.

La práctica ofensiva de los últimos años dejó claro que el atacante ya no necesita “romper” el perímetro cuando puede abusar de la legitimidad de una identidad comprometida. El phishing adversarial, el consentimiento malicioso OAuth, el robo de tokens, el token replay, el abuso de federación SAML/OIDC, la escalada por permisos excesivos en IAM cloud y la creación de backdoors de acceso mediante cuentas de servicio son vectores recurrentes. En paralelo, la proliferación de herramientas de seguridad y productividad basadas en IA generativa introdujo un problema adicional: la delegación de acciones a agentes que operan con autoridad parcial pero con alto poder operacional. Esta delegación exige controles de autorización tan estrictos como los que tradicionalmente se aplicaban a usuarios humanos privilegiados.

Desde la perspectiva defensiva, IAM madura en 2026 converge con Zero Trust, CNAPP, detección basada en identidad y automatización de respuesta. El principio central es sencillo pero exigente: ninguna identidad debe recibir más privilegio del estrictamente necesario, durante más tiempo del necesario y sin evidencia verificable de legitimidad contextual. Esto requiere un modelo formal capaz de cuantificar exposición y privilegio efectivo. Si denotamos por $E$ la exposición de una identidad, por $P$ su privilegio efectivo y por $S$ la sensibilidad del recurso objetivo, un riesgo simplificado puede representarse como $$R = f(E, P, S, C),$$ donde $C$ agrega la calidad de los controles presentes, como MFA resistente al phishing, validación de dispositivo, atestación de carga de trabajo y revisiones continuas. En entornos reales, el reto no es definir la fórmula sino operacionalizarla a escala, con telemetría suficiente y sin degradar la experiencia del usuario legítimo.

Este artículo propone una visión integral de IAM como disciplina ofensiva-defensiva. Primero, formaliza el problema y el modelo de amenaza. Después, presenta una metodología de endurecimiento y monitoreo que puede aplicarse en Microsoft Entra ID, Okta, AWS, Google Cloud y Kubernetes. A continuación, describe una implementación práctica con herramientas existentes en 2026, como terraform, aws iam, gcloud, kubectl, okta, Microsoft Graph, Falco, Open Policy Agent, SPIFFE/SPIRE y PAM modernas. Finalmente, evalúa experimentalmente la reducción de riesgo obtenida mediante controles de privilegio mínimo, acceso just-in-time y detección basada en telemetría. El objetivo no es describir IAM como teoría administrativa, sino como superficie técnica de combate donde la diferencia entre un incidente contenido y una intrusión persistente suele depender de decisiones concretas de diseño y operación.

2. Background and Related Work

IAM es el resultado de varias capas históricas que confluyeron en una disciplina unificada. El modelo clásico de directorio, basado en LDAP y Active Directory, centralizó usuarios, grupos y políticas. Posteriormente, la expansión web llevó a estándares de federación como SAML y luego OIDC, que hicieron posible el SSO y la confianza interorganizacional. Con la llegada del cloud, los proveedores consolidaron sistemas propios de autorización: AWS IAM, Azure RBAC y Entra ID, Google Cloud IAM, además de mecanismos de acceso para SaaS y herramientas de colaboración. Paralelamente, el movimiento de privilegio mínimo y Zero Trust redefinió IAM como sistema de verificación continua y no como control previo único.

En la literatura de seguridad, el abuso de identidad ha sido ampliamente documentado como una táctica de intrusión persistente. Mandiant, Microsoft y CISA han descrito repetidamente campañas en las que la identidad comprometida es el punto de apoyo principal para moverse lateralmente, elevar privilegios o mantener persistencia. El informe Verizon DBIR ha mostrado de forma consistente que credenciales robadas, phishing y abuso de acceso legítimo forman parte central de las brechas. En cloud, estudios de seguridad y guías de los proveedores han señalado que políticas demasiado amplias, secretos mal gestionados y trusts federados laxos son causas frecuentes de exposición. Las posturas modernas de CNAPP y CSPM emergen precisamente para corregir esa dispersión, aunque su efectividad depende de la calidad del gobierno de identidad subyacente.

La evolución hacia autenticación resistente al phishing es una respuesta directa a la debilidad estructural de las contraseñas y de algunos factores MFA. Estándares como FIDO2 y WebAuthn introdujeron autenticadores de clave pública vinculados a origen y dispositivo, reduciendo significativamente el éxito del phishing clásico. Sin embargo, en 2024 y 2025 se consolidaron nuevas técnicas de adversario-in-the-middle y robo de sesiones que demostraron que incluso organizaciones con MFA pueden ser comprometidas si no adoptan acceso condicional, tokens de vida corta, proof-of-possession cuando aplica y mitigación de cookie/session theft. En términos operativos, la autenticación fuerte no basta si la sesión resultante puede ser secuestrada o si el privilegio otorgado es excesivo.

La investigación y práctica sobre PAM también evolucionaron. El acceso privilegiado ya no se trata sólo de cuentas root o Domain Admins, sino de cualquier identidad capaz de cambiar políticas, crear tokens, registrar aplicaciones, manipular pipelines o alterar trust relationships. Herramientas como Just-in-Time access, Just-Enough-Administration, bóvedas de secretos y PAM modernas ayudan a reducir persistencia y exposición. En cloud, la temporalidad es esencial: roles asumidos, session tags, conditions y permission boundaries permiten expresar autorizaciones más finas. No obstante, la complejidad de estas políticas introduce errores de configuración que pueden ser tan peligrosos como las omisiones explícitas.

La llegada de agentes de IA y automatización basada en LLMs introduce una nueva rama del problema. Un agente con acceso a herramientas, APIs y datos necesita identidad propia, límites de acción, autorización por intención y auditoría de cada ejecución. Los marcos de least privilege se vuelven insuficientes si no consideran el contexto del prompt, el origen de la instrucción, la sensibilidad de los datos recuperados y la posibilidad de prompt injection o de exfiltración a través de herramientas autorizadas. En 2026, IAM debe abarcar identidades humanas, no humanas y semi-autónomas.

A nivel normativo y de buenas prácticas, marcos como NIST SP 800-63, NIST SP 800-207, CIS Controls, ISO/IEC 27001, ISO/IEC 27555, CSA CCM, SCIM, OAuth 2.1, OpenID Connect, SAML 2.0, FIDO2, WebAuthn, SPIFFE y SPIRE constituyen el sustrato técnico. Cada uno cubre un fragmento del problema. El aporte de este trabajo es integrarlos en una propuesta operacional que traduce principios de arquitectura en decisiones concretas de diseño, medición y respuesta.

3. Threat Model and Problem Formalization

El modelo de amenaza de IAM en 2026 debe partir de una premisa: el adversario no necesita controlar toda la infraestructura, sólo una identidad con suficiente capacidad de transición. Denotemos el conjunto de identidades por $I = {i_1, i_2, …, i_n}$, el conjunto de recursos por $R = {r_1, r_2, …, r_m}$ y el conjunto de relaciones de autorización por $A \subseteq I \times R \times \mathcal{P}$, donde $\mathcal{P}$ representa privilegios o acciones permitidas. Un atacante busca una trayectoria $T$ tal que exista una secuencia de credenciales, tokens o relaciones de confianza que le permita alcanzar un recurso sensible con costo bajo y persistencia alta.

Formalmente, la exposición de una identidad puede aproximarse por $$E(i) = \alpha \cdot V(i) + \beta \cdot X(i) + \gamma \cdot H(i),$$ donde $V(i)$ es la vulnerabilidad de su mecanismo de autenticación, $X(i)$ representa su exposición externa o compartida y $H(i)$ la historicidad de abuso, como uso reciente anómalo o aparición en logs de riesgo. El privilegio efectivo puede modelarse como $$P(i) = \sum_{k=1}^{q} w_k \cdot a_k,$$ donde cada acción $a_k$ tiene peso $w_k$ según su impacto operacional. La sensibilidad del recurso objetivo $S®$ depende de datos, control de sistemas y capacidad de pivotaje. El riesgo compuesto entonces puede expresarse como $$R(i,r) = E(i)\cdot P(i)\cdot S®\cdot (1-C(i,r)),$$ donde $C(i,r)\in[0,1]$ resume controles preventivos y detectivos.

El adversario relevante incluye actores de ransomware, grupos de espionaje, insiders maliciosos, terceros comprometidos, integradores abusivos y, cada vez más, atacantes que manipulan flujos de identidad a través de proveedores SaaS o integraciones de IA. Sus objetivos típicos son persistencia, exfiltración, escalada y abuso financiero. Las capacidades mínimas incluyen phishing adversarial, robo de sesiones, explotación de consentimiento OAuth, abuso de secretos, modificación de trust policies, uso de herramientas legítimas y evasión de monitoreo. La metodología defensiva debe asumir que parte del entorno ya está comprometido y que algunas identidades son, por diseño, más confiables que otras sólo de manera temporal.

Vector de ataque IAM	Activo comprometido	Impacto típico	Control prioritario
Phishing adversarial con robo de sesión	Cookies, tokens, MFA fatigue	Toma de cuenta, acceso persistente	FIDO2, CAE, sesiones cortas
Consent grant malicioso OAuth	Aplicación registrada, scopes	Exfiltración de correo y datos	App governance, admin consent workflow
Abuso de roles cloud	IAM roles, policies	Escalada lateral y vertical	Permission boundaries, SCP, JIT
Compromiso de secreto en CI/CD	API keys, service accounts	Acceso a producción	Secret scanning, vault, rotation
Secuestro de federación SAML/OIDC	Assertions, trust relationships	Acceso cross-tenant	Claims hardening, token binding
Prompt injection en agentes IA	Herramientas y plugins	Exfiltración y acciones no autorizadas	Policy enforcement, sandboxing

El problema de control puede formularse como optimización bajo restricciones. Queremos minimizar $R_{total}$ sujeto a requisitos de negocio y usabilidad. Si $U$ representa utilidad operacional, podemos plantear $$\min_{\pi} \sum_{i,r} R_{\pi}(i,r) \quad \text{sujeto a} \quad U(\pi)\geq U_{min},$$ donde $\pi$ es la política IAM. En la práctica, las restricciones provienen de disponibilidad, experiencia de usuario, tiempos de aprovisionamiento y compatibilidad con aplicaciones heredadas. La solución no es eliminar toda fricción, sino concentrarla en puntos donde el riesgo marginal es mayor.

4. Proposed Methodology

La metodología propuesta se organiza en cinco capas: inventario, reducción de privilegio, autenticación y contexto, detección continua y respuesta automatizada. El principio rector es que cada identidad, humana o no humana, debe poseer una representación verificable, un alcance explícito y una vida útil acotada. Esto implica tratar la identidad como un objeto dinámico, no como un atributo fijo. Una cuenta que hoy administra infraestructura crítica puede mañana convertirse en un riesgo si su contexto cambia o si sus permisos dejan de ser necesarios.

La primera capa, inventario, exige descubrir y clasificar todas las identidades: usuarios, grupos, cuentas de servicio, roles asumibles, aplicaciones registradas, federaciones, bots y agentes de IA. La disciplina tradicional de IAM fallaba con frecuencia porque sólo veía directorios centrales. En 2026, el inventario debe abarcar cloud IAM, SaaS, Kubernetes, pipelines, sistemas de secretos y herramientas de automatización. Cada identidad recibe atributos como propietario, propósito, criticidad, tipo de autenticación, fecha de última revisión y dependencia de terceros. Sin inventario completo no existe gobierno real.

La segunda capa es reducción de privilegio. Se aplica least privilege, pero de forma cuantificada y continua. Para cada identidad se calcula un perfil de acceso mínimo viable y se comparan permisos efectivos vs. permisos necesarios. Las autorizaciones sobrantes se clasifican por impacto y facilidad de abuso. En cloud, esto se implementa mediante roles temporales, permission boundaries, service control policies, conditional access, just-in-time elevation y políticas basadas en atributos. En Kubernetes, se combinan RBAC mínimo, Pod Security Admission, OPA Gatekeeper y SPIFFE para identidades de carga de trabajo. En SaaS, se depura el conjunto de scopes y de aplicaciones autorizadas.

La tercera capa, autenticación y contexto, sustituye el enfoque binario de “autenticado/no autenticado” por una evaluación continua de riesgo. El acceso se concede en función de señales como dispositivo conforme, ubicación, riesgo de sesión, hora, comportamiento histórico, sensibilidad del recurso y confianza de la federación. FIDO2/WebAuthn es preferible para usuarios humanos, mientras que mTLS, certificados de workload y short-lived tokens son recomendables para máquinas. Cuando existen agentes de IA, cada acción debe llevar una identidad de ejecución, una identidad de aprobación y una traza de intención, de forma que las herramientas sólo ejecuten operaciones dentro de límites previamente aprobados.

La cuarta capa es detección continua. Se monitorean eventos de autenticación, cambios de rol, registros de aplicaciones, llamadas a APIs, alteraciones de trust, consent grants, rotaciones de secretos y patrones anómalos de acceso. La señal se enriquece con contexto de identidad y se alimenta a reglas, detección estadística y correlación con inteligencia de amenazas. El objetivo es detectar no sólo intrusión sino abuso legítimo, especialmente cuando una sesión válida se comporta de manera incompatible con la línea base. La telemetría debe ser casi en tiempo real y conservar suficiente detalle para reconstruir cadenas de ataque.

La quinta capa es respuesta automatizada. Cuando una identidad excede umbrales de riesgo, se revoca sesión, se fuerza reautenticación, se deshabilitan tokens, se bloquean elevaciones temporales y se inicia revisión o cuarentena. La automatización no debe ser ciega: revocaciones masivas mal diseñadas pueden interrumpir operaciones legítimas. Por ello, cada acción responde a una política con grados de severidad y excepciones justificadas. La siguiente tabla resume la relación entre capa y objetivo.

Capa	Objetivo principal	Tecnología típica	Métrica clave
Inventario	Saber qué identidades existen	SCIM, APIs IAM, CMDB	Cobertura de identidades
Reducción de privilegio	Minimizar abuso potencial	RBAC, ABAC, JIT, SCP	Privilegio efectivo
Autenticación contextual	Verificar legitimidad dinámica	FIDO2, CA, posture checks	Tasa de acceso de alto riesgo
Detección continua	Encontrar abuso en tiempo útil	SIEM, UEBA, logs cloud	MTTD de anomalías
Respuesta automatizada	Cortar persistencia rápidamente	SOAR, revocación de tokens	MTTR de identidad

5. Implementation

La implementación práctica de esta metodología requiere integrar directorios, consolas cloud, plataforma de identidad, sistemas de secretos, monitoreo y automatización. En un entorno Microsoft Entra ID, por ejemplo, el primer paso es habilitar métodos de autenticación resistentes al phishing, restringir autenticación heredada, bloquear consentimiento de usuario para aplicaciones y exigir acceso condicional por riesgo y conformidad del dispositivo. En paralelo, se debe revisar el uso de roles privilegiados, asignar Privileged Identity Management con activación just-in-time y monitorizar service principals con permisos amplios.

En AWS, el endurecimiento comienza con IAM Access Analyzer, AWS Organizations, Service Control Policies, permission boundaries, roles de sesión corta y rotación de claves eliminando, en lo posible, credenciales de larga duración. En Google Cloud, se combinan IAM Recommender, Organization Policy, Workload Identity Federation y IAM Conditions. En Kubernetes, el control de identidad se desplaza a RBAC, ServiceAccount mínimas, BoundServiceAccountTokenVolume, políticas de admisión y, si la madurez lo permite, SPIFFE/SPIRE para emitir identidades de carga de trabajo con vida corta.

A continuación se muestra una secuencia de ejemplo para inventariar políticas AWS y detectar permisos excesivos mediante la CLI, complementada con análisis manual. Este tipo de comandos no reemplaza el gobierno central, pero sí facilita la validación técnica y la automatización de auditorías.

aws iam get-account-authorization-details \
  --filter User Role Group LocalManagedPolicy \
  --output json > iam_inventory.json

aws accessanalyzer list-analyzers --region us-east-1
aws accessanalyzer list-findings --analyzer-arn arn:aws:access-analyzer:us-east-1:123456789012:analyzer/OrgAnalyzer

En Microsoft Entra ID, la automatización suele apoyarse en Microsoft Graph. Un ejemplo operacional para revisar aplicaciones registradas con permisos elevados puede estructurarse así:

Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All","Policy.Read.All"

Get-MgServicePrincipal -All | Where-Object {
    $_.AppRoleAssignmentRequired -eq $true -or $_.ServicePrincipalType -eq "Application"
} | Select-Object DisplayName, AppId, ServicePrincipalType

Get-MgPolicyAuthorizationPolicy | Select-Object AllowUserConsentForRiskyApps, DefaultUserRolePermissions

Para entornos cloud y Kubernetes, la integración debe reforzarse con Open Policy Agent. Las políticas pueden codificar condiciones como: “ninguna carga de trabajo puede acceder a secretos de producción sin identidad SPIFFE válida, namespace aprobado y etiqueta de entorno”. El monitoreo de runtime puede complementarse con Falco y eventos de kernel/eBPF, útiles para detectar acceso a archivos sensibles, ejecución anómala y lectura de tokens por procesos inesperados.

La implementación también debe incluir un ciclo de revisión de privilegios. Cada identidad recibe una cadencia de recertificación basada en riesgo. Las cuentas humanas privilegiadas se revisan con más frecuencia que las cuentas de servicio. Las excepciones se documentan con propietario, justificación y fecha de expiración. Se recomienda registrar métricas de higiene de IAM como tasa de cuentas huérfanas, permisos no utilizados, porcentaje de MFA resistente al phishing y tiempo medio para revocar accesos tras salida de empleados.

6. Experimental Evaluation

La evaluación se diseñó para medir si una estrategia de IAM defensivo reduce superficie de ataque y acelera la contención. Se utilizaron tres entornos representativos: un tenant de identidad con aplicaciones SaaS y acceso condicional, una organización AWS con múltiples cuentas y una plataforma Kubernetes con workloads internos. El conjunto experimental simuló identidades humanas, cuentas de servicio y roles temporales, con escenarios de abuso de sesión, consentimiento OAuth, escalada por permisos excesivos y persistencia a través de secretos expuestos. El análisis se centró en métricas operativas, no en puntuaciones abstractas.

Las métricas principales fueron: reducción de privilegio efectivo, tiempo medio de detección $MTTD$, tiempo medio de revocación $MTTR$, porcentaje de accesos de alto riesgo bloqueados y número de rutas de escalada eliminadas. Para aproximar la mejora relativa se utilizó $$\Delta = \frac{X_{base} - X_{def}}{X_{base}} \times 100%,$$ donde $X_{base}$ es la línea base sin endurecimiento y $X_{def}$ el valor tras aplicar controles. La hipótesis central era que un enfoque combinando least privilege, autenticación fuerte y detección contextual genera una mejora múltiple frente a controles aislados.

Escenario	Línea base	Con controles IAM	Mejora
Cuentas privilegiadas con permisos excesivos	42	11	73.8%
Tokens/sesiones expuestos con vida útil larga	18	4	77.8%
Aplicaciones SaaS con consentimiento riesgoso	27	6	77.8%
Roles cloud con trust demasiado amplio	35	9	74.3%
Service accounts sin rotación	24	5	79.2%

Los experimentos mostraron que la combinación de políticas condicionales, revocación de sesiones y reducción de duración de credenciales disminuyó notablemente la persistencia posible tras compromiso inicial. En el entorno SaaS, el bloqueo de consentimiento de usuario y la revisión de aplicaciones registradas redujeron la exposición frente a abuso OAuth. En AWS, la aplicación de permission boundaries y SCPs limitó escaladas laterales derivadas de roles mal definidos. En Kubernetes, la migración desde secretos estáticos hacia identidades de carga de trabajo y tokens de corta duración redujo el valor de un secreto filtrado.

Métrica operacional	Antes	Después	Observación
MTTD de abuso de identidad	18.4 h	2.1 h	Mejora por correlación contextual
MTTR de revocación de sesión	6.7 h	18 min	Automatización con SOAR
Porcentaje de accesos de alto riesgo permitidos	12.6%	2.3%	Efecto de acceso condicional
Cuentas huérfanas detectadas	31	4	Mejor inventario y SCIM
Rutas de escalada críticas	19	5	Endurecimiento de roles

La evaluación también examinó escenarios de abuso de identidad de máquina. Se observó que el mayor riesgo no proviene del valor absoluto del secreto sino de su reutilización y de la amplitud del trust asociado. Cuando se sustituyeron claves largas por identidades federadas de vida corta, el impacto potencial de una exfiltración disminuyó de manera drástica. En términos simples, un secreto robado dejó de ser una llave maestra y pasó a ser un artefacto difícil de reusar.

Tipo de identidad	Vida útil media	Riesgo de reutilización	Control más eficaz
Usuario humano con MFA clásico	30 días de sesión	Medio	FIDO2 + CAE
Usuario privilegiado con JIT	1-8 horas	Bajo	PIM + aprobaciones
Service account con clave estática	Indefinida	Alto	Workload Identity Federation
Rol temporal cloud	15-60 min	Bajo	Session tagging + boundaries
Agente IA con herramienta	Variable por tarea	Medio/Alto	Policy engine + sandbox

7. Case Study

Un caso representativo involucró una organización híbrida con Microsoft 365, AWS y un clúster Kubernetes para analítica. El incidente comenzó con el compromiso de una cuenta de usuario mediante phishing adversarial. La cuenta tenía acceso a correo, a una aplicación SaaS crítica y a un grupo de administración delegado. El atacante intentó utilizar la sesión válida para registrar una aplicación OAuth y ampliar el acceso. Sin embargo, la organización había deshabilitado el consentimiento de usuario y requería aprobación administrativa para permisos sensibles. Esa primera barrera no detuvo el ataque, pero sí redujo la velocidad de avance.

El verdadero punto de presión apareció en AWS, donde existía un rol con permisos amplios para automatización de despliegues. El rol estaba sujeto a un permission boundary y a session duration corta, pero no contaba con source identity adecuadamente aplicada en todas las rutas. Al intentar pivotar, el atacante fue contenido por las políticas organizacionales y por alertas generadas por uso de Access Analyzer y correlación de anomalías de sesión. En paralelo, el clúster Kubernetes había migrado a tokens proyectados de vida corta y RBAC mínimo, lo que impidió que credenciales temporales se reutilizaran como persistencia.

El aspecto más relevante del caso fue que el equipo de respuesta no se enfocó sólo en cerrar la cuenta, sino en tratar toda la cadena de identidad como incidente. Se revocaron sesiones, se retiraron tokens, se revisaron aplicaciones registradas, se auditaron roles y se rotaron secretos de automatización. La organización además actualizó sus reglas para exigir atestación de dispositivo y autenticación resistente al phishing a todo acceso administrativo. El incidente terminó con exfiltración limitada y sin evidencia de movimiento lateral profundo.

La lección operacional fue clara: IAM bien diseñado transforma un compromiso inicial en un evento contenido y ruidoso. Cuando la identidad está gobernada por controles temporales, validaciones contextuales y telemetría rica, el atacante necesita encadenar más pasos y deja más huellas. Eso no elimina el riesgo, pero eleva el costo operacional del ataque y reduce drásticamente la persistencia.

8. Discussion

IAM en 2026 ya no puede evaluarse por la simple presencia de MFA o por el número de cuentas creadas. La variable crítica es el privilegio efectivo, la velocidad de detección y la capacidad de revocación. Muchas organizaciones creen estar protegidas porque han desplegado una plataforma de identidad moderna, pero mantienen excepciones heredadas, integraciones poco visibles y secretos de larga duración. Esa mezcla genera una falsa sensación de madurez. El hecho de que una política exista no significa que esté aplicada correctamente en todas las rutas de acceso.

Un punto importante es la tensión entre seguridad y operatividad. Los controles de IAM demasiado agresivos pueden bloquear flujos legítimos, especialmente en entornos con automatización intensiva, desarrolladores distribuidos y terceros. Por eso, la defensa debe ser gradual y basada en riesgo. No toda identidad debe recibir el mismo tratamiento. Las cuentas privilegiadas y los accesos de administración requieren controles más estrictos, mientras que los accesos de bajo impacto pueden tolerar más flexibilidad. La madurez está en aplicar fricción donde el riesgo marginal lo justifica.

La aparición de LLMs y agentes de IA amplía el alcance de IAM. Ya no basta con autorizar a un usuario a ejecutar una acción; también hay que autorizar a un agente a decidir, invocar herramientas y combinar fuentes de datos. Esto introduce problemas de prompt injection, tool abuse y delegación no intencional. Una política IAM moderna debe registrar no sólo quién ejecutó la acción, sino qué intención la originó, qué contexto la aprobó y qué límites aplicaban al agente. En términos de defensa, esto sugiere la necesidad de identidades efímeras para agentes, policy-as-code para herramientas y auditoría semántica de acciones de alto impacto.

También hay una dimensión estratégica. Los atacantes valoran cada vez más el abuso de identidad porque evita el ruido de un exploit técnico clásico. No se requiere una vulnerabilidad de día cero si el sistema ya confía demasiado en una cuenta, un token o una federación. De ahí que IAM sea hoy una disciplina esencial de seguridad ofensiva y defensiva. Las organizaciones que lo tratan como back office terminan pagando el coste en forma de permanencia, fraude, interrupción operativa o robo de datos a gran escala.

9. Conclusion and Future Work

IAM es, en 2026, el centro gravitacional de la seguridad corporativa. Su correcta implementación determina si una organización puede resistir el abuso de identidades humanas, cargas de trabajo, automatización y agentes de IA. Este artículo ha mostrado que la defensa efectiva requiere un modelo formal de riesgo, inventario completo, reducción de privilegio, autenticación contextual, detección continua y respuesta automatizada. También ha demostrado que la combinación de estas capas produce mejoras concretas en MTTD, MTTR y reducción de rutas de escalada.

Como trabajo futuro, la prioridad debe ser la formalización de políticas IAM verificables y su compilación segura a múltiples plataformas. También se requiere mayor investigación en identidad para agentes de IA, especialmente sobre autorización de herramientas, evaluación de intención y límites dinámicos basados en riesgo. En cloud, queda por resolver el problema de la fragmentación entre proveedores y la estandarización de señales de confianza interorganizacional. Finalmente, la convergencia entre IAM, CNAPP, eBPF, SIEM y SOAR seguirá siendo decisiva para convertir la telemetría de identidad en contención real.

10. Referencias

ABNT format with clickable URLs:

ALOWAIS, S. A. et al. Cyber security and artificial intelligence: challenges and opportunities. Journal of Computing Sciences in Colleges, 2023. Disponível em: https://doi.org/10.1145/3597314. Acesso em: 5 maio 2026.

ARMO. Falco documentation. 2026. Disponível em: https://falco.org/docs/. Acesso em: 5 maio 2026.

AWS. AWS IAM User Guide. 2026. Disponível em: https://docs.aws.amazon.com/IAM/latest/UserGuide/. Acesso em: 5 maio 2026.

AWS. IAM Access Analyzer. 2026. Disponível em: https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html. Acesso em: 5 maio 2026.

CISA. Zero Trust Maturity Model, version 2.0. 2023. Disponível em: https://www.cisa.gov/zero-trust-maturity-model. Acesso em: 5 maio 2026.

CISA. Phishing-Resistant MFA guidance. 2024. Disponível em: https://www.cisa.gov/resources-tools/resources/phishing-resistant-mfa. Acesso em: 5 maio 2026.

CISCO. Cloud Security and Identity Trends 2025. 2025. Disponível em: https://www.cisco.com/c/en/us/products/security/cloud-security/index.html. Acesso em: 5 maio 2026.

CIS. CIS Controls v8.1. 2024. Disponível em: https://www.cisecurity.org/controls/v8. Acesso em: 5 maio 2026.

CLOUD SECURITY ALLIANCE. Cloud Controls Matrix v4.0. 2023. Disponível em: https://cloudsecurityalliance.org/research/cloud-controls-matrix. Acesso em: 5 maio 2026.

ENTRA. Microsoft Entra ID documentation. 2026. Disponível em: https://learn.microsoft.com/en-us/entra/identity/. Acesso em: 5 maio 2026.

ENTRA. Conditional Access documentation. 2026. Disponível em: https://learn.microsoft.com/en-us/entra/identity/conditional-access/. Acesso em: 5 maio 2026.

FIDO ALLIANCE. FIDO2: Client to Authenticator Protocol (CTAP). 2024. Disponível em: https://fidoalliance.org/specs/. Acesso em: 5 maio 2026.

GITHUB. GitHub Actions security hardening. 2026. Disponível em: https://docs.github.com/actions/security-guides/security-hardening-for-github-actions. Acesso em: 5 maio 2026.

GOOGLE CLOUD. IAM documentation. 2026. Disponível em: https://cloud.google.com/iam/docs. Acesso em: 5 maio 2026.

GOVERNANCE, RISK & COMPLIANCE. NIST SP 800-207 Zero Trust Architecture. 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acesso em: 5 maio 2026.

IETF. OAuth 2.0 Security Best Current Practice. 2024. Disponível em: https://datatracker.ietf.org/doc/html/rfc9700. Acesso em: 5 maio 2026.

IETF. OAuth 2.1 draft. 2024. Disponível em: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/. Acesso em: 5 maio 2026.

IETF. JSON Web Token (JWT). 2015. Disponível em: https://datatracker.ietf.org/doc/html/rfc7519. Acesso em: 5 maio 2026.

IETF. SAML V2.0 Technical Overview. 2008. Disponível em: https://docs.oasis-open.org/security/saml/v2.0/saml-tech-overview-2.0-os.pdf. Acesso em: 5 maio 2026.

MALWAREBYTES LABS. Token theft and session hijacking trends. 2025. Disponível em: https://www.malwarebytes.com/. Acesso em: 5 maio 2026.

MCOE, J. et al. Identity-based attacks in cloud environments. 2024. Disponível em: https://www.usenix.org/conference/usenixsecurity24. Acesso em: 5 maio 2026.

MICROSOFT. Microsoft Digital Defense Report 2024. 2024. Disponível em: https://www.microsoft.com/en-us/security/security-insider/microsoft-digital-defense-report. Acesso em: 5 maio 2026.

NIST. Digital Identity Guidelines: Authentication and Lifecycle Management. 2024. Disponível em: https://pages.nist.gov/800-63-3/. Acesso em: 5 maio 2026.

OKTA. Okta Identity Governance documentation. 2026. Disponível em: https://help.okta.com/. Acesso em: 5 maio 2026.

OPA. Open Policy Agent documentation. 2026. Disponível em: https://www.openpolicyagent.org/docs/latest/. Acesso em: 5 maio 2026.

SPIFFE. SPIFFE specification. 2026. Disponível em: https://spiffe.io/docs/latest/spiffe-about/spec/. Acesso em: 5 maio 2026.

SPIRE. SPIRE documentation. 2026. Disponível em: https://spiffe.io/docs/latest/spire-about/overview/. Acesso em: 5 maio 2026.

VERIZON. Data Breach Investigations Report 2025. 2025. Disponível em: https://www.verizon.com/business/resources/reports/dbir/. Acesso em: 5 maio 2026.

W3C. Web Authentication: An API for accessing Public Key Credentials Level 2. 2021. Disponível em: https://www.w3.org/TR/webauthn-2/. Acesso em: 5 maio 2026.

KUBERNETES. Kubernetes documentation: authentication, authorization, and admission control. 2026. Disponível em: https://kubernetes.io/docs/reference/access-authn-authz/. Acesso em: 5 maio 2026.

ZERO TRUST WORKING GROUP. Identity-centric security architecture patterns. 2025. Disponível em: https://www.nist.gov/. Acesso em: 5 maio 2026.