Notified And Ignored

Most security failures are stories about something nobody saw. This one is the opposite. The exposure was found, catalogued and in many cases flagged by the cloud provider itself, which then told the account owner. Some of those owners were told three years ago. The credentials still work today. Truffle Security published the numbers on 19 August, and the uncomfortable part is not the leak. It is that every control in the chain fired correctly and nothing happened next.

What happened

Truffle Security has spent four years tracking AWS access keys that end up in public places: git history, Docker images, package registries, CI logs and public datasets on Hugging Face. Its scanners have verified 64,024 unique AWS key pairs across 431,875 public sightings, spanning 50,654 accounts. Those keys surfaced publicly between August 2022 and August 2026.

On 10 August 2026 the researchers took the 10,616 key pairs for which they held complete credentials and re-tested them, using read-only metadata calls and nothing else. 88% still authenticated. The team then enumerated what each live key could reveal about its own account: the age of the credential, the policies attached to it, whether any budget alert existed, and what the account had spent in the previous month.

Within that live population, 817 keys could be tied to an identifiable company. Of those, 526 were root keys, the credential that cannot be scoped down and that carries the ability to close the account itself, and a further 242 belonged to IAM users holding the AdministratorAccess policy. The two sets do not overlap. That is 768 live credentials, each one full control of a corporate cloud estate. The remaining 49 were scoped below administrator. Sector skew ran towards software, cloud and IT consulting, including one global consultancy with 19 distinct leaked keys across separate accounts.

At the far end of the distribution sit 130 live root keys on organisation management accounts, the account that governs every member account beneath it. One compromised management root exposes an entire organisation at once.

BleepingComputer reported the findings on 21 August. On 22 August, Amazon responded, stating that it notifies affected customers whenever it becomes aware of exposed keys and applies quarantine policies to limit the damage. That statement is accurate. It is also the reason this research should trouble any board.

The dated sequence

• August 2022 to August 202664,024 unique AWS keys surface publicly across repositories, container images, CI logs, package registries and public AI training datasets. 43% are sighted more than once.
• 2023 and earlierAWS detects a subset of these exposures and applies its AWSCompromisedKeyQuarantine policy. 112 of the still-live keys carry the original version of that policy, which AWS stopped applying in 2023, meaning those owners were flagged and notified at least three years ago.
• 10 August 2026Truffle Security re-verifies 10,616 keys using read-only calls. 88% still authenticate. 929 of the 7,590 active IAM users, roughly 12%, are still carrying the AWS quarantine policy.
• 19 August 2026Findings published. Every owner the researchers could identify, 10,260 of 10,616, was notified ahead of publication.
• 21 to 22 August 2026BleepingComputer and SC Media report the research. Amazon confirms it notifies customers of exposed keys and applies quarantine policies.

Why this one is different

There is no CVE here. No patch, no vendor at fault, no zero-day. Every organisation in this dataset had access to the controls that would have prevented the outcome, and a meaningful share had already been told, by name, that their credentials were public.

The number that carries the argument is 929. That is how many of the active leaked IAM users were still carrying AWS’s own quarantine policy when the researchers looked, roughly 12% of the active set. AWS had detected the exposure and restricted those keys. Of those, 112 carried the retired version of the policy, so their owners were notified at least three years ago. The credentials still authenticate.

Detection worked. Notification worked. What failed was ownership. Nobody inside those organisations held the accountability, the mandate or the routine to act on the alert when it arrived.

The age profile confirms it. The median live leaked key was created 1,831 days ago, roughly five years. Half are over five years old and the oldest is 17.4 years, nearly as old as AWS identity management itself. Of the keys the researchers could enumerate, only 13.7%, 398 of 2,903, had ever been superseded by a newer credential. Rotation was the rare event, not the leak.

There is a second structural finding that deserves separate attention. The largest single source of leaked keys was not a code repository. It was Hugging Face, with 8,482 unique live keys across 3,394 public datasets, and the credentials found there skewed more privileged than any other source tracked, with 17.9% of them root keys. Most of those datasets are snapshots of public code repackaged for model training. A credential committed once is tokenised into corpora that thousands of downstream projects then download. Deleting the original file achieves nothing.

