TL;DR: Hard-coded keys, long-lived credentials, and scattered vaults create brittle delivery pipelines and persistent attack vectors, according to Aembit’s analysis. The real shift is from treating secrets as stored assets to treating access as an identity problem, where ephemeral, policy-based credentials reduce both rework and exposure.
Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “Secrets Sprawl is Killing DevOps Speed – Here’s How to Fix It”.
Key questions
Q: What breaks when secrets are hardcoded into DevOps pipelines?
A: Hardcoded secrets break rotation, ownership, and offboarding at the same time.
Q: Why do static credentials create more risk for AI agents than for traditional workloads?
A: AI agents execute quickly, can chain actions across systems and may terminate before manual review ever happens.
Q: How should teams decide when just-in-time access is better than long-lived secrets?
A: Teams should prioritise just-in-time access when a workload reaches sensitive data, production systems, or third-party services and does not need persistent reuse.
Practitioner guidance
- Audit hard-coded and long-lived credentials Map credentials across repositories, CI/CD variables, config files and environment stores, then identify which ones still grant live access to production systems.
- Replace bootstrap secrets with workload identity Use runtime identity signals such as attestation or OIDC-backed trust so pipelines and services can obtain short-lived credentials without a stored secret zero.
- Scope credentials to the task and target Issue credentials that are time-bound and system-specific, so a pipeline or agent cannot reuse the same token across unrelated services.
Bottom line: Secrets sprawl is not only a housekeeping issue. It is an identity control problem because reused credentials create standing access paths across code, pipelines and services.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Secrets sprawl is an identity governance problem, not just a storage problem. The article shows that the real failure is the persistence of access paths after the business need has changed. When credentials are scattered across code, pipelines and environment variables, governance loses track of who or what can still authenticate. The practical conclusion is that lifecycle control, not vault placement, is the core issue for DevOps identity.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What does identity-based access change for DevOps governance?
A: Identity-based access changes governance by moving control from secret storage to issuance, scope and expiry. Instead of certifying a growing inventory of credentials, teams govern which workloads can request access, what they can reach and how long the access lasts. That aligns DevOps operations with Zero Trust principles and gives security teams a clearer boundary to enforce.
👉 Read our full editorial: Secrets sprawl is becoming an identity problem for DevOps teams