Encontrar credenciales filtradas es un problema resuelto. Truffle Security lleva cuatro años en ello y tiene 431.875 hallazgos de AWS que enseñar. La mitad sin resolver es el paso siguiente, ese en el que alguien tiene que entrar y borrar la clave. Eso ocurre una vez de cada siete.

Truffle Security publicó un censo esta semana, y BleepingComputer lo recogió el jueves. Desde agosto de 2022 la empresa recoge claves de acceso de AWS en los sitios donde aparecen en público: historial de git, datasets de Hugging Face, imágenes Docker, registros de paquetes, logs de CI. Después comprueba si siguen funcionando.

El informe cuenta 431.875 hallazgos verificados de AWS, deduplicados a 64.024 claves de acceso únicas repartidas en 50.654 cuentas distintas. De ellas, 10.616 pares traían material suficiente para volver a probarse. El ochenta y ocho por ciento sigue autenticándose. Son 9.308 claves, vivas hoy, que cualquiera pudo recoger de una superficie pública en algún momento de los últimos cuatro años.

Mantuvieron la verificación estrecha, con llamadas de metadatos de solo lectura: sts:GetCallerIdentity, iam:ListAccessKeys, enumeración de nombres de políticas, una lectura de presupuesto, una llamada a Cost Explorer por cuenta. No leyeron ningún dato ni cambiaron nada, y avisaron a 10.260 de los 10.616 propietarios antes de publicar.

Fíjate ahora en la edad de las claves.

Cinco años, y subiendo

La clave mediana que aún funciona tiene 1.831 días. La más antigua, 17,4 años. Solo 25 claves del conjunto, nueve décimas de un uno por ciento, son de los últimos treinta días.

Esa distribución describe un sedimento, no un caudal de accidentes recientes que se pillan y se limpian. Una clave se filtra y sigue filtrada, porque una clave de acceso estática de AWS no caduca: no hay reloj, no hay renovación, no hay certificado que se ponga rancio a los dieciocho meses. Funciona hasta que alguien abre la consola y la borra. Truffle midió con qué frecuencia aparece ese alguien. De los usuarios cuyas claves los investigadores pudieron enumerar, 398 de 2.903 tienen una clave más reciente junto a la filtrada, es decir un 13,7%. Los 2.505 restantes nunca la rotaron.

Tampoco se puede culpar al paso de detección, porque Amazon ya había hecho el descubrimiento. Cuando AWS detecta una de sus propias claves en público, aplica al usuario una política llamada AWSCompromisedKeyQuarantine, restringe lo que la clave puede hacer y manda un correo a la cuenta. Nadie tiene que pedírselo. Truffle encontró 929 usuarios IAM, el 12% de los 7.590 activos, con esa política puesta ahora mismo. Ciento doce de ellos llevan la versión original, así que AWS los marcó hace al menos tres años y siguen respondiendo.

La detección funcionó, el correo salió, y tres años después la clave sigue siendo buena.

Una clave de acceso estática de AWS no caduca, así que una filtración no tiene fecha de fin. Lo único que la cierra es una persona borrando la clave, y a lo largo de 2.903 usuarios enumerables eso ocurrió el 13,7% de las veces, incluidos los 929 usuarios a los que la propia AWS había marcado y puesto en cuarentena.

La superficie de filtración se mudó a un sitio sin botón de borrar

La mayor fuente individual de todo el censo es Hugging Face: 8.482 claves vivas únicas repartidas en 3.394 datasets, y una tasa de claves root del 17,9%, muy por encima del resto de la población.

Truffle ya había medido el otro extremo de esa tubería. En junio el equipo clonó todos los datasets públicos de Hugging Face: 186,9 millones de archivos únicos, 7,6 petabytes, unos 815.000 repositorios de datasets. Aplanaron Parquet, Arrow, JSONL y archivos comprimidos a texto escaneable y verificaron todo lo que encontraron. El resultado fueron 221.303 credenciales vivas y únicas en 6.003 datasets: 11.496 claves de proveedores de IA, 8.557 claves de cuentas de servicio de Google Cloud en 3.811 proyectos, 8.594 accesos a bases de datos que funcionan, 3.343 claves de AWS que pasan una comprobación de identidad STS, 349 tokens de acceso personal de GitHub, de los cuales 223 pueden hacer push de código y 130 reescribir workflows de CI.

Dos de sus ejemplos muestran hasta dónde viaja un solo error. Alguien pegó la clave de AWS de una fintech brasileña en un chatbot, y ahora aparece replicada unas dieciocho veces en distintos corpus. Una clave de Infura capturada del mismo modo acabó en 1.131 datasets y 10.162 ubicaciones de archivo distintas. El cuarenta y cuatro por ciento de los secretos vivos únicos que encontró Truffle aparece en más de un dataset.

