88% of Leaked AWS Keys Still Work: The Credential Debt Your AI Agents Are Compounding

Why Is a Five-Year-Old Leaked Key Still Working?

On 10 August 2026, a research team pulled 10,616 AWS access keys that had been sitting in public places since August 2022 and simply tried them. Truffle Security's re-verification found that 88% of them still authenticated. Not 88% of keys leaked last week. 88% of keys that have been publicly readable for up to four years.

The privilege distribution is where it stops being an abstract statistic. Of the live keys, 768 belonged to identifiable companies and carried complete control of the account: 526 were root access keys, and 242 were IAM users holding AdministratorAccess. The wider sweep behind that sample turned up 64,024 unique AWS key pairs across 431,875 public findings, drawn from git history, Hugging Face datasets, Docker images, package registries and CI logs. Hugging Face alone accounted for 8,482 unique live keys spread across 3,394 public datasets, which tells you that the modern leak surface is no longer just a repository.

The age numbers are the part that should change how you plan the quarter. The median live leaked key was 1,831 days old, which is five years. Of the keys examined for rotation history, 86% had never been rotated at all, and fewer than one in a hundred had been created in the previous month. These are not credentials that slipped out yesterday and will be caught by tomorrow's scan. They are permanent fixtures of somebody's production environment that happen to also be public.

There is a final detail that reframes the whole problem. Only 262 of 2,754 readable accounts had any budget alert configured, and the median budget limit among those that did was $8. Meanwhile 929 of the keys had already been flagged by AWS's own AWSCompromisedKeyQuarantine policy. The cloud provider had noticed the exposure, applied a containment policy, and the owner still had not rotated the key. This is not a detection problem. Detection worked. Nobody acted on it.

How Did the Volume Get This Bad?

The exposure rate is rising faster than the industry that produces it. GitGuardian's State of Secrets Sprawl 2026 counted 28.65 million new hardcoded secrets added to public GitHub during 2025, a 34% year-over-year increase and the largest single-year volume on record. Public commits over the same period reached 1.94 billion, up 43%, and the active developer base grew 33%.

You could argue that more code simply means more secrets, and proportionally that is nearly true for a single year. Extend the window and it stops being true. Since 2021, leaked secrets have grown 152% while the developer population producing them grew 98%. The leak rate per developer is going up, not holding steady, and it is going up during exactly the period in which secret scanning became a default feature of every major platform.

The second finding in that report is the one that quietly invalidates most internal risk models. Internal repositories are roughly six times more likely to contain a hardcoded secret than public ones: 32.2% of private repositories carry at least one, against 5.6% of public repositories. Teams behave as though the repository boundary is a security boundary, so the discipline that gets applied to public code never gets applied to internal code. Then a contractor laptop gets compromised, or a repository gets made public during an acquisition, or a supply-chain worm reaches a build runner, and four years of accumulated hygiene debt becomes an incident in one afternoon.

This is the shape of the problem worth naming clearly, because it changes who owns it. Secrets sprawl is not a security-team backlog. It is an engineering artefact produced by ordinary delivery work, and it accumulates at the rate that delivery happens. Any control that lives outside the delivery pipeline will always be a scan running behind a fleet of developers who are moving faster than it does.

Are AI Coding Agents Making the Leak Rate Worse?

Yes, measurably, and the mechanism is more interesting than the headline. In the same GitGuardian analysis, commits co-authored by AI coding agents leaked secrets at a rate of 3.2%, against a platform-wide baseline of 1.5%. Roughly double, on a population large enough that it is not noise.

It would be convenient to blame the model, and it would be wrong. The generated code is not inventing credentials. What changes is the workflow around it. An agent scaffolds a working integration in one pass, which means it writes the config file, the environment loader and the client initialisation together, and the fastest way to get that integration running is to put the real key in the real file and see it work. The human step that used to catch a pasted credential, the pause between writing the config and writing the code that consumes it, has been compressed out of existence. The commit that follows contains both.

The second effect is volume of identities rather than volume of mistakes. AI-service credentials are now the fastest-growing category of leaked secret by a wide margin: 1,275,105 AI-service secrets were detected during 2025, up 81% year over year, and eight of the ten fastest-growing detector categories were tied to AI services. Individual services show growth that only makes sense in a land-grab: Brave Search API keys up 1,255%, Supabase up 992%, Firecrawl up 796%. One provider alone accounted for roughly 113,000 leaked API keys. Every new tool a team adopts mints another token, and the governance for that token is almost never created at the same moment the token is.

Then there is the agent's own configuration layer, which is new enough that most organisations have no policy for it at all. Model Context Protocol config files turned out to hold 24,008 unique secrets, of which 2,117 were verified as still valid. These files are not usually treated as sensitive. They get committed to repositories, shared in onboarding docs, copied between machines and pasted into chat threads when a colleague's tool will not connect. They are a credential store that nobody classified as one.

