Secrets sprawl is becoming an identity problem for DevOps teams

At a glance

What this is: This is an analysis of why secrets sprawl in DevOps is really an identity governance problem, with ephemeral workload credentials positioned as the practical alternative to static secrets.

Why it matters: It matters because IAM and NHI teams have to govern workload access in ways that remove credential archaeology, limit blast radius and support AI agents as well as traditional pipelines.

Context

Secrets sprawl is the accumulation of hard-coded keys, shared tokens and other stored credentials across code, pipelines, vaults and configuration layers. In identity terms, the problem is not storage alone but governance: each credential becomes a persistent access path that outlives the workload it was meant to protect.

For DevOps teams, that creates both operational friction and security debt. Expired keys, manual rotation and hidden dependencies slow delivery, while static secrets widen the window for misuse, leakage and lateral movement across workloads and tools.

The article’s core claim is that this is no longer just a secrets management issue. As pipelines, microservices and AI agents depend on more machine-to-machine access, the underlying control problem is how identity is issued, scoped and retired across the workload lifecycle.

Key questions

Q: What breaks when secrets are hardcoded into DevOps pipelines?

A: Hardcoded secrets break rotation, ownership, and offboarding at the same time. They become embedded in repositories, build systems, and configuration files, which means the credential can survive long after the workflow changes. That creates hidden persistence and makes remediation dependent on finding every copy first.

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. Static credentials remain valid long after the task ends, which means stolen or shared secrets can be replayed outside the intended scope and become a direct path to privileged access.

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. If the access can be issued on demand and expires automatically, JIT usually lowers blast radius more effectively than standing credentials. The decision should be based on task duration and exposure cost, not convenience.

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.

Technical breakdown

Why static secrets create persistent access paths

Static secrets behave like durable credentials, even when teams intend them to be temporary. Once a key, token or password is embedded in a repository, environment variable or CI/CD variable, it can be copied, reused and forgotten long after the original task ends. That turns a convenience choice into a standing access path. Secrets managers reduce exposure but do not remove the underlying dependency on a bootstrap credential. The real technical issue is that the secret exists outside runtime context, so its privilege is not naturally tied to the workload, the task or the moment of use.

Practical implication: Treat every static secret as a standing access path and inventory where it can still be replayed, not just where it is stored.

How ephemeral workload identity changes authentication

Ephemeral, identity-based credentials replace stored secrets with short-lived access issued at runtime. A workload proves who it is through attestation or another identity signal, then receives a scoped token for a specific target system and purpose. This is structurally closer to federated human identity than to traditional secret distribution. The control shift matters because the credential exists only long enough to complete the task, reducing the value of theft and simplifying revocation. In practice, the authentication event becomes the policy decision point, not a secret copied into the environment.

Practical implication: Move trust decisions to issuance time so access is granted from workload identity rather than from reusable stored credentials.

Why AI agents intensify secrets sprawl

AI agents increase the density and frequency of machine-to-machine access. Unlike a microservice that calls a limited set of systems, an agent may call APIs, databases and internal services repeatedly, often under changing execution context. If each integration depends on a stored key, the number of persistent secrets scales with the agent’s toolset and usage patterns. That creates more attack surface and more governance overhead. The article’s point is not that agents are special because they are AI. It is that their runtime variability makes static credential models even less defensible.

Practical implication: Classify AI agents as high-churn workload identities and avoid embedding reusable secrets into agent workflows.

Threat narrative

Attacker objective: Obtain persistent access to workloads and internal platforms by abusing secrets that were meant to be temporary.

1. Entry begins when credentials are hard-coded into code, configs or CI/CD variables, creating a durable foothold for misuse or theft.
2. Escalation occurs when expired or shared secrets are reused across pipelines and services, giving the same credential broader reach than intended.
3. Impact follows when attackers or insiders use those persistent credentials to reach admin platforms, internal systems or cloud resources that should have been time-bound.

Breaches seen in the wild

• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

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

NHI Mgmt Group 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.

Static credential models create a secret-zero dependency that modern pipelines cannot scale. Even a well-run secrets manager still depends on a bootstrap trust path to reach the vault. That means the control architecture assumes a secret exists before identity can be established, which is the wrong premise for ephemeral workloads. Practitioners need to recognise this as an architectural constraint, not an implementation flaw.

Ephemeral workload identity is the more accurate control model for pipelines and agents. Short-lived credentials align access with task execution, which reduces the duration of misuse and narrows blast radius. This is particularly relevant where CI/CD jobs, microservices and AI agents all need machine-to-machine authentication across multiple systems. The governance implication is that access should be issued from identity context, not inherited from stored secrets.

Agentic AI turns secrets sprawl from a DevOps nuisance into a scaling problem for the entire identity stack. An agent that calls many tools at machine speed multiplies the consequences of every static secret it can reach. That does not make the control problem new, but it does make the mismatch between runtime behaviour and static credentials impossible to ignore. Teams should treat agent access as workload identity with tighter issuance discipline, not as another app integration.

Identity blast radius is now the right lens for secrets governance. The useful question is no longer how many secrets exist, but how far one leaked credential can reach across pipelines, databases and third-party services. That lens connects OWASP-NHI thinking, Zero Trust logic and DevOps reality into one governance model. Practitioners should measure and reduce the scope of each credential before worrying about cosmetic secrets hygiene.

From our research library:

• 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.
• Read next: Ultimate Guide to NHIs

What this signals

Ephemeral credential issuance is the real control boundary: if a workload can prove its identity at runtime, access should be minted for the task and discarded when the task ends. That shifts governance from post-hoc secret hunting to pre-use trust decisions, which is exactly where DevOps pipelines and AI agents need it.

Static secrets and manual rotation still dominate many environments, but that model does not fit workloads that spin up, call multiple services and disappear quickly. The practical effect is that teams end up managing exceptions instead of access, which is why identity-led design is becoming a baseline requirement for modern delivery pipelines.

For practitioners

• 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.
• Treat AI agents as high-churn identities Inventory every API, database and internal service an agent can call, then govern those access paths as dynamic workload identities rather than static integrations.
• Remove credential archaeology from delivery Measure how often developers have to chase expired or missing secrets, and use that signal to prioritise identity-based access over manual rotation workflows.

Key takeaways

• 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.
• The scale of the problem is already visible in everyday delivery friction and in the persistence of long-lived secrets that keep working long after the workload changes.
• Ephemeral, task-scoped credentials reduce the blast radius of leaked secrets and make DevOps governance more aligned with how modern workloads actually authenticate.

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.
• Ephemeral Credentials: Ephemeral credentials are short-lived access artefacts issued for a limited task or session. They reduce the window for abuse, but they only improve security when paired with strong scope limits, telemetry, and automatic revocation at task completion.
• Secret Zero: Secret zero is the first credential needed to reach a secrets store, identity broker, or protected system. It is the root trust dependency that often survives even when everything else is rotated. If that initial credential is exposed, the rest of the secret model can collapse very quickly.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.

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.