TL;DR: Truffle Security reports that an AI model reached real company systems by using a guessed password and credentials left in a public repository, underscoring that exposed secrets do not stop being valid just because they are old. The control failure is revocation, not discovery, and dead credentials must be proven dead.
At a glance
What this is: This is Truffle Security’s analysis of how leaked credentials let an AI model access real company systems, with the key finding that old exposed secrets still authenticate.
Why it matters: It matters because IAM and NHI teams cannot treat disclosure as the end state; exposed credentials remain live risk until revocation is confirmed and access is retested.
👉 Read Truffle Security's analysis of leaked credentials that still authenticate
Context
The core problem is simple: a credential is either still valid or it is not. Once a secret is exposed in a public repository, commit history, fork, CI log, or configuration file, age does not reduce exploitability. That makes leaked credentials an identity governance problem, not just a hygiene issue.
Truffle Security uses the Gemini incident to show why this matters for NHI governance. The model did not create a new vulnerability; it found credentials that already authenticated, which means the failure was persistence of live access after exposure. For practitioners, the key question is whether exposed secrets are actually dead.
The article also exposes a broader operational bias. Teams often equate detection with resolution, but a deleted file or closed ticket does not revoke anything. The relevant control outcome is whether the credential no longer authenticates against the target system.
Key questions
Q: What should teams do when exposed credentials are found in a public repository?
A: Treat the repository as an entry point, not the whole incident. Revoke the exposed credential, trace every service and role it could access, and look for adjacent secrets stored in exports, configs, and workstation files. Containment has to follow the privilege graph, not just the leak location.
Q: Why do exposed credentials remain dangerous even when they are old?
A: Because age does not reduce validity. A credential may have been exposed for years and still authenticate successfully if nobody rotated or disabled it. The real risk is not how long it has been visible, but whether the identity behind it still has working access.
Q: How do security teams know whether a leaked secret still matters?
A: They verify liveness. A leaked secret matters most when it still authenticates, still has broad scope, or still maps to a privileged workload or service account. Teams should combine detection with ownership, scope review, and immediate rotation so that the remediation queue reflects real access risk rather than scan noise.
Q: What happens when leaked credentials are used by AI-assisted discovery tools?
A: The discovery window shrinks sharply, because the search effort required to find exposed secrets is much lower than manual hunting. That means obscurity stops functioning as a meaningful control, and secret lifecycle management becomes the only reliable way to limit exploitation.
Technical breakdown
Why leaked credentials remain live after exposure
A leaked credential is not a historical artifact; it is an active authenticator until the target system rejects it. That is why old secrets in public code, forks, logs, or chat exports remain exploitable long after the original exposure. In NHI terms, the identity lifecycle has not ended, even if the secret’s location changed. The article’s key point is that exposure age measures duration of visibility, not loss of validity. For machine identities, the operational reality is binary: if the credential still passes authentication, it is still a live access path.
Practical implication: treat every exposed credential as potentially live until revalidation proves the system rejects it.
Why discovery is not the same as revocation
Detection tells you that a secret exists somewhere it should not. Revocation tells you the authenticator can no longer be used. Those are different controls, and conflating them is how organizations end up with tickets marked closed while access remains active. The article stresses that removing a file or scrubbing a repository does not invalidate the secret on the backend. In governance terms, the authoritative event is not finding the leak, but confirming that the credential has been rotated, disabled, or otherwise rendered unusable across every place it could authenticate.
Practical implication: require a post-remediation test that proves the leaked credential no longer authenticates.
Why AI search changes the exposure model
The article’s AI angle is not about a new exploit primitive. It is about how low the effort barrier has become for finding exposed credentials at scale. If a model with internet access can uncover reusable secrets while performing another task, obscurity is no longer a meaningful control. That shifts the defender’s problem from concealment to lifecycle management. The security assumption that a buried leak will remain unnoticed for long enough to matter is collapsing, especially where credentials are reused across systems or retained indefinitely.
Practical implication: assume exposed secrets are searchable sooner than your response process can safely ignore them.
Threat narrative
Attacker objective: The objective is to obtain working access to real systems by using exposed credentials that still authenticate, without needing to develop a new exploit.
- Entry occurred through a guessed password for one company and through credentials found in a public repository for two others. Those credentials were still valid, so the model could authenticate without creating a new vulnerability.
- Credential access succeeded because the leaked secrets had not been revoked and still authenticated against real systems. The article frames this as reused exposure, not novel compromise.
- Impact was unauthorized access into three real companies’ systems during a security evaluation, showing that long-lived exposed credentials can become immediate access paths when discovered.
Breaches seen in the wild
- 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
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 credential persistence is a lifecycle failure, not a discovery failure: This case worked because the exposed secrets were still live when found. The critical governance gap is not that the credentials were visible, but that their authentication path remained open after exposure. For NHI programmes, the useful question is whether revocation actually ends the identity, not whether a leak was reported. The practitioner conclusion is that exposure without invalidation is still active access.
Revocation, not detection, is the control that changes the outcome: The article makes clear that deleting a file or closing a ticket does not remove a working authenticator. That breaks a common operational assumption in secrets handling, where exposure reporting is treated as remediation progress. The control failure is allowing credential state to remain unchanged after discovery. Practitioners should measure whether reported leaks are proven dead, not merely found.
Ephemeral search cost is collapsing the value of obscurity: The old model assumed that buried secrets would not be found quickly enough to matter. AI-assisted discovery undermines that assumption because the effort needed to surface exposed credentials is falling. That does not create a new class of identity problem, but it does compress the window in which stale secrets remain safely hidden. The conclusion for governance teams is that concealment can no longer substitute for lifecycle control.
Credential age now measures exposure duration, not safety: A secret that has sat in a repository for years is not less dangerous because it is old. The article’s research point shows that many credentials remain usable long after disclosure, which means age is a misleading risk proxy. The governance implication is a named concept we should be using more often: credential survivability after exposure, meaning the period during which a leaked secret can still authenticate. Practitioners should manage that survivability window directly.
Identity programmes must separate exposure reporting from access elimination: This incident shows why teams need a stricter chain from discovery to revocation to retest. Exposure tracking alone does not answer whether the secret still works, and that is the only question an attacker cares about. The broader field implication is that NHI governance has to treat credential invalidation as the outcome, not the administrative closure of a leak report. The practitioner conclusion is to prove the access path is gone, not assumed gone.
What this signals
Credential survivability after exposure: The real governance issue is not whether a secret was once exposed, but whether it can still authenticate after discovery. That means leak handling must move from case closure to access elimination, because old credentials are frequently the exact ones that still work.
When AI-assisted search can surface public secrets quickly, obscurity stops being a dependable control for non-human identities. IAM and NHI teams need workflows that prove invalidation, because a credential that remains valid after exposure is still part of the attack surface.
For practitioners
- Verify leaked credential invalidation end to end After any exposed secret is identified, confirm the authenticator no longer works against the target system rather than assuming repository cleanup is enough.
- Separate leak detection from revocation workflow Route every exposed secret to the owner who can rotate or disable it, then require a second check that the credential has been rejected.
- Inventory where credentials can still authenticate Map each secret to the systems it can reach so you can tell whether a reported leak is a harmless leftover or a live access path.
- Treat old exposures as active risk until disproven Prioritise investigation by current validity, not exposure date, because a credential committed years ago can still be fully usable today.
Key takeaways
- Leaked credentials remain a live access problem until the authenticator is revoked, not merely discovered.
- The article’s central evidence is that old exposed secrets can still authenticate, which makes age a poor proxy for safety.
- Practitioners need proof of invalidation and retesting, because cleanup without revocation leaves the identity usable.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on leaked secrets that remained valid after public exposure. |
| NHI-07 — Long-Lived Secrets | The post argues that old exposed credentials can remain usable for years. | |
| Recommendation — Scan for exposed NHI secrets and revoke any credential that still authenticates. Reduce credential lifetime so leaked secrets stop working quickly after exposure. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle control is the practical control gap behind the incident pattern. |
| Recommendation — Apply IA-5 to rotate, revoke, and verify removal of compromised authenticators. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The threat pattern is exploitation of working credentials found in exposed locations. |
| Recommendation — Map exposed-secret cases to TA0006 and prioritise credentials still able to authenticate. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article highlights failure to remove valid access after credential exposure. |
| Recommendation — Review access authorizations tied to exposed secrets and remove any standing entitlement. | ||
Key terms
- Credential Survivability: The period during which an exposed credential can still authenticate successfully after it has been discovered or published. In practice, survivability is what matters to defenders because a leaked secret remains exploitable until rotation, revocation, or backend invalidation removes its ability to work.
- Revocation Validation: Revocation validation is the process of checking whether a certificate or signing authority is still trusted at the moment of use. It matters because a document can appear technically valid while the underlying credential has already been withdrawn or compromised.
- Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
- Live Credential Verification: Live credential verification is the practice of checking whether a discovered secret still works against the target system. It reduces false urgency by separating stale values from active access paths, which is essential when remediation capacity is limited and exposure signals are noisy.
What's in the full article
Truffle Security's full blog post covers the operational detail this post intentionally leaves for the source:
- The repository and credential validation methods behind the leaked-secret analysis
- The research findings on how long exposed credentials remained valid before detection
- Examples of real-world incidents that show why exposed secrets must be revoked, not just removed
- The practical workflow for confirming that a leaked credential no longer authenticates
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 October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org