No se pirateó nada. Se lo llevaron todo.

Déle a un agente de IA una clave de AWS filtrada —del tipo de privilegios bajos y desechable que un pipeline de CI vierte cada semana— y dígale que se lleve todo lo que pueda alcanzar. Después, aléjese. Lo más habitual es que, alrededor de un minuto después y sin nadie al teclado, esté leyendo los datos de sus clientes.

No se pirateó nada para llegar ahí. Ni exploits, ni CVE, ni servidores sin parchear. Todas las credenciales que tocó eran válidas; cada llamada a la API era una que AWS está diseñado para responder. Durante treinta años, una clave filtrada fue solo el inicio de un ataque —la parte lenta para la que un ser humano tenía que estar despierto, el hueco en el que viven los equipos de seguridad y donde una rotación rápida gana la carrera—. Ese hueco acaba de reducirse a unos sesenta segundos.

En mayo de 2026, un investigador llamado Adan Álvarez realizó una prueba sencilla. Tomó una única clave de AWS de privilegios bajos —del tipo que un pipeline de CI/CD filtra continuamente— y se la entregó a un agente de programación de IA con una única instrucción: actúa como pentester y encuentra todo lo que puedas alcanzar. A partir de ahí, ningún ser humano al teclado. El agente hizo el resto. En más de la mitad de los casos, recorrió la cadena completa hasta los datos de clientes —en aproximadamente un minuto, sin supervisión—.

Qué ocurrió realmente

La configuración era deliberadamente corriente. La clave filtrada pertenecía a un usuario de compilación de privilegios bajos. Por sí sola, no podía tocar los datos de clientes. Pero podía leer un fichero de estado de Terraform. Ese fichero de estado contenía un segundo juego de claves. Esas claves podían asumir un rol. Ese rol podía leer el bucket de clientes.

Así es como está configurada casi toda cuenta real en la nube: no una única muralla, sino una cadena de relaciones de confianza pequeñas y razonables, donde cada eslabón tiene sentido por sí mismo. Un atacante humano desenreda esa cadena despacio, a mano. El agente la desenredó en unos sesenta segundos.

Las ejecuciones exitosas siguieron siempre los mismos seis pasos: confirmar a quién pertenece la clave, enumerar lo que tiene permitido hacer, recuperar el segundo juego de credenciales del bucket de staging, asumir el rol privilegiado, localizar los datos y llevarlos. En doce ejecuciones con dos modelos, siete llegaron a la exfiltración. La mayoría terminó en aproximadamente un minuto [1].

Y esto no es solo un resultado de laboratorio. En noviembre de 2025, el equipo de investigación de amenazas de Sysdig observó la misma forma de ataque en producción: claves de AWS válidas expuestas en un bucket público, una función Lambda reescrita discretamente para generar credenciales administrativas, movimiento lateral a través de diecinueve identidades distintas —todo en ocho minutos— [2][3]. El código inyectado llevaba las huellas de un modelo: manejo de excepciones ordenado, lógica iterativa de selección de objetivos, comentarios en más de un idioma.

Esto no es una debilidad de AWS

Esta es la parte que debería quitarle el sueño: no se pirateó nada.

Ni exploits, ni CVE. Ni desbordamiento de búfer, ni servidores sin parchear. Toda credencial era válida. Cada llamada a la API era una que AWS está diseñado para responder. En palabras de Sysdig, las credenciales eran legítimas y las API se usaron exactamente como estaban previstas [3]. AWS hizo su trabajo a la perfección.

La suposición que se rompió no era la seguridad de AWS. Era otra más antigua y silenciosa que había debajo: que una clave filtrada solo es tan peligrosa como la atención que un atacante pueda dedicarle. Durante treinta años eso se cumplió. Explotar una credencial requería un ser humano: tiempo, habilidad, paciencia. Ese coste formaba parte real de su defensa, aunque nadie lo dibujara en el diagrama de arquitectura.

Los agentes reducen ese coste aproximadamente a cero. La paciencia es infinita. La habilidad se alquila por minutos. El atacante puede estar dormido.

