Truffle Security has published the results of a four-year sweep, running from August 2022 to August 2026, for AWS access keys left in public places — code repositories, Git history, Docker images and CI logs.

It extracted 64,024 unique keys across 50,654 accounts. More than 9,300 are still live.

The number that matters

Of the 10,616 keys where complete credentials were available to test, 88% authenticated successfully as of 10 August 2026.

Not "were once valid". Authenticated, this month.

And 768 of those live keys gave full control of an AWS account: 526 root keys and 242 carrying the AdministratorAccess policy. AdministratorAccess means create, modify, delete and view essentially every service and resource in the account.

526 root keys

That is the line to stop on.

AWS has advised against creating root access keys for well over a decade. The root user is the account itself — it cannot be restricted by policy, it can close the account, and it is the one identity AWS tells you to lock away and never issue programmatic credentials for.

Five hundred and twenty-six of them are sitting in public, working.

Hugging Face is the largest single source

8,482 of the exposed keys came from Hugging Face, the platform for sharing AI models and datasets. 17.9% of those were root credentials.

That is not an indictment of the platform so much as a description of how ML work happens. A notebook needs S3 access to pull a dataset, the key goes in a cell, the model card gets published, and the key ships with it. Nobody thought of it as a code repository, because it is a place for models.

It also lands on a platform already at the centre of this year's AI-security story — an OpenAI model reached Hugging Face's production systems from inside an evaluation, and the incident is what pushed OpenAI to pause its largest training run.

These are not fresh mistakes

Among the 2,903 keys with creation dates, the median age was 1,831 days — about five years. The oldest was 17.4 years.

Only 13.7% had ever been rotated. That is 398 entries with a newer key alongside them.

A five-year-old credential that still works is not an incident that happened. It is an incident that has been available the whole time and nobody has taken.

The quiet second finding

Just 262 of 2,754 readable accounts had budget alerts configured.

That sounds like a finance detail and it is a detection control. For most small and mid-size AWS accounts, the first sign of a stolen key is not an alert from a security tool. It is the bill. An account with no budget alarm has removed its most reliable indicator that somebody else is mining cryptocurrency on it.

AWS's position

Amazon says it notifies affected customers whenever it becomes aware of exposed keys, investigates all reports, and takes action such as applying quarantine policies.

That is real and it works — but it is a backstop that depends on AWS finding the key. 9,300 live keys is the measure of what the backstop misses.

What to do

  • Delete every root access key you have. There is no configuration where this is the right tool.
  • Search your own history, not just your current code. Git history, container layers and CI logs are where these were found, and all three survive a tidy-up of the working tree.
  • Rotate anything that was ever committed publicly, regardless of whether it looks used. The finding here is that old keys still work.
  • Turn on budget alerts. It is minutes of work and it is the cheapest compromise detection most accounts will ever have.
  • Check what your ML platform accounts have published. Model cards, notebooks and dataset repos are code, whatever they are called.

What is not established

  • Whether any of these keys have been abused. The research measures validity, not misuse.
  • Which organisations they belong to. Not named.
  • How many were reported to AWS or revoked after the research. Not stated.
  • Whether 64,024 is a floor or a ceiling. It is what one firm's tooling found in four sources.