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.
Expanded Definition
Secrets leakage is broader than a misplaced API key in source code. It includes tokens, certificates, signing keys, session material, and other credentials exposed in repositories, logs, build output, ticketing systems, chat, or artifact stores. In NHI practice, the harm is not disclosure alone, but the possibility of immediate reuse by an attacker.
Definitions vary across vendors, but the operational meaning is consistent: a secret becomes leaked when an unauthorized party can discover it and authenticate with it before it is rotated or revoked. That makes leakage an identity event as much as a data event, which is why the OWASP Non-Human Identity Top 10 treats poor secret handling as a core control issue. For identity design, the question is not whether a value was sensitive, but whether it still enabled access when exposed. See the OWASP Non-Human Identity Top 10 for the control framing behind this distinction.
The most common misapplication is treating leakage as a developer hygiene problem only, which occurs when teams focus on code scanning but ignore runtime logs, CI/CD metadata, and collaboration tools.
Examples and Use Cases
Implementing secrets leakage controls rigorously often introduces operational friction, requiring organisations to balance faster delivery against tighter detection, rotation, and access controls.
- A CI/CD pipeline prints a cloud token during a failed deployment, and the token is later reused to access production resources. The incident starts as build noise and becomes credential abuse. NHI teams should compare this pattern with the CI/CD pipeline exploitation case study.
- A developer commits an AI service key into a private repository, assuming the repo is safe. Private repositories are not a control boundary by themselves, which is why the The State of Secrets Sprawl 2026 findings matter to modern NHI programs.
- A chatbot integration posts a bearer token into a support channel, where it is copied into another system. This is a cross-tool exposure, not a code-only leak. The pattern is consistent with the Guide to the Secret Sprawl Challenge.
- An operator stores a certificate in a ticket or wiki page for convenience, then forgets to revoke it after use. In that case, short-lived intent is undermined by long-lived exposure.
- Automated detection flags a leaked key, but no revocation occurs for hours. That gap turns finding into impact, which is why runtime response needs to be paired with revocation workflows.
For governance context, the Anthropic first AI-orchestrated cyber espionage campaign report underscores how quickly exposed credentials can be operationalized once found.
Why It Matters in NHI Security
Secrets leakage is one of the fastest ways to turn a configuration mistake into active compromise. In NHI environments, leaked credentials can unlock cloud APIs, signing workflows, data platforms, and MCP-connected agents, often without triggering traditional password protections. That is why secret governance must cover creation, storage, transport, detection, rotation, and revocation as a single lifecycle.
NHIMG research shows the scale of the issue: the State of Secrets Sprawl 2026 reported 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, alongside growing leaks in AI-related tooling. For historical context, the 52 NHI Breaches Analysis shows that exposed non-human credentials repeatedly become the first usable foothold in larger intrusions. Static secrets are especially risky when they are reused across environments, which is why the Ultimate Guide to NHIs — Static vs Dynamic Secrets remains relevant to remediation strategy.
Organisations typically encounter the real cost only after a token is abused, at which point secrets leakage becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Secret sprawl and improper secret handling are core non-human identity risks. |
| NIST CSF 2.0 | PR.AA-05 | Credential lifecycle control supports authenticated access protection in modern environments. |
| NIST Zero Trust (SP 800-207) | SC-12 | Zero Trust assumes credentials can be exposed and need continuous validation and protection. |
Treat exposed secrets as compromised, limit blast radius, and require reauthentication and segmentation.
