TL;DR: GitGuardian's November 17 webinar frames the real problem as credential risk that persists inside and outside the vault, where storage alone does not resolve exposure, sprawl, or lifecycle control gaps. The issue is governed as a whole credential layer problem, not a vault-only tooling problem.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on GitGuardian's event briefing: Credential risk spans both vault-managed and out-of-vault secrets, so governance has to cover the full credential layer.
Why it matters: IAM, PAM, and NHI teams need to treat vault coverage, secret discovery, and revocation as one governance problem rather than separate operational silos.
👉 Register for GitGuardian's webinar on securing credentials inside and outside the vault
Context
A vault is only one control point in a broader credential lifecycle. If secrets also exist in code, CI pipelines, developer tooling, and ad hoc stores, then the governance problem is not storage alone but discoverability, ownership, and revocation across the whole credential layer.
GitGuardian's webinar topic points to a common programme gap: teams often centralise some secrets while leaving other credential paths unmanaged. That leaves blind spots in both NHI governance and developer workflow security, especially where credentials are created, copied, or reused outside approved systems.
The useful question is not whether a vault exists, but whether the organisation can account for every credential type across its lifecycle. secrets sprawl is the structural issue this kind of briefing is meant to surface.
Key questions
Q: How should security teams govern secrets across code, vaults, and collaboration tools?
A: Treat secrets as lifecycle-bound identities, not static strings. Security teams should inventory them across code, vaults, tickets, chat, and build systems, assign an owner and purpose to each one, and enforce rotation and revocation through a single process. Discovery without ownership leaves valid access scattered across the enterprise.
Q: What is the difference between secret storage and secret governance for agents?
A: Secret storage is about where credentials sit. Secret governance is about who or what can reach them, under what conditions, and whether that access is intentional. For AI agents, governance matters more because a secret that is reachable in runtime can be used even if it is encrypted at rest.
Q: How can developer workflows expose credentials even when a vault is used?
A: Developer workflows can still expose credentials when secrets are copied into source files, build logs, environment variables, container images, CI variables, or local caches before they ever reach the vault. A vault only protects credentials after they are stored there. Controls such as pre-commit checks, CI secret detection, short-lived tokens, and automated rotation reduce that exposure.
Q: When should organisations prioritise secret scanning over vault adoption?
A: Organisations should prioritise secret scanning first when credentials may already be exposed in repositories, tickets, logs, chat, or build artefacts. Secret scanning finds live secrets in places a vault cannot protect, then supports rapid revocation and rotation. Vault adoption still matters for future handling, but scanning addresses existing leakage and shadow credential use.
Background and context
Why vaults do not eliminate credential sprawl
A vault reduces exposure by centralising storage, but it does not remove the conditions that create secrets in the first place. Credentials still get copied into environment variables, build logs, local config files, and vendor integrations. Once that happens, the control surface expands beyond the vault and into developer workflows, CI/CD systems, and runtime services. The architectural issue is that storage control and usage control are not the same thing. A credential can be safely stored and still be unsafe in circulation if its distribution, revocation, or inheritance path is unmanaged. See the Secrets Management Guide.
Practical implication: Treat vault deployment as a storage control, not a complete lifecycle control.
How credential layer governance works across inside and outside the vault
Credential layer governance is the set of controls that tracks where secrets are created, where they are stored, who can retrieve them, and where they are used. Inside the vault, the focus is on access policy, rotation, and revocation. Outside the vault, the problem shifts to detection, cleanup, and preventing accidental reuse. The real failure mode is fragmentation: one team manages the vault, another manages application secrets, and nobody owns the full path from issuance to retirement. That fragmentation is what lets old credentials remain active after the system that issued them has changed. See the API Key Management Guide.
Practical implication: Map ownership for every credential path from issuance through retirement.
Why developer handling still drives secret exposure
Developer behaviour remains a major determinant of secret risk because many exposures happen before a secret ever reaches a managed store. Hardcoding, copying, test reuse, and convenience-driven sharing all create durable exposure paths that a vault cannot retroactively fix. The technical problem is not just bad storage discipline, but uncontrolled propagation. In practice, any credential policy that ignores how developers create and move secrets will miss the highest-frequency leak points. That is why runtime discovery and pre-commit or pre-push detection matter as much as vault-side controls.
Practical implication: Put leak detection in the developer workflow, not only in the vault.
NHI Mgmt Group analysis
Vault-centric programmes fail when they treat storage as the control instead of one node in a credential lifecycle. A vault can reduce one class of exposure, but it does not govern every copy, reuse, or shadow path that secrets take through development and runtime environments. The field mistake is to equate centralisation with control completeness. Practitioners need to judge governance by whether the organisation can account for credentials across their full lifecycle, not by whether a vault exists.
Secrets sprawl is the named governance gap this topic exposes. The problem is not simply that secrets exist outside a vault, but that no single team owns the full credential layer from issuance to retirement. That gap is visible when development workflows, pipelines, and application runtimes all hold different versions of the same secret. The implication is that NHI governance has to be built around inventory and ownership, not just storage architecture.
Developer workflow is the real enforcement plane for many credential failures. If secrets are introduced through local files, copy-paste, or pipeline variables, then the most important controls sit upstream of vault policy. This is why secret scanning, workflow guardrails, and revocation discipline matter together. Organisations that wait for secrets to enter a vault before governing them are already too late.
Credential governance must now span both managed and unmanaged surfaces. The industry is moving toward a model where vaults, developer tools, runtime services, and SaaS integrations all become part of the same identity perimeter. That perimeter is only as strong as the weakest credential path. The practical conclusion is that security teams should stop asking whether secrets are “in the vault” and start asking whether they are governable wherever they appear.
From our research library:
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Secrets sprawl will keep widening the control gap. As organisations add more integrations, more credentials will exist in places a vault does not automatically govern. The operational challenge is not just storage centralisation, but continuous discovery across development, deployment, and runtime surfaces.
Teams that only measure vault adoption will miss the real exposure pattern. The better signal is whether the same credential can be found, copied, and reused outside approved control points without being detected.
Lifecycle ownership is becoming the decisive control boundary. A credential that cannot be tied to one owner, one system, and one retirement path is already drifting out of governance. The implication for programme leaders is to treat credential sprawl as a governance failure, not a tooling gap.
For practitioners
- Define credential ownership across the full lifecycle Assign a responsible owner for issuance, storage, rotation, and retirement for every secret type, including those that never enter a vault.
- Extend secret discovery into development workflows Scan repositories, CI/CD variables, local configuration files, and logs for credentials so unmanaged copies are found before they become persistent exposure.
- Separate storage controls from usage controls Review whether vault policies also govern retrieval, redistribution, and downstream use, or whether those controls are handled elsewhere and left inconsistent.
- Rationalise duplicate secrets paths Reduce parallel storage locations so the same credential is not managed differently by platform teams, developers, and application owners.
Key takeaways
- The central risk is not the absence of a vault, but the absence of governance over every copy and reuse path for credentials.
- Secrets management remains incomplete when developer workflows, CI/CD, and runtime services can still create unmanaged exposure.
- Programme owners should measure whether each credential has a clear owner, lifecycle, and revocation path across all storage locations.
Related NHI Mgmt Group resources: Ultimate Guide to NHIs: Static vs Dynamic Secrets · Secrets Management Guide · Guide to the Secret Sprawl Challenge
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Secret leakage is central when credentials spill beyond the vault into code, logs, and pipelines. |
| NHI-07 — Long-Lived Secrets | Vault sprawl often hides secrets that remain valid longer than their intended use. | |
| Recommendation — Scan and revoke exposed secrets wherever they appear outside approved storage. Replace long-lived secrets with short-lived credentials where operationally possible. | ||
| CIS Controls v8 | CIS-5 — Account Management | Credential lifecycle ownership maps to account and credential management discipline. |
| Recommendation — Track every secret-bearing account and remove access paths that outlive business need. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Credential retrieval and reuse depend on controlled permissions and entitlements. |
| Recommendation — Limit who can retrieve, copy, or reuse secrets across the environment. | ||
Key terms
- 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.
- 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.
- Credential Lifecycle: Credential lifecycle is the process of issuing, rotating, expiring, and revoking secrets, certificates, and tokens across their usable life. For non-human identities, lifecycle discipline is the core control that separates temporary access from persistent exposure.
- 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.
What to expect at the briefing
GitGuardian's full event briefing covers the operational detail this post intentionally leaves for the source:
- Live discussion of securing credentials stored outside a vault in developer and runtime environments
- Practical commentary on how teams handle secret sprawl across code, pipelines, and integrations
- Speaker perspectives from GitGuardian and 1Password on the boundaries of vault-based control
- Questions and answers on governance gaps that appear when secrets are created outside approved storage
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 4, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org