Secret leakage is unavoidable without short-lived NHI controls

At a glance

What this is: This is an analysis of why secret leakage persists and why static credential models leave an avoidable exposure window, especially for NHI environments.

Why it matters: It matters because IAM teams must govern secrets as living NHI assets, not as one-time configuration values, or leaked credentials stay exploitable far too long.

By the numbers:

• Secret leakage is effectively unavoidable at some rate; GitGuardian recorded 28.65 million new secrets leaked to public GitHub in 2025 alone, a 34% year-over-year jump.
• Wiz found 65% of Forbes AI 50 companies leaked verified secrets in places most scanners don’t check: notebooks, logs, VS Code extensions, and support portals.
• Only 5.7% of organisations have full visibility into their service accounts.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read Akeyless's analysis of how to prevent secret leakage

Context

Secret leakage is an NHI governance problem because credentials, API keys, tokens, and certificates behave like live access, not static configuration. Once they leave intended control, they can be reused until they are revoked or expire, which means the real control boundary is the credential lifecycle rather than the repository where it was first exposed.

The article argues that scanning is necessary but incomplete because exposure also happens in notebooks, logs, support portals, and collaboration tools. That makes the operational question familiar to IAM teams: how much damage can a leaked secret do before detection, and how quickly can the credential be made worthless?

For non-human identity programmes, this is a lifecycle issue first and a detection issue second. The practical test is whether an exposed secret still has useful lifetime left when anyone notices it.

Key questions

Q: What breaks when secret scanning is only done before commit?

A: The main break point is enforcement. Local scanning can miss untracked files, skipped hooks, and contributors who never installed the checks. It also does nothing for later changes introduced in pull requests or pipeline steps. Without repeatable server-side validation, organisations end up with optional guardrails instead of reliable control.

Q: Why do API keys and tokens on endpoints increase breach risk so much?

A: Because API keys and tokens act like non-human identities with immediate replay value. Once exposed in collaboration tools, browsers, or AI workflows, they can be used outside the original endpoint without resistance from device controls. Identity teams need visibility, rotation, and revocation, not just endpoint detection.

Q: How should teams decide between secret scanning and dynamic secrets?

A: Use secret scanning to detect mistakes faster, but use dynamic secrets when the cost of a leaked credential is high enough that detection alone is not acceptable. If a copied secret could expose production systems or regulated data, short-lived issuance should be the control that changes the risk profile.

Q: What should teams do when a secret may already be exposed?

A: They should assume the secret is compromised until proven otherwise, revoke it, rotate dependent credentials, and check for secondary copies across repositories, tickets, and collaboration tools. The goal is to limit reuse before an attacker can convert exposure into access. Waiting for confirmation usually gives the attacker more time than defenders have.

Technical breakdown

Why static secrets create a durable exposure window

A static secret is a credential that remains valid until someone manually rotates or revokes it. That creates a long exposure window because a leak is only dangerous if the attacker can use the credential before it is invalidated. Git history, CI/CD logs, support tickets, and public forks all extend that window because copying the secret is often trivial even after the original file is cleaned up. In NHI terms, the problem is not just disclosure but continued authenticity. A leaked secret still proves identity until its lifecycle is explicitly broken.

Practical implication: Treat secret validity as the real risk metric, not merely whether a leak was detected.

Why scanners miss the highest-risk leakage paths

Secret scanners are pattern detectors, not omniscient controls. They are usually strongest in source repositories and weakest in adjacent systems such as notebooks, logs, extensions, and support tooling where credentials are pasted, echoed, or cached outside expected repositories. That matters because modern development environments are distributed across many platforms, and secrets move with the workflow. A scanner can shorten exposure time, but only after a secret exists somewhere the scanner can inspect. It cannot prevent leakage into channels it does not monitor.

Practical implication: Extend secret detection beyond source code into the full developer and support surface.

Dynamic secrets change the identity model from persistent to ephemeral

Dynamic secrets issue a credential on demand and set a time-to-live that ends the credential automatically. That changes the security model from persistent identity to bounded identity, where a copied secret loses value quickly even if it is discovered late. In practice, this is the decisive difference between a credential that remains exploitable for months and one that expires before most detection workflows finish. The article’s example shows why the TTL itself becomes a control boundary, not an implementation detail.

Practical implication: Use short-lived credential issuance to make leakage far less durable than manual rotation can achieve.

Threat narrative

Attacker objective: Use a leaked credential before it expires or is revoked, turning accidental disclosure into authenticated access.

1. Entry occurs when a developer, pipeline, or collaborator places a secret into code, logs, notebooks, or a support system outside the intended control boundary.
2. Escalation follows when the leaked credential remains valid and usable long enough for an attacker or opportunistic finder to authenticate with it.
3. Impact occurs when the exposed secret is used before rotation, turning a single mistake into cloud access, data exposure, or privileged lateral movement.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static secret exposure is a lifecycle failure, not a scanning failure. The article is right to separate detection from prevention because the control gap begins when a credential is issued as a durable object with no enforced expiry. OWASP-NHI and lifecycle governance both point to the same problem: if a secret stays valid after it escapes, the attack surface is already baked in. Practitioners should treat every long-lived secret as a standing NHI risk, not a recoverable typo.

