TL;DR: Truffle Security reports that it has confirmed 1.4 million live API keys leaked across GitHub, Docker Hub, npm, Hugging Face and other sources, while 81% of the keys it reported last year still worked six months later. Notification alone is not an adequate control when leaked secrets remain valid long after discovery.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Truffle Security's research: Leaked API keys continue to remain live across public code and package ecosystems, and revocation is the only response that reliably closes the exposure window.
Why it matters: This matters because IAM, PAM and platform teams need controls that remove leaked machine credentials fast enough to matter, not just controls that detect them after exposure.
By the numbers:
- 81% of the keys reported last year still worked six months later.
👉 Read Truffle Security's analysis of revoking leaked API keys at source
Context
API key leakage is not just a discovery problem. It is an offboarding problem, because a secret that remains valid after exposure is still an active identity, not a historical artefact.
The control gap is familiar in NHI programmes: teams can detect exposed credentials, but still lack reliable, timely revocation across code hosting, package registries and AI toolchains. API key management has to cover both issuance and shutdown, or exposure simply persists in another system.
Truffle Security's data shows that public exposure and long-lived validity are now occurring at internet scale, which makes manual follow-up too slow for the pace of leakage.
Key questions
Q: What should teams do first when they find an API key in source code?
A: Treat the discovery as a live credential incident, not a code defect. Revoke or rotate the key at the issuing identity system, then verify that it no longer authenticates anywhere it is used. Only after that should teams clean up repository history, branches, and copies that may still contain the secret.
Q: Why does a leaked API key remain dangerous after the code is removed?
A: A leaked key stays dangerous because copies can persist in forks, clones, package mirrors, commit history, and other downstream systems outside your control. Attackers may also copy and use the key during the exposure window. Once a key is exposed, the safest assumption is that it is compromised until it is rotated and every dependent integration is updated.
Q: How should teams scan for exposed secrets across software supply chains?
A: Teams should scan source code, build artefacts, container images, dependency manifests, logs, object storage and CI/CD outputs for exposed secrets such as API keys, tokens and certificates. Use pattern matching, entropy checks, secret-specific detectors and repository history scans, then quarantine findings, revoke the credential, rotate it and trace where the secret propagated across downstream systems and packages.
Q: How do organisations know whether their secrets governance is actually working?
A: Look for fewer identities with decrypt rights, fewer hardcoded credentials in code and state, and clear evidence that retired workloads can no longer access secret paths. If secret use still depends on manual exceptions or shared automation roles, governance is present in theory but not in practice.
Technical breakdown
Why leaked API keys stay valid after exposure
An API key is a reusable credential, so disclosure does not end its validity. If the issuer does not explicitly revoke it, the key continues to authenticate exactly as designed, regardless of where it was copied or published. That makes leakage a lifecycle failure, not only a detection failure. In practice, the relevant problem is that the secret and the authorization relationship are separated: the copy may be public, but the trust remains intact until the issuer cuts it off. This is why exposed machine credentials often remain exploitable long after discovery.
Practical implication: Treat every confirmed leak as a live authentication event until revocation is verified at the issuer.
Why notification fails as a control for machine credentials
Notification creates an information handoff, not a security outcome. A message to a developer or customer may be useful for reporting, but it does not itself disable the credential, remove downstream access, or prevent reuse in automation. The article's data shows that a large share of reported keys can stay live for months, which means the control objective has to be revocation, not awareness. For machine identities, the useful question is whether the issuer can invalidate a credential directly and quickly, including when the secret appears in public repos, container images, datasets or build artefacts. Read Guide to the Secret Sprawl Challenge.
Practical implication: Replace notification-only workflows with issuer-side disablement and validation that the credential is dead.
How public code and AI toolchains widen the exposure surface
The exposure surface now extends well beyond source repositories. Keys appear in container images, package ecosystems, AI coding tool settings, datasets and app artefacts, which means a single secret can be copied into multiple distribution channels before anyone notices. That matters because each downstream copy creates a separate revocation trigger and a separate delay window. The operational issue is no longer just secret scanning in one repository. It is continuous discovery across the places where modern software and AI workflows persist configuration, context and credentials.
Practical implication: Expand scanning and revocation workflows to the full software and AI supply chain, not only Git hosting.
Threat narrative
Attacker objective: The objective is to turn an exposed machine credential into sustained, unauthorised access before the issuer revokes it.
- Entry occurs when an API key is embedded in public code, packages, datasets or application artefacts and becomes visible outside the issuer's control.
- Credential access happens when an attacker or automated scraper tests the exposed key and confirms that it still authenticates.
- Escalation follows when the same key is reused for API calls, data access or automation at machine speed before the issuer disables it.
- Impact is reached when the leaked secret enables unauthorised service use, data retrieval, model distillation or other downstream abuse.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Leaked API key exposure is an offboarding failure, not just a detection failure: once a secret is public, the real question is whether the issuer can reliably invalidate it before reuse. Truffle Security's data shows that many reported keys remain live long after disclosure, which means discovery alone does not close the identity risk. The practitioner conclusion is simple: revocation is the control boundary, not notification.
Public secret sprawl has outgrown repository-only governance: exposed credentials now appear in Docker images, package registries, AI tool configuration files and datasets, so the governance surface is broader than source control. That is why secrets governance has to extend across build artefacts, distribution channels and AI workflows, not stop at code review. The practitioner conclusion is to treat every copy location as part of the same lifecycle.
Long-lived machine credentials create trust debt: every day a leaked key stays valid increases the cost of delayed response and the probability of reuse by attackers or automated systems. This is the failure mode that NHI programmes keep underestimating: a credential can be simultaneously public, functional and unaudited. The practitioner conclusion is to measure exposure age and revocation time as first-class governance metrics.
Google's shift from notification to automatic disabling is the right pattern, but the deeper lesson is architectural: machine identity controls must assume exposure will occur and must be able to terminate trust immediately. The issue is not whether a leak was detected, but whether the credential can be made useless at the source without waiting on human coordination. The practitioner conclusion is to design for issuer-side kill capability as a baseline control.
Secret revocation programs are becoming a market signal for the NHI category: the industry is moving from finding leaked credentials to operationalising shutdown at scale. That shift validates a core NHI governance principle: ownership matters only when the owner can act fast enough to remove standing trust. The practitioner conclusion is to evaluate whether credential ownership, revocation rights and telemetry are actually aligned across teams.
From our research library:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- Read next: API Key Management Guide
What this signals
Secret revocation has become the control that matters most: detection can tell you where a leaked API key exists, but it cannot on its own stop reuse. The governance test is whether the issuer can kill the credential fast enough to make exposure irrelevant.
Public secret sprawl now spans software and AI pipelines: exposed credentials are appearing in code, images, packages and dataset artefacts, which means IAM and platform teams need a lifecycle view that crosses tooling boundaries. A repo-only programme will miss the places where modern secrets actually persist.
Trust debt accumulates every hour a leaked key remains live: the longer a public credential can still authenticate, the more likely it is to be scraped, replayed or chained into automated abuse. That is why revocation age should be treated as a programme health indicator, not an incident note.
For practitioners
- Make revocation the default response Define a standing process where every verified leaked API key is disabled at the issuer before any notification workflow is considered complete.
- Map issuer-side kill paths Document which systems can disable keys immediately, which require manual intervention and which have no external revocation path at all.
- Extend scanning beyond source control Include container images, package registries, AI tool configs and datasets in the same leak detection and response workflow.
- Track revocation age as a governance metric Measure how long a leaked secret remains valid after first detection and report that delay as a lifecycle control weakness.
- Separate notification from closure Require evidence that a leaked secret has been invalidated, not just reported, before closing the incident or risk ticket.
Key takeaways
- Leaked API keys are still active identities until the issuer disables them, so discovery alone does not remove the risk.
- The scale of public secret exposure is now measured in millions of live keys, with many remaining valid long after being reported.
- Programs that can revoke at the source, not just notify owners, are the only ones that materially reduce the attack window.
Related NHI Mgmt Group resources: Guide to the Secret Sprawl Challenge · API Key Management Guide · Ultimate Guide to NHIs
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The post centres on leaked API keys that remain valid after public exposure. |
| NHI-07 — Long-Lived Secrets | The core problem is that leaked keys stay usable for months or years after disclosure. | |
| NHI-03 — Vulnerable Third-Party NHI | Exposure across GitHub, Docker Hub, npm and Hugging Face shows third-party ecosystems as leak paths. | |
| Recommendation — Treat exposed API keys as live credentials and revoke them at the source immediately. Reduce credential lifetime and eliminate secrets that remain valid after public leakage. Review third-party platforms that store or surface NHI credentials and require revocation paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | API keys are authenticators whose lifecycle must include rotation, revocation and recovery. |
| Recommendation — Apply authenticator management controls to disable leaked machine credentials without delay. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The attack pattern is public credential harvesting and reuse of valid keys. |
| Recommendation — Map exposed-key detection to credential access hunting and prioritise credentials still valid in the wild. | ||
Key terms
- API Key: A unique identifier used to authenticate a software application or service when calling an API. API keys are static, long-lived credentials and a major source of secrets sprawl. In 2024, over 50 million leaked API keys were found on the dark web.
- Secret revocation: Secret revocation is the process of invalidating exposed credentials so they can no longer be used. In practice, it must include every system that trusts the secret, because a credential that remains valid after disclosure is still an active attack path.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Long-Lived Secret: A long-lived secret is a credential, token, API key, or certificate that remains valid for an extended period without frequent renewal. In NHI environments, it creates durable exposure because one leaked secret can keep granting access long after the original use case has changed.
What's in the full report
Truffle Security's full post covers the operational detail this analysis intentionally leaves for the source:
- How the Secrets Revocation Program handles issuer-side revocation requests and webhook delivery
- The scan sources and detection pipeline behind the 1.4 million live key count
- The empirical comparison between notification-only handling and automatic disabling
- Examples of participating issuers and the onboarding model for the revocation programme
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org