Secret leakage is unavoidable without short-lived NHI controls

At a glance

What this is: Akeyless argues that secret leakage is a persistent operational reality, not a rare exception, because scanning alone cannot stop secrets from appearing in code, logs, notebooks, extensions, and support systems.

Why it matters: IAM and NHI teams need to shift from detection-first thinking to short-lived credential design, because leaked static secrets create durable access risk long after the original mistake.

By the numbers:

• 65% of Forbes AI 50 companies leaked verified secrets in places most scanners don't check, according to Akeyless.
• A 15-minute dynamic-secret TTL would have expired the credential before it was ever discovered, according to Akeyless.

👉 Read Akeyless's analysis of secret leakage and short-lived NHI controls

Context

Secret leakage is the exposure of credentials, API keys, tokens, certificates, or passwords in places they should never appear. For IAM and NHI programmes, the problem is not only discovery after the fact, but the reality that static credentials remain usable long after the original leak.

The article's central claim is that prevention and containment are separate jobs. If a leaked secret still has a long TTL or broad privilege scope, scanning only tells you that exposure already happened; it does not remove the access window that makes the leak exploitable.

Key questions

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.

Q: Why do static credentials create more risk than short-lived access tokens?

A: Static credentials create more risk because they remain valid until someone finds and removes them, which gives attackers a durable entry path. Short-lived tokens reduce exposure time, but they still need scope limits and revocation. The real control is the combination of short lifetime, least privilege, and continuous review.

Q: What are the signs that secret scanning is failing to find leaks?

A: The main signals are leaks appearing in notebooks, logs, support portals, and other systems outside source control, plus secrets that remain valid long after discovery. If scanners only report repository findings, the programme is probably blind to the higher-risk surfaces where credentials actually escape.

Q: Should organisations prioritise push protection or dynamic secrets first?

A: If secrets are still being committed to source control, push protection is the first containment step because it stops obvious leaks at the point of entry. If static credentials are already widespread, dynamic secrets become the higher-value next move because they remove the long-lived access problem that scanning cannot solve.

Technical breakdown

Why static secrets keep creating durable exposure

Static credentials create a long-lived trust problem because the credential itself remains valid until someone rotates it. A secret copied into code, logs, notebooks, or support systems can be reused from any of those locations, and Git history makes deletion from the current file irrelevant to earlier commits. In NHI terms, the issue is not just leakage, but persistence of usable authority after leakage. That is why a single mistake can remain an active access path for months. Practical implication: treat any static secret as a standing credential with an indefinite blast radius unless it is explicitly expired and revoked.

Practical implication: model leaked static secrets as standing privilege and rotate them immediately when exposure is confirmed.

Why scanners miss the highest-risk leak paths

Secret scanners are detection controls, not preventive controls. They work after a secret has already landed in a repository or shared system, and they are only as good as the surfaces they inspect. The article highlights blind spots such as notebooks, logs, VS Code extensions, and support portals, which are common collaboration surfaces but often outside default scanning scope. That means scanning reduces dwell time but cannot guarantee discovery, especially when secrets live outside source control. Practical implication: extend detection beyond repositories and pair it with controls that block secrets from being created or committed in the first place.

Practical implication: expand scanning coverage to collaboration and build surfaces, but do not treat scanning as prevention.

How dynamic secrets change the governance model

Dynamic secrets replace a durable credential with one that expires automatically after a short TTL. That changes the governance question from 'Can we find every leak?' to 'How much time can a leaked credential remain useful?' If the credential expires quickly, exposure becomes much less valuable even when discovery is delayed. This is a classic NHI control shift because the control objective moves from post-exposure cleanup to pre-exposure expiry. Practical implication: issue short-lived credentials for workloads and automation so leakage no longer equals long-lived access.

Practical implication: issue short-lived credentials for workloads and automation so leakage no longer equals long-lived access.

Threat narrative

Attacker objective: The attacker wants to turn a single leaked secret into reusable access before the organisation notices or revokes it.

1. Entry occurs when a credential is hardcoded, logged, pasted into a ticket, or otherwise placed into a surface that should not hold live secrets.
2. Credential access follows when the leaked secret is recovered from Git history, collaboration tooling, or another overlooked repository of sensitive data.
3. Escalation happens because the exposed credential is still valid, so the attacker can use standing access rather than burning effort on exploitation.
4. Impact is sustained access to the protected system until the secret is revoked, rotated, or expired.

