The Keys Have Been Public for Four Years. They Still Work.

On August 10, researchers at Truffle Security re-tested 10,616 Amazon Web Services access keys that had leaked into public view over the past four years — sitting in code repositories, Docker images, published AI datasets, and build logs where anyone could find them. Eighty-eight percent still worked.

That is more than 9,300 live keys, catalogued in public since as far back as August 2022. Among the keys traceable to companies, 526 were root keys, and 768 granted full administrative control of a corporate AWS account — the power to read every database, delete every backup, and quietly create new administrator accounts that survive after the original leak is cleaned up. The oldest key in the dataset had existed for 17.4 years.

Nobody had to hack anything.

What a Leaked Key Actually Means

If you sit on a board or run a P&L, here is the translation. An AWS access key is a password for software. It works without the second-factor prompt your own login requires, and whoever holds it becomes your infrastructure — with whatever privileges that key carries. A root key sits above every permission control your security team has built. Amazon's own best-practice guidance says root access keys shouldn't exist at all.

In my experience, executives hear "cloud breach" and picture a sophisticated adversary defeating expensive defenses. What actually happens looks more like this: a developer pastes a key into a configuration file, the file lands in a public repository or a published dataset, and the key sits there — still valid, still privileged — for five years. Then someone finds it. Truffle Security found these keys with automated scanners. Attackers run the same scanners.

The same week made the point twice. On August 18, a dataset appeared for free on a criminal data-trading forum: live Stripe secret keys for 659 merchant accounts, bundled with roughly 35 gigabytes of customer and payment data — reportedly about 688,000 customer records. Stripe's own systems were not compromised; the merchants leaked their own keys through infostealer infections and exposed configuration files. According to the researchers who examined the dataset and alerted Stripe, 519 of those accounts could both take payments and send payouts. That is direct theft capability, published free of charge.

Your Policy Says 90 Days. The Data Says Never.

Nearly every organization I've audited or advised has a credential rotation policy on paper. It's in the SOC 2 report. The auditor confirms the policy exists, samples a few accounts, and signs off. Nobody in that process googles your keys.

Now put the paperwork against Truffle Security's numbers. Among leaked keys with a known creation date, the median age was 1,831 days — about five years. Only 13.7 percent had a newer replacement key on the same account, which is the researchers' marker for whether a key has ever been rotated in its life. The policy says 90 days. The evidence says never.

This is the gap I wrote Cyber Risk Is Business Risk to expose: compliance tells you a control is documented. Security is whether the control actually operates. A rotation policy nobody verifies is a comfort object, not a control.

The Biggest Single Source Was the AI Pipeline

Here's the detail that should get your attention if your company is racing to ship AI. The largest single source of leaked keys was not a traditional code repository. It was Hugging Face, the platform where developers share AI models and datasets — 8,482 exposed keys, and 17.9 percent of them were root.

The pattern makes sense once you see it. Data science teams move fast, and publishing datasets is part of the job. Credentials get embedded along the way. Your AI governance program — the sheriff, as I call it in the book — has probably been focused on model behavior and hallucination risk. The sheriff also needs to inspect what your AI teams push out the door, because right now the AI pipeline is a leading exporter of corporate cloud credentials.

One more number. Of the AWS accounts whose settings the researchers could read, only 262 out of 2,754 had a budget alert configured. Attackers who find valid keys routinely deploy cryptominers and run up enormous compute bills before anyone notices. A budget alert is free, and fewer than one in ten accounts had one.

What to Ask Your CISO This Week

Five questions, all answerable with numbers, none requiring a technical background:

1. How many of our cloud access keys are older than one year? Ask for the count itself. If the answer is "we'd have to check," that is the answer.
2. Do any root access keys exist in our accounts? The acceptable number is zero.
3. What scans our code, containers, datasets, and build logs for leaked secrets — before publication and continuously afterward? If the answer only covers your own repositories, it misses where these keys actually surfaced.
4. When a key leaks, how fast can we revoke it? The answer should be measured in hours, and someone should be able to tell you when that was last tested.
5. Does every cloud account have a budget alert? It is the cheapest breach detector you will ever deploy.

Truffle Security says it notified every credential owner it could identify, and Amazon says it applies quarantine policies when exposed keys are reported. If your company received one of those notifications, your security team already knows — ask them what happened next. If nobody can tell you whether you received one, that's your first question for Monday morning.