Secret leakage becomes materially worse when the environment assumes repositories are the primary boundary. The article’s examples in notebooks, logs, VS Code extensions, and support portals show that code scanning is only one slice of the real problem. The named concept here is secret leakage blind spots, meaning leakage paths that exist outside the tools most teams monitor first. The practical conclusion is that visibility must follow the workflow, not the source tree.

Dynamic TTL is the control that collapses the value of leaked NHI credentials. A 15-minute credential is not just shorter lived, it changes the attacker economics because exposure and exploitation must now happen inside a very narrow window. That is the central governance lesson for NHI programmes: the shorter the credential lifetime, the less a leak can mature into an incident. Teams should measure whether their secrets have an expiration boundary that meaningfully reduces blast radius.

Secret rotation without inventory is a partial answer, not a governance model. The article points to containment steps after a leak, but containment only works when teams can identify what was exposed, where it was used, and who depends on it. That makes ownership, inventory, and revocation authority part of the control plane, not administrative overhead. IAM teams should view secret response as an offboarding problem for machine identity.

Scanning and dynamic secrets are complementary, but only one of them changes the risk curve. Scanning reduces dwell time after disclosure, while dynamic secrets remove the assumption that a copied credential remains useful. In an NHI programme, that distinction matters because the first control watches for a failure and the second prevents the failure from staying exploitable. Practitioners should prioritise controls that expire access, not just controls that observe exposure.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which helps explain why exposed credentials often stay live longer than teams expect.
• For a broader lifecycle view, the NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding fit together as one control system.

What this signals

Secret leakage blind spots will keep widening as development and support workflows spread across notebooks, chat tools, ticketing systems, and extensions. IAM teams should assume that repository scanning is only one detection layer and align controls with where credentials are actually created, copied, and reused. For a practical baseline, pair this with the OWASP Non-Human Identity Top 10 and the Guide to the Secret Sprawl Challenge.

With the Ultimate Guide to NHIs showing 97% of NHIs carry excessive privileges, secret leakage should be treated as a blast-radius problem as much as a discovery problem. A leaked credential with broad access is a governance failure even when detection is fast, so teams need scoped permissions and rotation policies that reduce the usefulness of every copy.

The forward shift is toward expiration-aware identity design. As more workloads and pipelines rely on machine credentials, programmes that keep static secrets alive will continue to accumulate risk faster than manual response can remove it. The operational question is no longer whether a secret can leak, but how quickly it becomes useless after it does.

For practitioners

• Block obvious secret entry points Enable pre-commit hooks and repository-level push protection so recognizable credential patterns are stopped before they reach shared branches. Extend those checks to CI/CD workflows and build artifacts rather than limiting them to source code.
• Expand scanning beyond the repository Add coverage for notebooks, logs, VS Code extensions, support portals, and container layers because those are common blind spots where verified secrets are pasted or echoed outside normal source control.
• Move high-risk credentials to dynamic issuance Replace hardcoded long-lived secrets with short-lived credentials that expire automatically, then map TTL to the actual task duration so leaked copies lose value quickly.
• Prepare a secret-specific containment playbook Define who can revoke the credential, how downstream integrations are notified, and which audit logs confirm whether the secret was used while valid. Rotation should happen immediately after confirmation, not after a full investigation.

Key takeaways

• Secret leakage is inevitable enough that the real control question is how long a leaked credential stays valid.
• Scanning reduces exposure time, but dynamic secrets and rapid revocation are what materially change the attacker’s window.
• NHI programmes need lifecycle ownership for secrets, because a leaked credential is still an identity until it expires or is revoked.

Key terms

• Secrets Leakage: 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.
• Dynamic Secret: A secret generated on-demand for a specific task and automatically revoked after use or expiry. Dynamic secrets dramatically reduce the risk of credential exposure compared to static, long-lived secrets and are considered best practice.
• 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.
• Exposure Window: The period in which a credential, session, or privilege grant can be exploited before it is revoked or expires. Shorter windows help, but they do not solve the deeper question of whether the access remains justified for the full time it is active.

What's in the full article

Akeyless's full article covers the operational detail this post intentionally leaves for the source:

• The step-by-step prevention checklist for pre-commit hooks, push protection, and repository exclusions.
• The incident containment sequence for rotating exposed credentials and checking downstream dependencies.
• The comparison of scanning, traditional secrets managers, and dynamic secrets in practical deployment terms.
• The Akeyless-specific implementation example showing how dynamic TTL changes the exposure window.

👉 Akeyless's full post covers the leak patterns, remediation timing, and dynamic secret example in more detail.

Deepen your knowledge

NHI governance, machine identity security, and secrets management 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.