TL;DR: Truffle Security found about 12,000 live API keys and passwords in Common Crawl, the web-scale dataset used to train models such as DeepSeek, showing that LLMs are exposed to insecure code patterns before prompt-time safeguards can intervene. That exposure turns secret hygiene into a data-supply-chain problem, not just a repository problem.
At a glance
What this is: This research shows that Common Crawl contained roughly 12,000 live API keys and passwords, making hardcoded secrets part of the data fed into LLM training pipelines.
Why it matters: For IAM and NHI practitioners, it widens secret governance from application repositories to public web capture, model training inputs, and downstream AI coding guidance.
By the numbers:
- The scan covered 2.76 million web pages containing live secrets.
👉 Read Truffle Security's research on live API keys and passwords in DeepSeek training data
Context
Hardcoded credentials are not just an application-layer mistake. When they are captured in public web archives and reused as model training material, secret exposure becomes part of the AI supply chain and can influence what LLMs later reproduce in code suggestions.
This matters to NHI governance because API keys, passwords, and other machine credentials are often managed as isolated secrets, while the real exposure path now spans source code, rendered pages, archived datasets, and model outputs. The problem is not limited to one vendor or one model family; it is structural.
Truffle Security's research uses Common Crawl as the example dataset, but the underlying issue is broader: if secret scanning stops at repositories and CI systems, organisations miss the places where public web content and training corpora preserve credentials long after the original deployment has changed.
Key questions
Q: What breaks when live API keys appear in public web archives?
A: The secret lifecycle breaks at discovery and revocation. Once a live key is preserved in a crawl or snapshot, it can outlive the original deployment, be reused in training data, and remain exploitable until the owning team traces and invalidates every instance. The practical failure is losing control over where the credential exists.
Q: Why do leaked secrets in training data matter for security teams?
A: Because training data can reproduce insecure patterns at scale, and live credentials may remain valid long after the original leak. That means the risk is not only exposure of a string, but also the reinforcement of unsafe coding behaviour and the persistence of usable access material across external datasets.
Q: What are the signs that secrets exposure is spreading beyond code repositories?
A: A clear warning sign is when secrets appear in places teams do not treat as source code, such as public buckets, file shares, or other object storage. If those files contain multiple credential types, or if one exposed secret leads to authenticated infrastructure, the leak is no longer isolated. That indicates scanning, storage hygiene, and revocation processes are not keeping pace.
Q: How should teams reduce the blast radius of exposed API keys?
A: Use per-environment credentials, track where each secret is published, and revoke any credential that has been copied into public web content or archived datasets. The goal is to stop one leak from becoming a distributed identity problem that spans customers, pages, and training inputs.
Technical breakdown
How secrets reach model training data
Large language models learn patterns from whatever is present in their training corpus, including code snippets and web pages that contain credentials. Common Crawl is a public web archive, so if a site exposes an API key in front-end HTML or JavaScript, that string can be preserved and later ingested into training workflows. The model does not need to “understand” the secret to absorb the pattern. This is why data quality, not only model alignment, shapes output safety.
Practical implication: treat public web exposure as part of the secret lifecycle, not a separate problem from source-code leakage.
Why live secrets are more serious than lookalikes
A live secret is one that still authenticates successfully against its target service. That distinction matters because a live key in training data is not just evidence of bad hygiene, it is potentially usable credential material that may remain valid long after it was published. Even expired or example-looking strings can reinforce insecure patterns during training, but live secrets create direct abuse risk. The difference between “resembles a secret” and “authenticates as a secret” is the difference between noise and governance failure.
Practical implication: prioritize revocation and exposure tracking for validated live secrets first, then sweep for inert but risky examples.
Why repeated API keys amplify the blast radius
Reused API keys create a much larger exposure surface than one-off leaks because the same credential can appear across many pages, subdomains, or customer environments. In the article, one key appeared tens of thousands of times, which shows that a single secret can become a distributed artifact once it is copied into templates, scripts, or shared deployment patterns. This is a classic identity blast radius problem: one credential, many trust points, and very limited certainty about where it has propagated.
Practical implication: map key reuse across properties and tenants before rotation, or you may revoke one exposure while leaving many others active.
Threat narrative
Attacker objective: The attacker objective is to obtain usable credentials or exploit model-assisted insecure coding patterns to expand access and data exposure.
- Entry occurs when developers hardcode API keys or passwords into public-facing HTML, JavaScript, or other web content that later lands in public archives.
- Credential access follows when crawlers and training pipelines capture those strings in large datasets such as Common Crawl, preserving secrets at scale.
- Impact occurs when the preserved credentials influence model outputs, expose usable tokens, or widen the set of places an attacker can harvest the same secret.
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.
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
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
Training data is now part of the secret attack surface: Hardcoded API keys are no longer just a code hygiene problem because public archives can preserve them long after deployment. That means LLM training data becomes a governance domain alongside repositories, CI logs, and cloud metadata. The practitioner conclusion is simple: secret lifecycle controls have to extend to public web exposure, not just internal systems.
Secret scanning has to move upstream of the repository boundary: The article shows that public pages and archived datasets can contain working credentials at meaningful scale. That makes post-commit scanning necessary but insufficient, because the secret may already exist in a crawl or snapshot before internal controls can touch it. The implication is that discovery must cover external surface area, not only developer workflows.
Credential reuse creates an identity blast radius problem: When the same API key appears across many pages or subdomains, one leak becomes many exposures. The governance failure is not just leakage but reuse without clear ownership, rotation, and revocation boundaries. Practitioners should treat repeated keys as evidence of weak credential segmentation and lifecycle control.
Data-supply-chain security now overlaps with NHI governance: This research connects public content ingestion, model training, and downstream code generation to the same underlying secret management problem. That is why NHI, IAM, and AI governance can no longer be managed as separate programmes. The practitioner conclusion is to govern credentials as portable, replayable assets whose exposure path crosses more than one control plane.
Live-secret validation changes the risk conversation: Verifying that a leaked string still authenticates changes the issue from theoretical leakage to active access. That matters because governance teams often underestimate the importance of credentials that live outside the original system boundary. The conclusion is to prioritise validated secrets as operational incidents, not just data-quality findings.
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
Credential exposure is becoming a data-supply-chain issue: If archived web content can preserve live API keys, then model training pipelines inherit the same secret hygiene problem that IAM teams usually assign to repositories and CI systems. The programme boundary has to expand to cover public-facing assets and third-party archives, not just internal development workflows.
Secret reuse is the real multiplier: One API key appearing across many pages or subdomains creates an identity blast radius that is much larger than a single disclosure event. The operational lesson is to segment credentials by environment and owner so that rotation actually collapses exposure instead of shifting it.
Training data safety is now a governance control, not a model-tuning detail: LLM output quality will reflect the insecure patterns present in the corpus, so the control point starts before inference time. Teams should assume that whatever is left exposed on the public web can re-enter the development lifecycle through AI-assisted coding.
For practitioners
- Expand secret discovery beyond source control Scan public web properties, rendered pages, archived snapshots, and documentation sites for exposed API keys, passwords, and webhook tokens. Treat those locations as part of the secret inventory, not as exceptions outside it.
- Validate and revoke live secrets first Differentiate between strings that merely look like secrets and secrets that still authenticate successfully. Prioritise revocation, owner notification, and service-side invalidation for live credentials before handling lower-risk lookalikes.
- Reduce repeated key reuse across environments Identify credentials that appear across multiple customer sites, subdomains, or deployments, then replace them with environment-specific secrets and separate ownership boundaries. Reuse turns one exposure into a broad identity blast radius.
- Add AI code guidance that blocks insecure patterns Use developer-facing instructions and policy prompts that explicitly forbid hardcoded credentials and other insecure secret-handling patterns in generated code. The goal is to stop the model from reproducing what it has seen in exposed training data.
Key takeaways
- Public archives can preserve working API keys and passwords, which means secret management now extends beyond internal repositories and into the external data supply chain.
- The scale of the problem is not theoretical, with Truffle Security identifying 11,908 live secrets in 400TB of web data and millions of pages containing exposed material.
- The best containment strategy is to find and revoke live credentials first, then remove reuse patterns that allow one leak to propagate across many properties.
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 centers on exposed API keys and passwords preserved in public archives. |
| NHI-07 — Long-Lived Secrets | The research shows how leaked keys remain valid across crawls and reused datasets. | |
| Recommendation — Scan public web exposure and archived content for leaked NHI secrets and revoke any live credentials immediately. Replace long-lived API keys with shorter-lived credentials and enforce expiry where reuse is detected. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 directly covers credential issuance, rotation, and revocation for API keys and passwords. |
| Recommendation — Apply IA-5 to rotate and revoke exposed authenticators across every environment that copied them. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The exposed keys represent over-broad machine access that must be constrained and reissued. |
| Recommendation — Use PR.AA-05 to right-size machine entitlements and remove unnecessary credential reach. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The article illustrates how exposed secrets enable credential access and downstream data theft. |
| Recommendation — Map exposed-key findings to TA0006 and TA0010 to prioritise detection and containment. | ||
Key terms
- Live Secret: A credential, token, API key, or certificate that still authorises real access when discovered. In NHI governance, a live secret matters more than its origin because it can still move data, change code, or invoke services until it is revoked everywhere it exists.
- 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.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- 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.
What's in the full report
Truffle Security's full research covers the operational detail this post intentionally leaves for the source:
- The scanning method used to process 400TB of Common Crawl data across 90,000 WARC files
- The live-secret verification approach that separated authenticating credentials from lookalike strings
- Examples of repeated secrets, including a WalkScore API key found 57,029 times across 1,871 subdomains
- The disclosure and revocation process Truffle Security used to coordinate key rotation with affected vendors
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 October 15, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org