Después la gente entrena con esos datasets. Los datos de entrenamiento documentados de StarCoder contienen 25.217 de estas claves; Swallow, 22.484; OLMo 3, 21.278. Los grandes modelos propietarios mantienen sus corpus en privado, así que nadie de fuera lo sabe.

Truffle saca la conclusión sin rodeos: la rotación sigue siendo el único arreglo, porque nadie puede volver atrás y limpiar datos de entrenamiento. Da por quemada cualquier clave que alguna vez llegara a un repositorio público, a una página web o a un chatbot.

Una credencial que llega a un dataset público no se puede retirar. Truffle encontró un 44% de los secretos vivos duplicados entre corpus, una clave de Infura en 1.131 datasets, y decenas de miles de claves que funcionan dentro de los datos de entrenamiento documentados de modelos abiertos. Borrar el archivo original no cambia nada aguas abajo.

Cada fuente de esa lista es algo que escribe un agente

Mira otra vez dónde fue Truffle a comprar: historial de git, imágenes Docker, registros de paquetes, logs de CI, subidas de datasets. Eso son salidas de build, y son los artefactos que un agente de programación produce ahora sin supervisión, de madrugada, a un ritmo que ningún equipo podría revisar.

Un agente que despacha un backlog mientras duermes escribe commits, reescribe lockfiles, construye imágenes, hace push de ramas y llena logs. Cada una de esas cosas es una superficie de publicación, y el agente tiene tu ~/.aws/credentials al alcance todo el rato, porque así es como el SDK está diseñado para encontrarlo.

Los agentes de programación escriben esos artefactos más rápido que ninguna herramienta anterior, y el 13,7% no se ha movido.

La mitad que firma se queda en tu Mac

Bromure Agentic Coding ejecuta el agente en una VM Ubuntu desechable sobre el framework Virtualization de Apple, con un proxy del lado del anfitrión como única salida. AWS exige un tratamiento propio en ese diseño. SigV4 nunca pone el secreto en el cable, ya que el SDK lo consume en el proceso para calcular un HMAC, así que un proxy no tiene nada que sustituir en tránsito. Bromure mueve entonces la firma.

Dentro de la VM, ~/.aws/config señala a un ayudante credential_process. Cuando el SDK pide credenciales, el ayudante devuelve el identificador de clave de acceso real emparejado con un secreto falso de cuarenta caracteres, acuñado de nuevo en cada sesión. El identificador de clave de acceso es un identificador, no un secreto, y es la mitad que dice qué usuario IAM está llamando. La clave de acceso secreta es la mitad que firma, y no entra jamás en el espacio de direcciones de la VM. Bromure ni siquiera exporta AWS_ACCESS_KEY_ID ni AWS_SECRET_ACCESS_KEY al entorno del invitado, con el argumento de que las variables de entorno se escapan por /proc, ps -E y el historial del shell. La VM recibe una cadena de región y nada más.

El SDK firma una petición cuya firma no puede ser correcta. A la salida, el anfitrión retira esa firma y vuelve a calcular SigV4 con el material real. aws, boto3 y terraform funcionan como siempre. Todo lo que rodee el proxy recibe un InvalidSignatureException de Amazon, que es justo el fallo que quieres.

Ahora pasa un workspace de Bromure por la metodología de Truffle. Su listón para contar una clave es un sts:GetCallerIdentity firmado que vuelve válido. Supón que una dependencia comprometida cosecha el archivo de credenciales de ese invitado, o que convencen al agente de hacerle cat, o que un build lo mete en un bundle público. Lo que sale es un identificador y cuarenta caracteres que nunca fueron el secreto. Falla el día en que se filtra, así que nunca se suma a la capa de sedimento y no hay una cola de cinco años detrás.

Eso también elimina el paso de rotación que espera a un humano. El secreto real vive en un solo sitio, en tu Mac, en el panel de Credenciales del perfil. Cámbialo ahí y la siguiente sesión lo recoge. Nadie tiene que averiguar cuál de noventa ejecuciones nocturnas escribió qué artefacto.

Credenciales de AWS en un workspace de Bromure: el identificador de clave de acceso identifica a quien llama y llega a la VM, la clave de acceso secreta firma y no llega. El invitado firma una petición condenada a fallar, el anfitrión la vuelve a firmar con el material real, y lo que se coseche de la VM falla la misma comprobación STS que usó el censo para contar claves vivas.

Una petición firmada más estrecha que la clave que la firma

El otro titular del censo es el alcance. De 817 claves ligadas a una empresa, 768 daban el control total de la cuenta: 526 claves root y 242 usuarios IAM con AdministratorAccess. Ciento treinta de esas claves root están en cuentas de gestión de organización, la cuenta que gobierna todas las cuentas miembro de la organización. Entre los usuarios que los investigadores pudieron enumerar, 976 tenían AdministratorAccess, es decir, un 84%.

