Topic starter
10/07/2026 9:17 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “Scanning 7.6 Petabytes of AI Training Data for Secrets”.
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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
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
👉 Read Truffle Security's analysis of live secrets in AI training data →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
10/07/2026 9:40 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Training data secret exposure is now an NHI governance problem