The exposure of service account names, API keys, tokens, certificates, or deployment references inside code, config, or repository history. This matters because attackers can use that information to map governance gaps, target adjacent systems, and accelerate credential abuse even when the original secret is not immediately usable.
Expanded Definition
Identity leakage in code occurs when service account names, API keys, tokens, certificates, deployment references, or other identity-bearing artifacts are written into source code, configuration files, infrastructure templates, or repository history. In NHI governance, the issue is broader than secret exposure alone: leaked identity metadata can reveal naming patterns, system ownership, trust boundaries, and automation pathways that help an attacker map where to pivot next.
Definitions vary across vendors on whether “identity leakage” includes only directly reusable credentials or also non-secret references such as account names, tenant IDs, and certificate subjects. NHI Management Group treats both as relevant because modern attackers often chain low-value identity clues into credential discovery, token replay, or privilege escalation. The concept aligns closely with secret hygiene guidance in the Ultimate Guide to NHIs and with general secret-handling principles described in the OWASP Top 10 for LLM Applications, even though the latter is not NHI-specific.
The most common misapplication is treating leaked references as harmless because the original secret was not immediately usable, which occurs when teams ignore repository history, build artifacts, and config drift as part of the identity attack surface.
Examples and Use Cases
Implementing controls against identity leakage in code often introduces workflow friction, requiring organisations to balance developer velocity against review depth, secret scanning coverage, and repository access constraints.
- A CI pipeline hardcodes a service account name and cluster role binding in a Helm chart, giving an attacker enough context to hunt for the matching token in deployment logs.
- A public Git repository exposes an API key in an old commit, while the current branch appears clean; history still reveals the credential path and rotation gap.
- A Terraform module stores a certificate thumbprint and backend reference, allowing an adversary to identify where the workload authenticates and which trust anchor to target.
- A developer pastes a JWT into test code during debugging, then removes it without rewriting history, leaving the token recoverable through source control metadata.
- Repository documentation names the exact automation account used for production deployment, which helps an attacker focus phishing, token stuffing, or lateral movement attempts.
NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, and 30.9% store long-term credentials directly in code, as detailed in the Ultimate Guide to NHIs. For incident patterns involving exposed code paths, see the 52 NHI Breaches Analysis. External incident research from Anthropic also underscores how quickly attackers operationalise exposed credentials once they are discovered.
Why It Matters in NHI Security
Identity leakage in code turns application delivery systems into discovery tools for attackers. Even when a secret is rotated quickly, the leaked identity trail can expose which services exist, how they authenticate, and where governance has failed. That matters because NHI environments already struggle with visibility, and leakage multiplies that weakness across source control, build logs, code review tools, and deployment pipelines.
NHIMG research reports that 79% of organisations have experienced secrets leaks, with 77% of those incidents resulting in tangible damage, while only 20% have formal offboarding and revocation processes for API keys. Those gaps make leaked code artifacts more than a hygiene issue: they become evidence of control failure, weak rotation discipline, and incomplete blast-radius containment. The Guide to the Secret Sprawl Challenge is especially relevant where teams distribute credentials across multiple repos or environments, and the Top 10 NHI Issues shows how this problem usually coexists with poor inventory and excessive privilege.
Organisations typically encounter the operational cost of identity leakage only after a repository exposure, credential abuse alert, or customer-facing incident, at which point the term 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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 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 | Addresses secret exposure and improper storage patterns that include code and repository history. |
| NIST CSF 2.0 | PR.DS-1 | Protects data at rest, including credentials and identity artifacts stored in code repositories. |
| NIST SP 800-63 | IAL/AAL | Identity assurance concepts help assess the trust impact of leaked account and authenticator material. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust assumes exposed identity material should not grant broad network or resource access. |
| CSA MAESTRO | Covers agent and workload identity governance, including secure handling of credentials in automation. |
Limit blast radius with segmentation, continuous verification, and tightly scoped service identity access.