Breaches seen in the wild

• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secret leakage is a governance problem, not a scanning problem. The dominant failure is not that organisations lack tools to detect exposed credentials, but that they continue issuing credentials whose usefulness survives the leak itself. When a secret remains valid for months, detection becomes a cleanup function rather than a control boundary. The practical conclusion is that NHI governance has to reduce the value of the leaked credential, not just improve the odds of finding it.

Long-lived secrets create latent access debt. Every static credential carries an implicit obligation to monitor, rotate, and revoke it across all the places it can surface. The article shows that obligation expands far beyond source control into logs, support portals, notebooks, and collaboration tools. This is exactly why long-lived secrets are a lifecycle failure mode: the credential outlives the assumption that someone will catch it before reuse.

Secret leakage is now a blind-spot problem across the software and collaboration stack. The article's examples show that repositories are only one exposure surface among several. That means NHI governance cannot be scoped to code scanning, because the same identity artifact can leak through productivity systems the security team rarely treats as primary control points. Practitioners need to govern the full credential footprint, not the repository alone.

Dynamic secrets are the control that collapses the exposure window. The article's 15-minute TTL example illustrates the core shift: a credential that dies before discovery is materially different from one that survives for months. This does not remove leakage, but it changes the meaning of leakage from durable compromise risk to transient exposure. The practitioner takeaway is that expiry, not detection speed, becomes the decisive control variable.

Secret leakage is one of the clearest cases for treating NHI lifecycle as a first-class security discipline. Secret issuance, expiry, revocation, and audit review are not separate hygiene tasks. They are the control system that determines whether a leaked credential is a nuisance or an incident. Organisations that still rely on static secrets are effectively choosing an exposure model, whether they call it that or not.

What this signals

Secret leakage becomes manageable only when the credential itself expires faster than the organisation can rediscover it. That is the governance shift this article points to: leakage still happens, but the exposure window can be made too short to matter operationally. For IAM and NHI teams, the real control question is no longer just detection coverage, but whether every high-risk credential has a bounded lifetime.

Static secret management creates hidden lifecycle debt. Every live credential adds a future obligation to rotate, revoke, notify, and audit across systems that never should have held the secret in the first place. Programmes that cannot answer where secrets live, who can issue them, and how quickly they die are already carrying avoidable identity risk.

Dynamic credentials change the practitioner posture from cleanup to containment. Instead of trying to find every leak after the fact, teams can limit the usefulness of any leaked copy through automatic expiry and narrow scope. That is a stronger operating model for workloads, automation, and privileged access than relying on scanner coverage alone.

For practitioners

• Block secrets before commit Use pre-commit hooks and repository-level push protection so recognizable credential patterns never reach shared branches or public repos.
• Extend detection beyond repositories Scan logs, notebooks, support portals, build artifacts, and container layers, because those are common leak paths that standard repo scans miss.
• Replace static credentials with expiring ones Issue dynamic secrets with short TTLs for workloads, automation, and privileged integrations so leaked copies stop being useful quickly.
• Prepare a leak-response rotation playbook Define who revokes the exposed credential, how downstream integrations are notified, and how audit logs are checked once a leak is confirmed.
• Centralise secret issuance and review Move credential creation into a governed secrets management process so rotation, scope, and expiry are controlled instead of left to individual teams.

Key takeaways

• Secret leakage is best treated as a lifecycle and exposure-window problem, not just a detection problem.
• The scale in the source article is large enough to matter operationally, with millions of leaked secrets and major blind spots outside source control.
• Short-lived credentials and faster expiry reduce the value of a leak more reliably than scanning alone.

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.
• Static Secret: A secret, such as an API key or password, that does not change automatically over time. Static secrets require manual or scheduled rotation and represent a higher security risk than dynamic secrets or managed identities.
• Push Protection: Push protection is a preventive control that blocks some secrets from being committed to public repositories. It reduces accidental exposure during development workflows, but it is not a complete safeguard across all Git-based surfaces. Coverage gaps matter, especially where content can still be published outside the protected path.

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 .gitignore hygiene
• The incident-response sequence for rotating a confirmed leak and checking downstream usage
• The comparison of secret scanning, traditional secrets managers, and dynamic ephemeral secrets
• The case examples showing how long-lived credentials remained exploitable in real incidents

👉 Akeyless's full post covers the leak-path examples, containment sequence, and dynamic-secret TTL guidance

Deepen your knowledge

NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.