The practical conclusion is not to slow down agent adoption. It is that a team scaling up agentic development without first removing static credentials from the developer's reach is scaling the leak rate along with the delivery rate. Get the secrets out of the environment before you put agents into it.

Where Do Secrets Hide When They Are Not in Your Code?

Most secret-scanning programmes are scoped to repositories, and that scope misses roughly a third of the problem. 28% of incidents originate entirely outside code, in Slack, Jira and Confluence, where a credential gets pasted into a thread to unblock a colleague and then lives forever in a searchable archive with far weaker access controls than the repository it was kept out of.

Worse, those non-code leaks skew more severe. 56.7% of secrets found only in collaboration tools were rated critical, against 43.7% for code-only incidents. That inversion makes sense once you think about who pastes what: nobody hardcodes the production database password into a service, but somebody absolutely pastes it into a support channel at 23:00 during an incident.

The build and packaging layer is a third surface. 18% of scanned Docker images contained secrets and 15% contained valid ones, which is what happens when a build argument becomes a layer and the layer gets pushed to a registry. Self-hosted source control is not immune either: 12% of scanned GitLab repositories held valid secrets.

And then there is the case that ties all of these together into a single attack. The Shai-Hulud npm worm campaign, which JFrog's security research team tracked across successive waves, propagates through package updates, then harvests every credential it can reach on the host: npm tokens, cloud keys, Kubernetes and Vault tokens, SSH keys, .env files, Terraform state and Docker configs. Analysis of 6,943 machines compromised in that campaign surfaced 294,842 secret occurrences and 33,185 unique secrets, and 59% of the compromised machines were CI/CD runners rather than laptops.

That last number is the one to sit with. The build runner is where an organisation concentrates its most privileged, longest-lived credentials, usually with the fewest humans watching. A worm that reaches one runner does not get a developer's read access to a repository. It gets the deploy key, the registry token and the cloud role that ships to production.

Why Does Nobody Revoke Them?

Here is the statistic that turns this from a hygiene story into a governance story: 64% of the secrets leaked in 2022 were still valid four years later. The organisations involved were not unaware. Most of them run secret scanning. They were notified, and the credential is still live.

The reasons are consistent, mundane, and entirely fixable. The first is ownership. A leaked key arrives in a security queue with no indication of which service uses it, which team wrote it, or who is on call for the thing that breaks when it disappears. Tracing that takes a day of archaeology across repositories and people who have left, and the ticket ages.

The second is unknown blast radius. Nobody can enumerate the consumers of a long-lived credential, because the whole point of a long-lived credential is that it gets copied. It is in a Terraform variable, a Kubernetes secret, two CI pipelines, a colleague's local environment file, and one lambda that nobody has touched since 2023. Revoking it is a change with an unbounded and unmeasured failure surface, which means it will not happen on a Friday, and then it will not happen on Monday either.

The third is that rotation has never been rehearsed. If a team has not rotated a given credential in the last year, the rotation procedure is a hypothesis, not a runbook. Teams that rotate on a schedule discover their broken assumptions during business hours on a planned day. Teams that rotate only under incident pressure discover them at the worst possible moment, which is precisely why they keep deciding not to.

A fourth failure is subtler and it undermines the triage step itself. Prioritising only on whether a credential still validates misses 46% of critical secrets, because validation checks answer a narrow question. A key that fails validation may have been rotated, or it may simply be scoped to an endpoint the scanner cannot reach, and a key that validates against a low-value service may be reused as the same string somewhere that matters. Severity is a function of what the credential unlocks, not of whether a probe happened to succeed.

What Does a Leaked Credential Actually Cost?

The financial baseline moved this year. IBM's 2026 Cost of a Data Breach research put the global average at $4.99 million, a 12% rise, with the United States average at $11.5 million. For the first time in five years, the time to identify and contain a breach also went up rather than down.

The attack-path data is more nuanced than the usual credentials-are-everything framing, and it is worth getting right. The Verizon 2026 DBIR analysis shows vulnerability exploitation reaching 31% of breaches as the first known initial access vector, up from 20% the previous year, while credential abuse fell to 13% from 22%. That is the first time in the report's nineteen-year history that stolen credentials have not led as the entry point.

Read only that far and you would deprioritise this work. Read one line further and you would do the opposite. Counted anywhere in the attack progression rather than only at the front door, credential abuse appears in 39% of breaches, more than any other vector. Credentials have moved from the doorway to the hallway. The intruder gets in through an unpatched service, and then it is your long-lived, over-scoped, never-rotated keys that turn a foothold into a full compromise.