Son claves acuñadas por comodidad, hace años, para una tarea que necesitaba tres permisos.

El ajuste Guardrails de Bromure estrecha la credencial en el punto de uso, para que nunca tengas que acordarte de estrecharla en el origen. Es un motor de políticas del lado del anfitrión, dentro del proxy. Para AWS lee el nombre de la acción de la cabecera X-Amz-Target en los servicios con protocolo JSON como DynamoDB y Lambda, o del parámetro Action= en los servicios con protocolo query como EC2, IAM y SQS, y recurre al método HTTP en el caso de S3. Delete*, Terminate*, Remove*, Purge* y Destroy* se clasifican como destructivas; Get*, List* y Describe*, como lecturas. Pon el perfil en Solo lectura y una mutación vuelve como un 403 seco que el agente lee como un fallo de API cualquiera. Ponlo en Bloquear destructivas y las creaciones y actualizaciones pasan, pero los borrados no.

Esto lo impone tu Mac, no la VM, así que un agente al que han convencido de algo no puede discutir hasta colarse. La credencial con la que firma tu anfitrión acaba siendo más estrecha que la credencial misma, lo cual vale la pena en una población donde el 84% de los usuarios enumerables tenía permisos de administrador.

El registro aparece antes que la factura

Un número más del informe. De las 2.754 cuentas cuyos presupuestos pudieron leer los investigadores, 262 tienen siquiera una alerta de presupuesto configurada, es decir un 9,5%, con un límite mediano de ocho dólares. Ese mismo conjunto gastó 420.631 dólares en julio, con cincuenta cuentas por encima de 1.000 dólares y nueve por encima de 10.000. La mayoría de esos propietarios conocerá a su intruso en una factura.

Bromure escribe el registro mientras el trabajo ocurre. Cada petición que el anfitrión firma emite una fila credential.aws_sign en Ventana → Cronología de seguridad, con el servicio, el método, el host, la región y el identificador de clave de acceso enmascarado, junto a las descargas de paquetes, los veredictos del cortafuegos y los intercambios de credenciales. Bromure guarda ese log en el Mac, donde nada de dentro de la VM puede editarlo. Para la versión más estricta, AWS → Exigir aprobación para usar convierte cada llamada de firma en una petición de consentimiento con un permiso acotado en el tiempo, de forma que una tarde de trabajo de verdad pregunta una sola vez.

Bromure aplica la misma idea un paso antes, cuando levantas un perfil por primera vez. Pasa la configuración de agente que importas por una fase de redacción: JSON, TOML y YAML estructurados filtrados por nombre de clave, con coincidencia en token, secret, password, apikey, credential, authorization, private_key y access_key, y texto corrido filtrado por forma del token, con coincidencia en AKIA, ASIA, sk-ant-, ghp_, glpat-, AIza y npm_. Sean cuales sean los secretos reales que haya en los dotfiles de tu Mac, no se suben a la VM con el resto de la configuración.

Lo que demuestra el censo

Truffle Security lo hizo bien: llamadas de solo lectura, ningún dato tocado, 10.260 de 10.616 propietarios avisados antes de publicar. AWS sale de esto mejor de lo que sugiere el titular, ya que la política de cuarentena es Amazon encontrando sus propias claves filtradas y avisando al dueño sin que nadie se lo pida. Ambas mitades del sistema de detección hicieron su trabajo.

El resultado siguieron siendo 9.308 claves vivas con una edad mediana de cinco años, y una tasa de rotación del 13,7%.

El control que falla le pide a una persona que complete una tarea pesada meses o años después del error, en un sistema que quizá ya ni sea suyo, por una clave que no da ninguna señal de ser un problema. Los controles con esa forma fallan a escala, y ya fallaban antes de que nada se pusiera a escribir commits de madrugada.

Así que deja de pedirle a la tarea pesada que aguante todo el peso. Pon en el workspace una credencial que nunca fue la credencial, y el censo se queda sin nada que contar, el corpus sin nada que replicar, y la cola de cinco años es de otro.

Fuentes: Truffle Security, “Leaked Corporate AWS Keys Held Full Admin Rights” (19 de agosto de 2026) · Truffle Security, “Scanning 7.6 Petabytes of HuggingFace Training Data for Secrets” (1 de junio de 2026) · Truffle Security, “Introducing TruffleHog AWS Analyze” (20 de agosto de 2026) · BleepingComputer, “Hundreds of leaked AWS keys give full control over corporate accounts” (21 de agosto de 2026) · Cybernews, “Massive exposure: researchers test leaked AWS keys, 9 out of 10 still authenticate” (21 de agosto de 2026)