TL;DR: Truffle Security scanned 7.6 petabytes across 187 million public AI training files and found 221,303 live, unique credentials in 6,003 datasets, including write-capable tokens and cloud keys that can influence software, infrastructure, and identity systems. The real governance failure is permanence: once a secret enters training data, it is copied into derivative corpora and cannot be treated as a one-time leak.
At a glance
What this is: Truffle Security shows that public AI training data contains live credentials at scale, turning secret exposure into a persistent governance problem rather than a single leak event.
Why it matters: IAM, NHI, and AI governance teams need to treat training corpora as credential-bearing assets, because leaked secrets can propagate into downstream model supply chains and remain usable long after discovery.
By the numbers:
- Truffle Security scanned 7.6 petabytes of AI training data across 187 million files.
- 44% of all unique live secrets appeared in more than one dataset.
- One leaked Infura key reached 1,131 datasets and 10,162 file locations.
👉 Read Truffle Security's analysis of live secrets in AI training data
Context
Public AI training data is no longer just a data-quality issue. When live credentials are embedded in corpora that get scraped, deduplicated, and remixed into model inputs, secret exposure becomes part of the identity governance problem, not just the data loss problem.
The underlying gap is lifecycle control. Training datasets can preserve secrets after the original source is cleaned up, which means revocation alone is not enough unless organisations also govern where those secrets were copied, published, and reused.
Key questions
Q: What breaks when live secrets are published inside AI training data?
A: The normal secrets lifecycle breaks because the credential stops existing in one place. Once a live secret enters a public corpus, it can be copied into derivatives, reused in training, and discovered long after the original owner thinks the exposure is gone. Revocation still matters, but it must chase every replicated copy to be effective.
Q: Why are write-capable NHI credentials more dangerous than simple leaked tokens?
A: Write-capable credentials can change software, infrastructure, or workflow state, so the blast radius extends beyond data access. In training-data contexts, that means an exposed token can influence packages, CI pipelines, cloud resources, or hosted databases that other teams depend on.
Q: How do security teams know if training-data secret exposure is still active?
A: Look for live credentials that appear in more than one dataset, especially where the same secret shows up across mirrors, fine-tunes, or re-uploads. Repetition is the signal that the secret has become a persistent distribution problem, not a single leak.
Q: What should organisations do when a secret has already appeared in public AI training data?
A: Revoke the credential at the source, then trace where it was copied so downstream datasets, mirrored corpora, and model inputs can be cleaned up or quarantined. Without that propagation view, revocation only solves the first copy and leaves the rest usable.
Technical breakdown
Why AI training corpora become secret reservoirs
Public training datasets aggregate code, web pages, chat logs, and files into large corpora that are then reused across downstream models and derivatives. If a secret scanner is not run before publication, a live credential can survive inside multiple corpus generations even after the original source is fixed. That changes the control problem from discrete exposure to credential persistence across replicated datasets. For IAM and NHI teams, the important point is that the dataset itself becomes a distribution path for credentials, not just a repository of text.
Practical implication: treat published training corpora as credential-bearing assets and scan them before release and before ingestion.
Why write-capable tokens are higher risk than simple leakage
Not every exposed secret creates the same blast radius. A token that can publish packages, rewrite CI workflows, or push cloud resources changes software that other people run, which turns credential exposure into supply-chain influence. In NHI terms, the risk is not only that the secret exists, but that it authorises actions that propagate outward through software distribution, hosted databases, or cloud control planes. That is why credential inventory must include the privilege attached to the token, not just the token count.
Practical implication: classify exposed secrets by what they can change, then prioritise remediation for write, admin, and publish permissions.
Why repeated copies defeat one-time revocation
Training data creates amplification. Once a secret is embedded in one corpus, derivative datasets, fine-tunes, and mirrored copies can preserve it long after the source owner revokes the original credential. That means incident response is not limited to revocation at the source; it also depends on understanding where the secret has already propagated. For governance teams, the technical issue is copy proliferation across datasets and file locations, which makes traditional leak remediation incomplete on its own.
Practical implication: pair revocation with downstream traceability so you can locate and retire copied secrets across corpus variants.
Threat narrative
Attacker objective: The attacker’s objective is to inherit live authorization from training data and use it to change software, access infrastructure, or reach sensitive data at scale.
- Entry occurs when a credential is leaked into a public surface such as a repo, web page, or chat log and then scraped into training data.
- Credential access is preserved when the secret is verified live and embedded in a corpus that is later reused across multiple datasets.
- Impact follows when copied secrets continue to authorize cloud access, package publishing, CI changes, or database queries across downstream systems.
Breaches seen in the wild
- Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.
- 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.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Training data secret exposure is now a governance issue, not a hygiene issue: once a live credential enters a public corpus, the identity problem shifts from source remediation to lifecycle control across every derivative dataset. That breaks the old assumption that revoking a secret at the source is enough. Practitioners should treat dataset publication as a credential distribution event.
Write-capable NHI credentials create supply-chain reach inside model corpora: a token that can publish packages, rewrite workflows, or push images is not merely exposed, it is operationally consequential. Those privileges let a leaked secret influence software that other teams install or deploy. The practitioner conclusion is to govern secrets by authorization scope, not by leak volume alone.
Training corpora create secret blast radius, and the blast radius is multiplicative: one credential can be copied into many datasets, mirrored into file locations, and preserved through remixing. That means the control failure is not just exposure, but unchecked propagation. Security teams need a governance model that accounts for copy count, dataset reuse, and downstream residency.
Secret scanning must move left of publication and right of ingestion: the article shows that the dominant risk is not discovery after the fact, but preventing live credentials from becoming part of model inputs in the first place. That aligns with OWASP-NHI thinking on secret leakage and long-lived secrets. The practitioner lesson is that corpus governance belongs in the same control plane as NHI lifecycle management.
Persistent corpus exposure changes the accountability model for AI governance: the organisation that leaked the credential, the dataset publisher that copied it, and the model builder that consumed it each sit in the same risk chain. No single team can claim clean ownership once secrets are replicated into public training data. Practitioners should rework incident ownership so secret remediation spans source systems, dataset publishers, and model consumers.
From our research library:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Secret propagation is the core governance problem: once a credential enters public training data, revocation at the source is only the beginning. The more important control is preventing copied secrets from surviving across derivative datasets, mirrors, and fine-tunes, because that is where lifetime risk is created.
Corpus scanning belongs in the same control set as NHI lifecycle management: the fact pattern here is not unique to AI. Any environment that republishes secrets into another trust boundary needs inventory, detection, and revocation coverage that extends beyond the original owner.
The security profession is right to worry that AI systems can learn and reproduce sensitive information patterns from codebases, according to the State of Secrets in AppSec. When training data includes live credentials, the issue is not model memorisation alone, but the governance failure of allowing secrets to become reusable input.
For practitioners
- Scan training corpora before publication Run secret detection across raw datasets, transformed corpora, and derivative exports before any public release or model ingestion.
- Prioritise write-capable credentials Triage secrets by the actions they authorize, with first attention on tokens that can publish packages, modify CI workflows, or push cloud resources.
- Track downstream secret propagation Maintain evidence of where a credential was copied so revocation can extend beyond the original leak location into mirrored datasets and fine-tunes.
- Treat public-token exposure as burned Revoke any secret that has appeared in a public repo, web page, chatbot, or training corpus, because the copy can outlive the source.
- Add corpus governance to AI intake Gate model training on proof that the input corpus has been scanned, classified, and approved for credential-bearing content.
Key takeaways
- Public AI training data can become a credential repository, which means exposure must be governed as a lifecycle problem rather than a one-time leak.
- The scale of the issue is material, with live credentials appearing in thousands of datasets and persisting across downstream copies.
- The right control response is to scan before publication, classify by privilege, and revoke with downstream propagation in view.
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 CSF 2.0 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 article is fundamentally about live secrets appearing inside public training corpora. |
| NHI-07 — Long-Lived Secrets | Secrets remain usable after copy and reuse, which makes longevity the main risk. | |
| NHI-05 — Overprivileged NHI | Many exposed credentials can write code, publish packages, or alter infrastructure. | |
| Recommendation — Scan corpora for exposed credentials and remove or revoke any secret found before publication or ingestion. Shorten secret lifetime and treat any credential that reached a public corpus as burned. Prioritise remediation for credentials whose privileges can change software or cloud state. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The threat pattern centers on stolen or exposed credentials that are later reused. |
| Recommendation — Map leaked training-data secrets to credential access and exfiltration workflows to improve detection. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is the scope of what leaked credentials can do once reused. |
| Recommendation — Review credential entitlements and remove write or admin permissions that are not essential. | ||
Key terms
- Training Data Secret Exposure: The presence of live credentials inside datasets used to train or fine-tune AI systems. In practice, the risk is not only disclosure but persistence, because once a secret is published in a corpus it can be copied, mirrored, and reused across downstream model pipelines.
- Corpus Propagation: The spread of the same secret across multiple datasets, mirrors, or derived training sets after an initial leak. This creates a wider attack surface than the original source and makes revocation incomplete unless the downstream copies are also found and removed.
- Write-Capable Credential: A secret that authorizes changes, not just read access. Examples include tokens that can publish packages, modify CI workflows, or push cloud resources, and they are especially dangerous in NHI governance because a single leak can alter systems that many users depend on.
- Credential Lifetime: Credential lifetime is the period during which a token, key, secret, or refresh credential remains valid. In identity governance, lifetime determines how long access can exist without re-approval, making it a control boundary for revocation, review, and accountability.
What's in the full report
Truffle Security's full article covers the operational detail this post intentionally leaves for the source:
- The dataset-by-dataset breakdown of which corpora contained live credentials and how the authors verified them
- The deep dive into token types, including which credentials could publish packages, rewrite workflows, or push cloud resources
- The propagation analysis showing how one leaked secret can appear in hundreds or thousands of downstream datasets
- The case-level details behind the inVOID identity database exposure and the self-leak examples
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 10, 2026.
Updated on October 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org