Secrets sprawl is becoming an identity problem for DevOps teams

At a glance

What this is: This analysis argues that secrets sprawl is turning DevOps authentication into an identity governance problem, especially as AI agents expand the number of non-human identities that must authenticate.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern short-lived workload access, not just rotate static secrets, if they want speed and security to coexist.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Aembit's analysis of secrets sprawl, workload identity, and AI agent access

Context

Secrets sprawl is the accumulation of hard-coded credentials, long-lived keys, and scattered tokens across code, pipelines, and environment variables. In an IAM context, it creates a governance gap because access is no longer centrally visible, and revocation becomes reactive instead of lifecycle-driven. As AI agents multiply the number of non-human identities, the same problem expands into new runtime environments and more brittle authentication paths.

The article’s core point is that static secrets do not scale in distributed systems or agentic workflows. Once credentials are copied into repositories, CI/CD variables, scripts, and vaults, the organisation inherits persistent attack surface and operational drag. That is a familiar failure mode for NHI programmes, but it is now colliding with workload identity and agentic AI adoption at the same time.

Key questions

Q: How should security teams replace hard-coded secrets in CI/CD pipelines?

A: Security teams should move CI/CD pipelines to workload identity and runtime attestation so the pipeline receives short-lived credentials only when needed. That removes the stored bootstrap secret, reduces leakage in variables and scripts, and makes revocation automatic when the token expires. The key is to design for identity proof, not secret distribution.

Q: Why do long-lived service account keys create more risk than they solve?

A: Long-lived service account keys create standing access that survives beyond the workload, so one leak can enable repeated use, lateral movement, or delayed abuse. They also make rotation brittle because the organisation must track every copy and dependency. Short-lived, scoped credentials reduce both exposure and operational drag.

Q: What do security teams get wrong about secrets scanners?

A: Teams often treat scanning as the control, when it is only detection. A scanner can find exposed credentials after they are already committed or shared, but it cannot stop an attacker from using a still-valid secret. Effective governance pairs scanning with automatic revocation and identity-based access.

Q: How do AI agents change secrets governance for IAM teams?

A: AI agents increase the number of identities that need access and the frequency with which credentials are used. That makes static secrets harder to govern because the same token may be exercised across many systems at machine speed. IAM teams should treat agents like workload identities, with scoped access and short lifetimes.

Technical breakdown

Why static secrets break down in distributed pipelines

Static secrets assume the credential can be stored, copied, and rotated without changing the trust model. In practice, every copied key creates another place where access can leak, expire, or outlive the workload that uses it. The operational problem is not just theft. It is that secrets become embedded in build systems, manifests, and environment variables, so authentication turns into a maintenance workflow rather than an identity control. That is why incidents often surface as broken deployments, not only as security alerts.

Practical implication: replace persistent pipeline secrets with workload identity flows that remove stored credentials from build paths.

Secret zero and the bootstrap trust problem

Secret zero is the first credential needed to reach a secrets vault or other protected service. If the bootstrap credential is static, the system has already reintroduced the very secret it was meant to eliminate. That creates recursion: the vault protects secrets, but the vault access path still depends on a secret somewhere. Identity-based attestation breaks that loop by letting the workload prove who it is at runtime and receive a short-lived token without a stored bootstrap key.

Practical implication: design bootstrap flows around attestation, not around a permanent vault password or access key.

How ephemeral workload identity changes the access model

Ephemeral workload identity ties access to the runtime context of a service, job, or AI agent. Instead of pre-placing credentials, the platform evaluates identity, environment, and policy in real time and issues a scoped token for a narrow purpose. That reduces standing exposure and makes revocation simpler because access expires naturally. For AI agents, this matters even more because the same identity may need to call multiple APIs dynamically, which makes static secret sprawl multiply faster than in traditional microservices.

Practical implication: scope each token to a single workload, target system, and short time window, then let expiry do part of the governance work.

Threat narrative

Attacker objective: The attacker wants durable, repeatable access that bypasses human approval and survives ordinary secret rotation cycles.

1. Entry begins when hard-coded API keys, CI/CD variables, or leaked repository secrets give an attacker a reusable authentication path into pipelines or adjacent cloud services.
2. Escalation follows when those credentials provide standing access to databases, admin consoles, or cloud APIs that were never meant to be reachable from the original workload.
3. Impact occurs when the attacker uses persistent tokens to move laterally, exfiltrate data, or manipulate build and deployment systems at scale.

Breaches seen in the wild

• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Static secrets are now a governance liability, not just a hygiene issue. Secrets sprawl turns authentication into an uncontrolled distribution problem across code, pipelines, and tools. That means the risk is not confined to one leaked key. It is the cumulative effect of many long-lived credentials that outlast the workloads they protect. For NHI programmes, the relevant control question is lifecycle visibility, not merely secure storage.

