Las claves de agentes de IA huérfanas permanecen activas mucho después de que finalizan los proyectos

A medida que los agentes de inteligencia artificial se vuelven comunes en los flujos de trabajo de desarrollo, con frecuencia dejan atrás claves activas de gestión de identidad y acceso (IAM) mucho tiempo después de completar sus tareas. Esto crea una brecha de seguridad significativa donde existen credenciales válidas sin propietario ni propósito. Un análisis reciente destaca cómo estas claves huérfanas pueden persistir durante meses, ofreciendo a los atacantes un posible punto de entrada en entornos cloud.

Qué ocurrió

Un escenario hipotético pero representativo ilustra el problema central: un usuario IAM llamado _research-agent-2 conserva una clave de acceso creada hace catorce meses. La clave fue utilizada por última vez hace once meses, pero sigue activa. El proyecto al que apoyaba ha cerrado, y el empleado que aprobó su creación ya no trabaja en la empresa. A diferencia de los empleados humanos, que activan procedimientos de salida cuando se van, los agentes de IA terminados simplemente dejan de ejecutarse, dejando sus credenciales en un estado de limbo.

Este problema del ciclo de vida no se debe a descuido, sino a una brecha estructural en la gestión de identidades no humanas. Las claves de acceso de usuarios IAM de AWS no caducan automáticamente. En consecuencia, una clave olvidada permanece válida indefinidamente hasta que alguien la deshabilita o elimina manualmente. El Open Web Application Security Project (OWASP) clasificó la mala gestión de salidas como el riesgo principal en su Top 10 de 2025 para identidades no humanas, enfatizando la necesidad de retirar activos no utilizados y asignar propietarios responsables a los que permanecen.

La urgencia de este problema se ve reforzada por la velocidad de los ataques modernos. En septiembre de 2026, GreyNoise documentó una campaña orquestada por IA contra servidores PaperCut. Los atacantes pasaron de un espacio de trabajo vacío a la ejecución remota de código en menos de cuatro horas. Una vez lanzada, la campaña comprometió al menos once organizaciones en solo veintiséis segundos. Aunque este ataque específico no utilizó claves AWS IAM abandonadas, demuestra lo rápido que el acceso expuesto resulta útil para los adversarios. Los procesos lentos de inventario y revocación son peligrosamente inadecuados en este contexto.

Detalles clave

• Las claves de acceso de usuarios IAM de AWS no tienen fecha de caducidad automática y permanecen válidas hasta ser revocadas manualmente.
• El Top 10 de OWASP de 2025 para identidades no humanas clasifica la mala gestión de salidas como el riesgo principal.
• Un informe de GreyNoise de septiembre de 2026 mostró un ataque impulsado por IA que comprometió once organizaciones en 26 segundos.
• CloudQuery puede sincronizar informes de credenciales IAM de AWS para ayudar a identificar claves no usadas durante más de 90 días.
• La configuración de tiempo de vida (TTL) del entorno puede ayudar a gestionar credenciales desechables, pero no garantiza la revocación inmediata si fallan las destrucciones.
• Las claves de acceso de la cuenta raíz requieren auditorías separadas y urgentes, y generalmente no deberían existir.

Antecedentes

Las identidades no humanas se refieren a cuentas de servicio, bots y agentes de IA que interactúan con la infraestructura cloud. A diferencia de los usuarios humanos, estas entidades no tienen eventos naturales de rotación como renuncias o jubilaciones. Sus credenciales, como claves de acceso o tokens, suelen aprovisionarse para tareas específicas pero carecen de gestión de ciclo de vida integrada. Cuando la tarea termina, la credencial puede permanecer activa si no se desmantela explícitamente.

Inventariar estas identidades es difícil porque los proveedores cloud no siempre rastrean qué agente específico usó una cuenta. Es necesario correlacionar la actividad con registros de auditoría y propietarios nombrados para determinar si una clave sigue siendo necesaria. Además, aunque las plataformas de despliegue pueden imponer políticas durante la creación de infraestructura, no siempre pueden controlar las credenciales creadas mediante consolas o scripts externos. Esta distinción entre identidad de despliegue y credenciales aprovisionadas complica los esfuerzos de gobernanza.

Por qué importa

Para los equipos que ejecutan su propio software, las claves huérfanas representan una deuda de seguridad silenciosa. Una máquina virtual olvidada incurre en costos financieros, pero una credencial olvidada otorga potencial acceso a datos y sistemas sensibles. Los atacantes no necesitan saber que una clave está huérfana para explotarla; solo necesitan que sea válida. A medida que proliferan los agentes de IA, el volumen de estas identidades no humanas crecerá, aumentando la superficie de ataque si no se implementa una gobernanza adecuada.

Las auditorías anuales manuales son insuficientes dada la velocidad de los ataques automatizados. Los equipos necesitan visibilidad continua sobre el uso de credenciales. Sin consultas y políticas automatizadas, los líderes de seguridad pueden seguir ignorando claves activas asociadas con proyectos obsoletos. Este retraso entre el cierre del proyecto y la revocación de credenciales crea ventanas de vulnerabilidad que los atacantes sofisticados pueden explotar rápidamente.

Además, confiar únicamente en herramientas de infraestructura como código no es suficiente. Si bien herramientas como Terraform pueden gestionar la creación de claves, no revocan automáticamente las claves si el proceso de destrucción falla o si las claves se crean fuera del entorno gestionado. Los equipos deben verificar la revocación activamente en lugar de confiar en temporizadores de cuenta regresiva o scripts de despliegue.

Qué puedes hacer

• Ejecuta consultas SQL contra informes de credenciales IAM sincronizados para encontrar claves activas no usadas durante más de 90 días.
• Implementa políticas de aprobación en plataformas de despliegue para bloquear la creación de credenciales de larga duración en planes de Terraform u OpenTofu.
• Prefiere la federación basada en OIDC para despliegues que utilicen credenciales temporales que caducan con la sesión.
• Establece TTLs de entorno para credenciales desechables, pero verifica la revocación real mediante comprobaciones de estado.
• Desactiva primero las claves sospechosas para monitorear errores de autenticación antes de eliminarlas permanentemente.
• Asigna propietarios explícitos a todas las identidades no humanas y registra la propiedad en tu inventario de credenciales.

La sección de cierre aparece abajo.