Imagina que en un informe de credenciales aparece una entrada inexplicable para el equipo de la plataforma. Un usuario IAM llamado research-agent-2 posee una clave de acceso creada hace 14 meses, usada por última vez hace 11 meses, pero sigue activa.
El proyecto que requería esta clave fue cerrado hace tiempo, y la persona que aprobó su creación ya no trabaja en la empresa.
Este escenario, aunque hipotético, refleja un problema real y común en la gestión de credenciales: claves de acceso que permanecen activas sin supervisión, exponiendo innecesariamente los sistemas. 
No se trata solo de negligencia. Al crear un agente para una tarea específica, cuando ésta termina, muchas veces nadie revisa ni desactiva sus accesos. Cuando un empleado se va, comienza su proceso de offboarding; en cambio, cuando un agente termina su función, simplemente se cierra su ventana de operación. Dado que las claves de acceso de usuarios IAM en AWS no caducan automáticamente, una clave olvidada permanece activa hasta que alguien la deshabilita o elimina manualmente.
“Un empleado que se va inaugura el proceso de desvinculación; un agente terminado simplemente deja una pestaña abierta.”
OWASP sitúa el problema del offboarding impropio como su principal riesgo para identidades no humanas en 2025. Su solución básica es clara: retirar lo que ya no se necesita y asignar un propietario responsable para el resto. El mayor desafío permanece en detectar qué credenciales existen y cuál es su estado.
El problema se agudiza porque los atacantes se mueven mucho más rápido que una auditoría anual de seguridad convencional. En septiembre de 2026, GreyNoise reportó una campaña orquestada por IA contra servidores PaperCut, donde el atacante logró ejecutar código de forma remota en una víctima real en menos de cuatro horas. Esta campaña, que en solo 26 segundos comprometió al menos once organizaciones más, no usó claves AWS IAM abandonadas, pero evidenció la velocidad con la que un acceso expuesto puede ser explotado y las consecuencias de una gestión lenta de inventarios y revocaciones.
Las credenciales de agentes pueden sobrevivir mucho tiempo más allá de su cometido si nadie supervisa su ciclo de vida.
En artículos anteriores analizábamos cómo asignar propietarios al descubrir recursos, reasignarlos antes de la salida de una persona o cuando el dueño es un agente. Las credenciales suponen un problema similar, aunque con una complejidad añadida: la identidad con la que el agente o la plataforma se despliega en la nube es la que autentica su acceso.
“Una máquina virtual olvidada tiene un coste económico; una credencial olvidada puede conceder acceso.”
Una credencial provisionada -ya sea una clave, secreto o token- es un elemento persistente creado por un despliegue para otro sistema. Por tanto, cada elemento tiene propietarios y procedimientos de revocación diferentes. Mientras que una VM olvidada implica solo un gasto, una credencial válida y sin control puede convertirse en una puerta abierta para un atacante.
1. Detectar claves inactivas mediante consultas especializadas
Herramientas como CloudQuery pueden sincronizar informes de credenciales de AWS IAM para identificar claves que están activas, tienen al menos 90 días desde su creación y no han sido utilizadas en el mismo período. La consulta diseñada para el dialecto de ClickHouse extrae el último estado sincronizado, lee los dos posibles slots de claves por usuario y filtra las inactivas, excluyendo la cuenta root.
El umbral de 90 días es un punto de revisión recomendado, más que una sentencia definitiva. Muchas claves pueden ser usadas de forma trimestral por trabajos programados, y un campo «última fecha de uso» nulo indica solo que debe investigarse, no que la clave sea prescindible. Además, este informe no especifica qué agente empleó cada cuenta IAM, por lo que debe correlacionarse con los logs de auditoría y las asignaciones de propiedad para concluir si puede eliminarse o no.
El mismo concepto puede aplicarse en otras plataformas cloud como Microsoft Entra ID o Google Cloud, donde gestionar el inventario de credenciales y analizar su uso resulta fundamental para mantener la seguridad.
2. Políticas que evitan la creación indiscriminada de claves
Modificar el escenario antes de que se generen las claves también es clave. Herramientas de gestión de infraestructura como env0 permiten aplicar políticas de aprobación en el momento de despliegue para impedir la creación de claves permanentes no autorizadas. Estas políticas se aplican sobre planes de Terraform o OpenTofu y bloquean recursos relacionados con claves de acceso en AWS, Google Cloud o Azure, entre otros.
Sin embargo, estas políticas solo son efectivas durante el despliegue si se gestionan con env0; no pueden controlar las claves generadas manualmente en consolas, scripts externos o tareas fuera de env0. Por ello, deben complementarse con mecanismos nativos de IAM en cada plataforma que limiten y auditen la creación y uso de claves.
Se recomienda también el uso de federación y credenciales temporales. Por ejemplo, AWS ofrece roles con credenciales temporales que expiran al cerrar la sesión, limitando la persistencia de accesos.
3. Asignar un tiempo de vida limitado a cada clave
AWS no impone fecha de caducidad a las claves IAM de usuario, por lo que su vida útil debe ser controlada externamente. Para claves gestionadas mediante Terraform, un tiempo de vida definido para el entorno puede servir para programar la destrucción automática de las credenciales. Sin embargo, el tiempo de vida configurado no garantiza la expiración efectiva de la clave, ya que si la destrucción falla o la clave se crea manualmente, permanecerá activa.
La verdadera verificación debe hacerse a través de auditorías que confirmen la revocación efectiva, no solo confiar en el contador de tiempo. Además, estas políticas no limitan a los administradores que pueden extender o eliminar el límite a su conveniencia.
En entornos gratuitos, como el plan Free de env0, existen limitaciones que pueden causar que las claves sobrepasen su tiempo previsto, ya que una vez superadas ciertas ejecuciones por mes, los TTL se anulan temporalmente, alargando la vigencia de las credenciales.
Para claves fuera del control del ciclo de vida de algún entorno, es imprescindible retirarlas manualmente siguiendo un procedimiento controlado: identificar la clave, verificar última actividad y propietario, desactivarla para probar que ningún proceso se vea afectado, y finalmente eliminarla.
Ejemplos de comandos AWS CLI para gestionar esta operación incluyen listar las claves de un usuario, verificar la última fecha de uso y actualizar el estado a Inactivo.
Es importante tener en cuenta que la desactivación se puede revertir, pero eliminar la clave es definitivo y requiere aprobaciones formales para evitar interrupciones inesperadas en aplicaciones que aún dependan de esas credenciales.
El riesgo latente de no jerarquizar la caducidad de las credenciales
Un recurso sin propietario cuesta dinero hasta que alguien se da cuenta. Pero una credencial sin dueño puede otorgar acceso indebido a cualquier persona que la encuentre, incluso sin estar identificada como ‘huérfana’.
“Una clave antigua no necesita estar etiquetada como huérfana para que un atacante la utilice; solo necesita estar activa.”
Los agentes que concluyeron proyectos pasados no suelen marcar o desactivar sus claves, y el siguiente agente que las encuentre podría no pertenecer a la organización. La gestión efectiva, la asignación clara de responsabilidades y la supervisión continua son por tanto esenciales para minimizar los riesgos.
En resumen, la gobernanza del ciclo de vida de las credenciales de agentes AI y otros usuarios es vital para proteger la seguridad en entornos cloud modernos. Sus riesgos superan con creces el desperdicio económico: hablamos de puertas abiertas al mundo exterior que pueden comprometer simultáneamente múltiples sistemas en minutos si se ignoran.