Identity-based access is the architectural answer because it removes the need to manage secrets as assets. When a workload proves identity at runtime and receives a short-lived token, the governance model changes from possession to assertion. That aligns better with OWASP-NHI and zero trust thinking because access is evaluated at the point of use instead of being inherited from a stored credential. Practitioners should treat this as a shift in control plane design, not a point product decision.

Secret zero is the named failure mode hidden inside many modern access stacks. The bootstrap trust problem was designed for systems where a credential could be safely placed before the first request. That assumption fails when pipelines, services, and AI agents need to authenticate continuously across changing trust boundaries. The implication is that teams must rethink how trust is established at startup, because the old bootstrap model recreates the very secret it tries to eliminate.

AI agents make secrets sprawl worse because they expand both credential count and usage frequency. A human might hard-code a key once and forget it. An agent can repeat the same pattern across multiple services at machine speed, multiplying persistent attack vectors. That makes workload IAM and NHI governance converge around the same problem: who or what gets access, for how long, and under which runtime conditions.

Identity blast radius: the useful unit of analysis is no longer the single secret but the full span of systems a credential can reach before it expires or is revoked. That concept is especially important for CI/CD and agentic workflows where one token can touch code, cloud APIs, and data stores. Practitioners should size controls to the blast radius, not the secret itself.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
• Internal repositories are 6x more likely to contain secrets than public ones, with 32.2% versus 5.6%, according to the State of Secrets Sprawl 2026.
• For teams moving from static secrets to workload identity, Guide to the Secret Sprawl Challenge helps frame the remediation work beyond detection.

What this signals

Secret sprawl is no longer a code-scanning problem. The operational signal is that credentials now appear across repositories, CI systems, and collaboration tools, which means governance has to extend beyond repository hygiene and into lifecycle control for machine access. Teams that still rely on periodic rotation alone will keep chasing symptoms after exposure has already happened.

Identity proof is becoming the control surface for pipelines and AI workloads. The more systems that authenticate on behalf of software, the less useful static credential models become. That is why NHI and workload identity programmes should converge on short-lived issuance, explicit scoping, and revocation that is tied to runtime context rather than manual cleanup.

Credential archaeology is a sign of an access model that has lost traceability. When engineers have to search configs, vaults, and tickets to find why a deployment failed, the organisation has already exceeded its governance capacity. For practitioners, the next step is to reduce credential footprint and use attested identity flows before the next pipeline failure exposes the same weakness again.

For practitioners

• Replace stored pipeline secrets with attested workload identity Use identity proof at runtime to issue short-lived credentials for CI/CD jobs, services, and agents. Remove hard-coded keys from build variables, scripts, and manifests so authentication is no longer dependent on a persisted secret.
• Map every bootstrap path to a secret zero dependency Inventory how each workload first reaches a vault, API, or database, then identify where the initial credential still exists as a permanent key, token, or password. If bootstrap requires a secret, the system still depends on secret zero.
• Set expiry and scope as default controls for machine access Issue tokens that are narrow in scope, tied to one workload or agent context, and automatically expire after task completion. Treat standing credentials as exceptions that require explicit justification and review.
• Remove credentials from code and pipeline review as a detection-only task Combine pre-commit scanning, repository checks, and runtime issuance so leaked secrets cannot remain valid long enough to matter. Detection without revocation still leaves the identity usable.
• Govern AI agent access as workload identity Assign each agent a distinct identity, limit its API reach to the smallest viable set, and evaluate access based on execution context rather than developer convenience. That prevents agent sprawl from becoming secret sprawl.

Key takeaways

• Secrets sprawl is a governance failure because it creates durable credentials that outlive the workloads they protect.
• The scale of exposure is already large enough that detection-only programmes cannot keep pace without automatic revocation and identity-based access.
• Practitioners should shift from secret storage to runtime identity proof so pipelines and AI agents can authenticate without persistent credentials.

Key terms

• Secrets sprawl: Secrets sprawl is the uncontrolled spread of credentials, tokens, keys, and certificates across code, pipelines, collaboration tools, and infrastructure. It matters because each copy increases exposure, complicates revocation, and weakens governance when no single system can tell which secret is still in use.
• Secret zero: Secret zero is the initial credential or trust path required to reach a protected system such as a vault, API, or database. In modern access architectures, it is the hidden bootstrap problem that reintroduces static trust unless the workload can prove identity without first presenting a permanent secret.
• Workload identity: Workload identity is a machine or application identity used to authenticate software at runtime rather than through a manually stored secret. It enables short-lived, policy-based access that can be issued after verification of context, environment, and posture instead of depending on copied credentials.
• Identity-based access: Identity-based access is a model where a workload proves who or what it is and receives scoped credentials for a limited purpose. For NHI programmes, it replaces static secret distribution with runtime issuance, making access easier to govern and easier to revoke when the task ends.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Aembit: Secrets sprawl is becoming an identity problem for DevOps teams. Read the original.