TL;DR: Common secrets management myths still leave credentials exposed at runtime, in logs, memory, CI pipelines, private repos and AI tools, even when teams believe vaults or masking are enough, according to Doppler’s analysis. Secrets governance fails when storage is treated as the control instead of the full lifecycle from injection to revocation.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Doppler's blog post: Secrets management myths persist because teams overtrust storage controls while secrets still leak at runtime, in logs, CI/CD and AI tools.
Why it matters: IAM, PAM and platform teams need to govern the full secret lifecycle, because exposure usually happens after issuance, not when the secret first lands in a vault.
Context
Secrets management often fails because teams confuse secure storage with secure use. A vault protects a secret at rest, but once an application retrieves it, the real exposure surface shifts into logs, memory, build systems, developer tools and shared integrations. That is why runtime handling matters as much as issuance.
The same failure pattern shows up across cloud, CI/CD and developer workflows. Secrets leak when processes assume a secret is safe simply because it is centralised or hidden, which means governance has to follow the credential after delivery, not stop at the vault.
Treat static vs dynamic secrets as the baseline distinction here: dynamic delivery changes the risk model by limiting how long a credential exists in a usable form. Once secrets are reused, cached or copied into operational paths, the control objective changes from storage to lifecycle control.
Key questions
Q: How do I stop secrets from leaking at runtime?
A: Stop treating storage as the control boundary and govern the full secret lifecycle instead. Deliver credentials only when needed, keep them short-lived, remove them from memory and logs after use, and revoke them as soon as they are no longer required. Runtime exposure is usually the real leak point, not the vault.
Q: Why do secrets in build logs create such a high-risk failure mode for CI/CD pipelines?
A: Build logs are widely distributed, retained, and often visible to developers, operators, and external systems. Once a secret is echoed into logs, it can be copied, indexed, or reused before anyone notices. In CI/CD environments, that exposure can enable unauthorized access to cloud resources, credentials misuse, and downstream supply chain abuse.
Q: How does dynamic secret delivery reduce exposure?
A: Dynamic secret delivery reduces exposure by issuing credentials only when a workload or agent needs them, then revoking or expiring them quickly after use. That shortens the window in which API keys, tokens, or certificates can be copied from code, images, logs, or configuration files, and limits the value of any leaked secret.
Q: What is the difference between secret scanning and secret revocation?
A: Secret scanning finds exposure, while secret revocation removes the ability to authenticate with the exposed credential. Scanning reduces blind spots, but revocation is what actually breaks attacker reuse and shrinks blast radius.
Technical breakdown
Why vaults do not control runtime exposure
A vault is a storage control, not a usage control. It can protect a credential before an application retrieves it, but it does not govern what happens after the secret enters process memory, configuration, logs or child processes. That distinction matters because many leaks occur during normal execution, not during storage. In practice, the exposure window begins at retrieval and ends only when the credential is revoked, expired or discarded. Without runtime orchestration, a vault becomes a source of truth for location, not for use. See the Secrets Management Guide.
Practical implication: Design controls around retrieval, use and disposal, not just storage, because runtime exposure is where secrets most often leak.
How secrets leak through CI/CD, repos and developer workflows
Secrets spread because modern delivery pipelines copy them into places the original control never anticipated. Environment variables, private repositories, build logs, container inspection commands and local dev shells all create duplicate exposure paths. A secret that was safe in one system becomes unsafe once it is echoed, cached, inherited by a child process or stored in an artifact. The underlying mechanism is amplification: each operational convenience creates another place where the same credential can be observed, replayed or exfiltrated. Read Guide to the Secret Sprawl Challenge.
Practical implication: Limit where secrets can appear in pipelines and developer tooling, because every new copy expands the attack surface.
Why detection alone does not equal containment
Secret scanning is a detection mechanism, not a lifecycle control. It can tell you that a credential has appeared in a repository, log or artifact, but it cannot revoke the credential, remove downstream copies or prevent reuse on its own. That is why scans often create a false sense of completion. Real protection requires the response chain to continue after discovery, because a leaked secret remains valuable until access is invalidated and dependent systems are updated. See the API Key Management Guide.
Practical implication: Connect detection to revocation and prevention workflows, or the organisation will keep finding leaks after the damage is already possible.
Threat narrative
Attacker objective: The objective is to use one leaked credential as a foothold for broader unauthorised access across systems that trust the same secret.
- Entry occurs when a secret is exposed through a repository, log, environment variable, build output or AI interaction that should not have contained it.
- Credential access follows when an attacker or unauthorised insider retrieves the leaked secret from the place it was copied or indexed.
- Escalation happens when the same credential is reused across services, pipelines or cloud resources, widening the reachable trust boundary.
- Impact arrives when the exposed secret is used for unauthorised API calls, data access, code changes or further secret harvesting.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- Toyota T-Connect key exposure 2022: A subcontractor left a T-Connect server key on public GitHub from 2017 to 2022; 296,019 customers' emails were exposed, misuse unknown.
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
Secrets management fails when teams treat storage as the control boundary: the real control problem begins after a credential is retrieved. Vaults, encrypted stores and masked output do not prevent runtime leakage into memory, logs, build artifacts or developer tooling. The operating assumption that “secured at rest means secured in use” is no longer defensible. The practitioner conclusion is that secrets governance must be measured by how well it controls the credential after delivery, not by how well it stores it.
Secret sprawl is a lifecycle problem, not a tooling problem: multiple managers, private repos, CI systems and local workflows create overlapping copies of the same credential. That produces fragmented ownership, uneven revocation and long exposure windows. The field needs to stop describing this as a storage issue and start treating it as lifecycle drift across delivery paths. The practical conclusion is that governance has to follow the secret across every operational surface it touches.
Runtime delivery is the named concept that matters here: secrets become dangerous when they persist beyond the moment of use. Dynamic injection, short-lived credentials and immediate disposal are not convenience features, they are the controls that narrow the window of exploitation. This is why lifecycle processes for managing NHIs matter even in a secrets-management discussion. The practitioner conclusion is that lifecycle governance must be enforced at issuance, use and revocation, not only at rest.
AI tools and agents expand the secrets surface without changing the underlying rule: prompts, integrations and code suggestions can expose credentials just as reliably as logs or repos. The governance failure is assuming that a conversational interface is outside the secrets boundary. It is not. The practitioner conclusion is to treat any AI-connected workflow that can see or reference credentials as part of the same control environment.
Detection without automated response is incomplete governance: scanning finds exposed secrets, but it does not stop reuse, revoke access or clean up duplicate copies. That creates a gap between awareness and containment that attackers can exploit quickly. The practitioner conclusion is that the discipline now sits at the intersection of discovery, revocation and prevention, not just alerting.
From our research library:
- 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned", according to the 2024 State of Secrets Management Survey.
- 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to the 2024 State of Secrets Management Survey.
- Read next: Ultimate Guide to NHIs — Static vs Dynamic Secrets
What this signals
Runtime secret delivery: secrets need to be governed at the moment of use, because the exposure window opens after retrieval and closes only when the credential is discarded. That changes the control objective from vault design to lifecycle enforcement, which is why teams need to redesign pipelines around ephemeral access rather than persistent values.
A mature programme will also treat repositories, CI logs, developer machines and AI-assisted workflows as one secret surface, not four separate problems. The practical shift is to connect discovery, revocation and prevention so that a leaked credential cannot remain useful after it is found.
For practitioners
- Enforce runtime secret injection Deliver credentials only when a process needs them, then discard them immediately after use so they do not persist in environment variables, memory or files. See the Secrets Management Guide.
- Block secrets from CI/CD output Remove commands, debug traces and error handling that print tokens or keys, and fail pipelines when log scanning finds credential patterns. Read Guide to the Secret Sprawl Challenge.
- Automate rotation and revocation Replace manual rotation with policy-driven replacement so leaked credentials can be invalidated quickly across systems that still trust them. Read Guide to NHI Rotation Challenges.
- Scope developer credentials tightly Restrict local and test credentials to the minimum access needed, and avoid reusing production secrets in developer machines or shared environments.
- Treat AI integrations as secret-bearing systems Prevent prompts, assistants and connected agents from reading or printing real credentials, and isolate them from systems that hold secrets.
Key takeaways
- Secrets management fails when teams protect only stored credentials and ignore how those credentials behave once applications begin using them.
- The article’s examples show that leaks can come from repositories, pipelines, developer machines, logs and AI tooling, which broadens the governance problem beyond vaults.
- The strongest control pattern is short-lived delivery with automated revocation, because runtime exposure is where leaked secrets become exploitable.
Related NHI Mgmt Group resources: Ultimate Guide to NHIs: Static vs Dynamic Secrets · Guide to the Secret Sprawl Challenge · API Key Management Guide
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 addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 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 centres on secrets leaking from repos, pipelines, logs and AI workflows. |
| NHI-07 — Long-Lived Secrets | Manual rotation and reused credentials are a core theme of the article. | |
| NHI-05 — Overprivileged NHI | The article repeatedly shows secrets and integrations carrying more access than they need. | |
| Recommendation — Scan every operational surface for exposed secrets and revoke any credential that appears outside intended storage. Replace manual rotation with short-lived credentials and automate revocation before secrets outlive their task. Scope each secret to the minimum access required and remove broad reuse across systems. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The post argues that secret use and access scope must be governed after issuance, not just at rest. |
| Recommendation — Review entitlements tied to secrets so access is limited to the task and revoked when no longer needed. | ||
| CIS Controls v8 | CIS-5 — Account Management | Secrets function as accounts or authenticators whose lifecycle must be tracked and removed. |
| Recommendation — Maintain ownership, rotation and retirement records for every secret-backed account or token. | ||
Key terms
- Secrets Management: The discipline of securely storing, distributing, rotating, and auditing secrets across an organisation's systems and pipelines, typically implemented via a centralised secrets vault such as HashiCorp Vault, AWS Secrets Manager, or Akeyless.
- CI/CD Masking: CI/CD masking is the hiding of sensitive values in build and deployment output, such as logs, console text, and pipeline variables. It works by redacting secrets like API keys, tokens, and passwords before they are displayed or stored, so they are less likely to be exposed during automated software delivery.
- 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.
- 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.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org