tl;dr We re-verified 10,616 leaked AWS keys on August 10, 2026. They surfaced publicly between August 2022 and August 2026. 88% still authenticate. 768 of the live ones belong to a company and carry full control of its AWS account: 526 root keys plus 242 IAM users holding AdministratorAccess. The median live leaked key is five years old and has never been rotated.

We are launching this research in coordination with our launch of TruffleHog AWS Analyze, which you can read about here.

Our scanners have verified 64,024 unique AWS key pairs across 431,875 public findings: git history, Hugging Face datasets, Docker images, package registries, CI logs. These keys surfaced publicly between August 2022 and August 2026. We took the 10,616 pairs with complete credentials and re-verified them, then enumerated what each key can tell us about its account: key age, attached policies, budgets, and last month's spend. No key material is published, and every owner we could identify is being notified.

64,024 keys. 1 in 6 is root.

Every key in this population was verified live when our scanners first found it. AWS returns the principal type at verification time, so the split is precise: 10,625 root keys (16.6%) across 9,945 distinct accounts. A root key cannot be scoped down. It is the account, including the ability to close it.

64,024 unique verified AWS keys. 10,625 root, 48,744 IAM user, 4,655 not classifiable at verification time.

The largest single source is Hugging Face. AWS credentials are the second most common secret type we verify there, with 8,482 unique live keys across 3,394 public datasets. Hugging Face keys also skew privileged: 17.9% are root, the highest share of any source we track. Most of those datasets are snapshots of public code repackaged for training. A key committed once ends up tokenized into corpora that thousands of downstream projects download.

The median live leaked key is 5 years old

For the 2,903 keys that permitted iam:ListAccessKeys, AWS reports the exact creation date. The median live leaked key was created 1,831 days ago. Half are over five years old. The oldest is 17.4 years, nearly as old as IAM itself.

Only 25 keys (0.9%) were created in the last 30 days. Almost none of this population leaked recently. The count has been building for years.

Rotation is the rarer event. Of the keys where we could enumerate the user's access keys, only 13.7% (398 of 2,903) have any newer key alongside the leaked one. The other 86% were never rotated, superseded, or cleaned up.

What the keys can do

For the 7,590 active IAM user keys we attempted to enumerate attached managed and group policies, names only, never policy documents. 1,157 users permitted it. 976 of those (84%) hold AdministratorAccess directly or through a group, and another 144 hold IAMFullAccess. Most leaked IAM users in this set are admin accounts.

Most common managed policies attached to leaked IAM users. Enumerable skews toward quarantined and admin users because both can read IAM, so treat the rates as directional and the counts as exact.

Separately, 929 of the 7,590 active IAM users (12%) carry AWS's own AWSCompromisedKeyQuarantine policy. AWS detected those keys as exposed and restricted them. 112 carry the original version, which AWS stopped applying in 2023, so those were flagged at least three years ago and their owners were notified by AWS. They still authenticate. AWS detected the exposure. Nobody acted on it.

768 of them belong to companies

Root keys and permissive IAM users can read the account's registered contact information. Combining that with username patterns, we classified the 9,308 active keys and found 817 business-linked keys.

Ownership of still-active keys by principal type. Corporate means a real company name in the account contact or a non-webmail org domain.

Crossing ownership against privilege produces the headline number. Of those 817 business-linked keys, 526 are root and another 242 hold AdministratorAccess on an IAM user. The two sets do not overlap, so 768 live keys give full control of a company AWS account. The remaining 49 are scoped below admin. Sector skews toward software, cloud, and IT consulting, including one global consultancy with 19 distinct leaked keys across separate accounts.

At the far end sit 130 live root keys on organization management accounts, the account that controls every member account in the org. One compromised management root exposes every account in the org at once.

9.5% have a billing alarm. The rest have no ceiling.

2,754 keys could read budgets and 1,059 could read Cost Explorer. Only 262 accounts (9.5% of readable) have any budget alert at all. The median configured limit is $8, the classic free-tier guardrail.

Median spend was $0.03. The tail is what matters: 50 accounts spent over $1k last month, 9 spent over $10k, and the readable set spent $420,631 in July alone.

The typical leaked key opens an abandoned experiment that costs its owner nothing, which is why it never gets rotated. The tail opens production.

What to do with this

• Delete root access keys. 1 in 6 leaked keys is root. There is no legitimate reason for a root access key to exist in 2026. Check every account you own, including the personal one from 2019.

• Sort your IAM keys by age. The median leaked key was five years old and had never been rotated. aws iam list-access-keys plus a maximum age policy catches the entire failure mode.

• Set a budget alarm, even a small one. 90.5% of leaked-key accounts have none. A $10 alert costs nothing and catches cryptomining early.

• Assume committed means leaked. 43% of keys in our population were sighted more than once across repos, datasets, and images. Deleting the file does not help once it is in a training corpus.

• Watch for the quarantine policy. If AWS attaches AWSCompromisedKeyQuarantine to one of your users, that is AWS telling you the key is public.

Knowing this about your own org

Everything above is what leaked credentials reveal from the outside. Getting there took read-only IAM calls against one key at a time, which is the same manual work a responder does after every alert.

That is the job we built TruffleHog AWS Analyze to do. It resolves the IAM principal behind a leaked key, pulls the managed and inline policies attached to the user, the groups, and the roles, then follows trust policies one hop further to show which roles that key can reach. The 768 corporate keys above are the outside view of that question. AWS Analyze answers it for your own org, before someone else does.

The launch post walks through the full workflow: Introducing TruffleHog AWS Analyze: Know What a Leaked AWS Key Can Reach.

Method and ethics. Population: 431,875 verified AWS findings deduplicated to 64,024 unique access keys across 50,654 accounts. Re-verification used read-only metadata calls only: STS GetCallerIdentity, IAM ListAccessKeys, IAM policy-name enumeration, Account GetContactInformation, Organizations Describe and ListAccounts, Budgets DescribeBudgets, and one Cost Explorer call per account. No policy documents, resources, or data were read. Nothing was modified. Aggregate figures only; no key material, account identifiers, or personal details are published. Every owner we could identify (10,260 of 10,616 re-checked keys) is being notified ahead of publication.