For any organisation building with AI, that is a new exposure channel sitting outside the field of view of most security functions. The AI data supply chain now propagates credentials, and it does so at a scale and permanence that traditional secret rotation was never designed to counter.

The commercial exposure for UK organisations

Regulatory. A five-year-old, unrotated administrative credential is difficult to defend as “appropriate technical and organisational measures” under UK GDPR once it becomes the entry point for a personal data breach, and the ICO has repeatedly cited basic credential hygiene in its enforcement reasoning. Organisations in scope of DORA through EU financial operations, or of NIS2 through European entities and supply chains, face regimes that expect demonstrable ICT risk management and explicit board accountability. Intent is not a defence in either.

Financial. Full account control permits data exfiltration, infrastructure destruction, or quiet cryptomining funded entirely by the victim. Only 262 of the 2,754 readable accounts, 9.5%, had any budget alert configured, and the median configured limit was $8, the standard free-tier guardrail. Accounts behind live leaked keys spent $420,631 in July 2026 alone. An attacker has little need for ransomware when the target is already paying the bill and has no mechanism to notice.

Contractual. Secrets management and key rotation now appear routinely in enterprise security questionnaires and in ISO 27001 and SOC 2 audit scope. A stale credential estate is an audit finding in waiting, and in a competitive procurement it is the difference between clearing a security review and being set aside. That reframes credential hygiene as a revenue question rather than a hygiene one.

Governance. The consultancy carrying 19 leaked keys makes the supplier dimension concrete. Exposure is not bounded by your own repositories. It extends to every development partner, agency, integrator and contractor that has ever held a credential into your estate, and to the AI datasets their code may since have been folded into.

What leaders should do now

Five decisions, none of which requires new technology spend, and all of which can be taken this week.

• Decision oneAssign a named owner for credential lifecycle. A person, not a team and not a function. This research is four years of evidence that alerts delivered to nobody in particular produce no action at all.
• Decision twoOrder the removal of root access keys across every cloud account. One in six leaked keys was root. There is no legitimate operational reason for a root access key to exist in 2026, including in the dormant account created for an experiment nobody remembers.
• Decision threeSet a maximum credential age and make it policy. The median leaked key was five years old and had never been rotated. An enforced age limit eliminates the entire failure mode whether or not a credential ever leaks.
• Decision fourPut a financial tripwire on every account. 90.5% of the readable accounts had no budget alert. A $10 alert costs nothing and surfaces abuse in hours rather than at the end of a billing cycle.
• Decision fiveBring the AI data supply chain into scope. Require secrets scanning before anything is committed, published or used for training, and require your suppliers to evidence the same. Treat committed as leaked, permanently.

Three questions for leadership

Executives do not need to understand IAM policy syntax. They need three answers.

1. If our cloud provider quarantined one of our credentials tomorrow, who receives that notification, and what is the agreed time to action?

2. What is the age of the oldest active access key in our estate, and can anyone in this organisation answer that today?

3. Which suppliers and development partners hold credentials into our environment, and when did we last verify how they manage and retire them?

If the first question has no named answer, the other two cannot be resolved by tooling.

The strategic takeaway

Most security budget buys detection. This research is a four-year, controlled demonstration that detection without ownership produces nothing at all. The organisations in this dataset had monitoring available, had in many cases been notified directly by their cloud provider, and still left administrative credentials live for a median of five years.

The differentiating capability is not another platform. It is a named owner, an enforced rotation policy, and a leadership team that keeps asking the second question above until it receives an answer with a number in it. That capability is inexpensive to build and, in a market where enterprise buyers now audit their suppliers’ credential hygiene as a condition of contract, it is commercially productive rather than merely defensive.

Detection is abundant. Ownership is scarce. That gap is where this entire dataset came from.

Garzon Cyber Solutions delivers cybersecurity advisory, compliance certification, and specialist technology recruitment as one integrated capability. We are a young firm, the founder personally runs the work, and our perspective comes from a career spent inside cybersecurity and compliance, on the sales, marketing and technical sides of the industry.