No se limita a AWS

Nada de esto es específico de Amazon. La misma cadena se reproduce allí donde una credencial puede usarse para descubrir la siguiente credencial: una clave de la nube que puede enumerar sus propios permisos, un token en un fichero .env que otro proceso puede leer, un secreto en un fichero de estado, un token de un almacén de secretos que reposa en disco junto al código. Cualquier entorno —un agente de programación, un servidor MCP que instaló la semana pasada— puede ser el que recorra la cadena, con o sin su permiso.

El hilo común es que el secreto arrastra su propio radio de alcance. Puede leerse donde ocurre el trabajo, puede enumerar lo que toca y funciona desde cualquier lugar. Esas tres propiedades eran soportables cuando los ataques eran lentos y manuales. No lo son a velocidad de agente.

Diseñado para esto, a propósito

Así que construimos lo contrario, deliberadamente.

Una credencial de Clavitor solo es accesible mediante el nombre que se dio al agente: no puede enumerar el almacén, por lo que no puede trazar el mapa. El valor del secreto nunca llega donde se ejecuta el código; el agente obtiene el resultado de usar la credencial, no la credencial en sí. Cada una está vinculada a la máquina y al ámbito para los que se emitió, de modo que una copia llevada a un portátil no sirve de nada. Y cada solicitud queda registrada en un registro inmutable, encadenado por hash y fuera del endpoint —la evidencia que piden la Requisito 10 de PCI DSS y NIST 800-171 (3.3.8)—, de manera que incluso una acción perfectamente «válida» tiene un nombre asociado.

Hablemos con franqueza: esto no convierte una credencial filtrada en algo inofensivo. Limite el ámbito de una clave a un solo bucket y, si esa clave se filtra, un atacante obtendrá ese único bucket. Lo que se elimina es la cadena: esa parte en la que una clave corriente se convierte en el mapa de todo lo demás. Ámbito acotado frente a ámbito ambiental no es la diferencia entre estar a salvo y estar comprometido. Es la diferencia entre un incidente y una catástrofe.

Hemos anotado el puñado de reglas que una herramienta de credenciales debería respetar si quiere sobrevivir a esto. Puede contrastar la suya con ellas en clavitor.ai/rules.

La lección no es «rotar más rápido»

No se puede superar por rotación un ataque de sesenta segundos. Para cuando se activa el canario, la cadena ya se ha ejecutado.

La conclusión no es un ejercicio de limpieza más estricto. Es que la economía se ha invertido. Construimos sistemas de credenciales para un mundo en el que el tiempo del atacante era escaso y caro —uno en el que una clave filtrada era una carrera que podía ganar—. Ese mundo ya no existe. Una credencial capaz de encontrar la siguiente credencial ya no es una comodidad. Es el ataque entero, preescrito, esperando a que caiga cualquier clave.

Construya para el mundo donde el atacante nunca duerme. Ya está aquí.

Clavitor (@clavitorai) es el almacén de credenciales construido para agentes de IA, y contra ellos. clavitor.ai

Fuentes

[1] Adan Alvarez — «From Leaked AWS Key to Data Exfiltration in 60 Seconds: Are We Ready?» (mayo de 2026) — https://medium.com/@adan.alvarez/from-leaked-aws-key-to-data-exfiltration-in-60-seconds-are-we-ready-28213bc73678

[2] CSO Online — «From credentials to cloud admin in 8 minutes: AI supercharges AWS attack chain» — https://www.csoonline.com/article/4126336/from-credentials-to-cloud-admin-in-8-minutes-ai-supercharges-aws-attack-chain.html

[3] Vectra AI — «AWS Compromised by AI Agents in Minutes» (Alex Groyz) — https://www.vectra.ai/blog/aws-compromised-by-ai-agents-in-minutes

[4] Help Net Security — «The shocking speed of AWS key exploitation» — https://www.helpnetsecurity.com/2024/12/02/revoke-exposed-aws-keys/