The ransomware linkage makes the same point in operational terms. Ransomware featured in 48% of breaches investigated, and 73% of ransomware victims had an associated infostealer or credential leak during the same year. Among those, half saw the credential leak in the 95 days preceding the attack. A leaked credential is not merely a risk in the abstract. It is frequently a dated early warning that an organisation received and did not act on.

What Actually Works: Stop Storing the Secret at All

Every durable fix in this area shares one property: it reduces the number of long-lived strings that exist. Rotation policies, vaults and scanners all help, but they are compensating controls around a credential that still exists and can still be copied. The structural answer is to issue credentials at the moment of use, scoped to the workload, and let them expire in minutes.

That path is now well supported rather than aspirational. GitHub extended OpenID Connect support to Dependabot and code scanning at organisation level in April 2026, so private registry access can obtain short-lived credentials from a cloud identity provider instead of reading a static repository secret. The same federation pattern already covers Actions workflows reaching AWS, Azure and Google Cloud. Every pipeline moved onto it is a permanent deletion from your secret inventory rather than another item to rotate.

At the ingress point, push protection blocks a commit containing a recognised credential before it reaches the remote, which is the only intervention that avoids the git-history problem entirely. Once a secret is in history, removing it means rewriting history across every clone and fork, which is why in practice teams rotate instead and the exposed string stays readable forever.

The sequence that works, roughly in the order it should be attempted, looks like this. Turn on push protection everywhere, including internal repositories, because that is where 32.2% of the exposure lives. Inventory beyond the repository: chat archives, ticket systems, wiki pages, container images, CI logs and agent configuration files. Delete root access keys outright, since there is essentially no legitimate steady-state use for them. Move CI and registry authentication to identity federation, which removes the largest and most privileged block of static secrets in one project. Give every credential that survives three pieces of metadata: an owner, an expiry and a documented consumer list. Rehearse rotation on a schedule so the runbook is real. And put cost and anomaly alarms on every cloud account, because 9.5% coverage on budget alerts means most organisations would learn about credential abuse from an invoice.

None of this is research work. It is unglamorous platform engineering with a clear definition of done, which is exactly the sort of project that gets deferred indefinitely inside a product team measured on feature delivery. It is also the sort of project a dedicated team can pick up, complete in a defined window, and hand back with the tooling and the runbooks in place.

How Do You Run Credential Hygiene Across a Distributed Team?

Everything above gets harder the moment the people writing code are spread across companies, contracts and countries, which describes almost every engineering organisation now. Credential hygiene is fundamentally a question of who holds what, and that question is answered by your operating model long before it is answered by your tooling.

The failure modes are predictable. Access is granted at onboarding through a shortcut because the proper path takes a week, and the shortcut becomes the path. Nobody revokes at offboarding because the credential was personal rather than provisioned, so there is no record to revoke against. A rotating pool of short-term contractors means the person who created a key is routinely gone before anyone asks what it unlocks, which is precisely the archaeology problem that makes revocation stall. And the more the composition of the team churns, the more the ownership metadata degrades, until the inventory is a list of strings with no attached meaning.

If you are evaluating an engineering partner for work that touches production, the useful questions are concrete and technical rather than certification-shaped. How do your engineers authenticate to our cloud, and does any long-lived key exist in that path? What happens to access on the day an engineer rolls off, and who executes it? Is push protection enabled on the repositories you work in, and what happens when it blocks someone at 18:00? Have you rotated a production credential for a client in the last quarter, and what broke? Where do your engineers store environment files, and are those machines managed? Which of your CI pipelines still authenticate with a static secret? Every one of those has a specific answer, and a partner who cannot give one is telling you something useful.

This is one of the reasons we build the way we do at Stepto. We put dedicated senior teams in Serbia onto a product rather than rotating individuals through a ticket queue, which means the engineer who provisioned a credential is still there when someone asks what it unlocks, and the ownership metadata that makes revocation tractable stays attached to a real person. Access is provisioned through the client's own identity path rather than around it, and offboarding is a defined step rather than an assumption. Working inside the European regulatory perimeter means GDPR obligations, data residency and access controls are constraints our engineers already build under. And Central European hours overlap the full European working day, which matters more than it sounds: rotating a production credential is a change you want executed while both the team that owns the service and the team that owns the pipeline are awake.

The work itself splits cleanly into project shapes. A secrets inventory and remediation sweep across repositories, collaboration tools and images is a well-bounded engagement with a countable output. Migrating CI and registry authentication to identity federation is a platform project with a clear endpoint. Building the rotation runbooks and rehearsing them is a quarter of work that leaves the client's own team more capable than it found them. Our security engineering, DevOps and dedicated team engagements are built for exactly that kind of scoped, senior-led work, and engineers are assigned by name so that the person who wrote the runbook is the person you can ask about it in eighteen months.