TL;DR: DevOps teams can reduce pipeline friction by replacing static secrets with short-lived workload identities, which Aembit argues improves security while preserving developer velocity. The deeper issue is that access controls built around long-lived credentials do not scale cleanly across cloud, data centre, and emerging AI workloads.
At a glance
What this is: This is an analysis of why pipeline access works better when teams replace static secrets with workload identity and short-lived credentials.
Why it matters: It matters because IAM, PAM, and NHI programmes have to reduce credential sprawl without adding release friction, especially across cloud, data centre, and emerging AI workloads.
Context
DevOps teams often inherit a mismatch between how software ships and how access is governed. Pipelines need machine-to-machine authentication, but many organisations still bolt on static secrets, shared keys, and manual rotation workflows that were never designed for high-frequency release pipelines.
The article’s core claim is that the problem is access, not secrets. For NHI governance, that means workload identity becomes the control point for cloud, data centre, and emerging AI-adjacent workloads, while secrets management becomes a symptom to reduce rather than the primary operating model.
Key questions
Q: How should security teams reduce secrets sprawl in Azure DevOps pipelines?
A: Start by inventorying every secret location, including variable groups, YAML, Key Vault references, and repository history. Then decide which values can move to runtime-only retrieval and which must be rotated on a fixed cadence. The goal is to eliminate unknown persistence paths and make every secret traceable to an owner and expiry point.
Q: Why do static pipeline credentials create more risk than teams expect?
A: Static credentials persist across runs, so one exposed key can be reused long after the original build completed. That makes compromise easier to replay and harder to contain, especially when the same credential is shared across environments or services. The risk is not only leakage but persistence, because the credential outlives the task it was meant to serve.
Q: What are the signs that access management is becoming unmanageable in a DevOps environment?
A: Common signs include rising ticket volume, frequent manual exceptions, developers sharing credentials, and teams using ad hoc workarounds to keep delivery moving. Another warning signal is when security, IT, and engineering describe the same access process differently. That usually means controls are fragmented, auditability is weak, and the environment is becoming harder to govern.
Q: What happens when workload identity is attempted without consistent governance?
A: You get fragmented policies, duplicated authentication patterns, and partial adoption that leaves some workflows on static secrets anyway. That produces a mixed estate where the most sensitive pipelines may still rely on reusable credentials while others are ephemeral. The result is uneven control, not a clean identity model, which preserves the original risk in another form.
Technical breakdown
Why static secrets fail in pipeline authentication
Static credentials create a long-lived trust relationship between the pipeline and the target service. In practice, that means the same access key, client secret, or shared token can be reused across runs, environments, and teams, which increases the blast radius when it leaks. The mechanism is weak not because secrets are inherently bad, but because they are detached from runtime context. When the pipeline identity is not bound to the execution event, the organisation has to compensate with rotation, storage controls, and manual oversight that do not scale well in DevOps.
Practical implication: Treat persistent pipeline secrets as a governance defect, not just a hygiene issue.
How workload identity changes DevOps access management
Workload identity binds access to the runtime identity of the pipeline or workload, then issues short-lived credentials only for the task being executed. That shifts authentication from something developers manage to something the platform provisions on demand. In the article’s example, a GitLab job can present its native identity and receive a credential type that the target service accepts, even when standard federation does not fit neatly. The architectural point is that access becomes policy-driven and ephemeral, which reduces the need to store reusable secrets in the pipeline.
Practical implication: Design pipeline access so credentials are minted per run rather than stored for reuse.
Why multi-environment scale exposes the limits of secrets management
The article points to cloud, data centre, and future agentic AI workloads as one operational problem: identity sprawl without consistent control. As environments multiply, teams end up with separate authentication patterns for each platform, which fragments governance and makes reuse more likely. Workload identity aims to standardise access semantics across these environments so security does not depend on environment-specific secrets handling. For practitioners, the architectural challenge is not just better vaulting, but a model that keeps authentication consistent while the underlying runtime shifts between clouds, clusters, and on-prem systems.
Practical implication: Standardise workload identity policies across environments before the credential model fragments further.
Threat narrative
Attacker objective: The attacker seeks reusable access to pipelines and downstream services by abusing long-lived machine credentials.
- Entry begins when static credentials are embedded in pipelines, repositories, or environment variables and become available to anyone or anything that can reach the workflow.
- Escalation follows when the same long-lived credential is reused across runs, services, or teams, expanding the potential impact of one compromise.
- Impact occurs when compromised credentials are used to access cloud services or sensitive systems without a runtime identity binding that limits replay and reuse.
Breaches seen in the wild
- 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.
- 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
Workload identity is now the more durable control plane for DevOps access. The article correctly reframes access as an identity problem rather than a secrets problem, because that is where the operational and governance burden actually sits. Static secrets force security teams to manage storage, rotation, and exposure risk after the fact. Practitioners should treat workload identity as the baseline pattern for pipeline authentication, not as an optimisation layered on top of secret sprawl.
Secrets management becomes a secondary control once access is bound to runtime identity. The governance mistake is to assume the main question is where to store credentials, when the harder question is whether credentials should exist at all in the workflow. Short-lived tokens tied to verified workload identity reduce the persistence of compromise and narrow the trust window. The implication is that identity lifecycle design matters more than credential vaulting alone.
Static pipeline credentials create identity blast radius. Once one token or key is reused across multiple jobs or services, the compromise model shifts from single-workflow exposure to cross-system propagation. That is why the article’s emphasis on ephemeral credentials is directionally correct, even if the real issue is broader than DevOps tooling. Practitioners need governance that assumes machine identities will scale faster than human review cycles.
Pipeline authentication should be measured by invisibility, not by rotation activity. If developers still think about credential handling, the identity model has not been abstracted far enough. The operational goal is not simply fewer secrets, but fewer occasions where a developer must touch access material at all. For IAM and NHI teams, that changes success metrics from rotation cadence to the extent that access is issued automatically, contextually, and auditable at runtime.
Workload identity governance has to stretch across cloud, data centre, and agentic workloads. The article’s forward-looking point matters because the same access pattern will be reused for microservices, on-prem systems, and AI-adjacent workloads. That means identity programmes that stay focused only on vault hygiene will miss the larger lifecycle problem. The practitioner conclusion is to govern machine access as an estate, not as a set of disconnected credential exceptions.
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.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Secret sprawl is a governance symptom, not the root problem. The operational question for practitioners is whether access is still being handled as a credential storage issue instead of a runtime identity issue. When that happens, teams accumulate rotation debt, review debt, and exception debt at the same time, which is exactly why pipeline authentication becomes brittle at scale.
Workload identity changes the unit of control from credential to execution event. That matters because machine access is increasingly shared across cloud services, data centre platforms, and emerging AI workloads. If identity programmes keep centring on vaults alone, they will miss the larger control boundary where permissions should be issued and revoked.
Ephemeral pipeline access is the more realistic NHI governance baseline. Static secrets can still exist in the estate, but they should no longer define the operating model for modern DevOps. The practical shift is to make credential handling invisible to developers while keeping issuance, scope, and revocation auditable at runtime.
For practitioners
- Replace embedded pipeline secrets Move high-frequency build and deploy workflows to workload identity so each run receives ephemeral credentials instead of stored access keys or client secrets.
- Map every pipeline credential location Inventory where access keys, client secrets, and tokens live across CI systems, repositories, and variables, then remove any that are not essential to runtime execution.
- Standardise identity for multi-environment access Use one policy model for cloud, data centre, and platform-specific workloads so teams do not rebuild authentication separately for each service boundary.
- Measure whether developers still handle access Track how often engineers create, copy, rotate, or troubleshoot credentials. If the answer is still frequent, the identity model has not fully replaced secrets handling.
Key takeaways
- Static secrets remain a scale problem in DevOps because they create reusable access paths that are hard to govern consistently.
- The evidence in the source points to widespread secrets sprawl and fragmentation, which makes access management brittle even before a breach occurs.
- Workload identity reduces the need for manual credential handling by making access short-lived, policy-driven, and tied to the execution context.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix 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 replacing leaked and embedded pipeline secrets with short-lived identity. |
| NHI-07 — Long-Lived Secrets | Static credentials in DevOps pipelines are the direct long-lived secret pattern this article argues against. | |
| NHI-05 — Overprivileged NHI | Shared or reused pipeline credentials can exceed the scope each workload actually needs. | |
| Recommendation — Remove hard-coded secrets from pipeline workflows and block secret leakage into repos, logs, and CI variables. Replace long-lived pipeline secrets with ephemeral credentials tied to workload identity. Constrain workload permissions to the minimum scope required for each execution context. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article is about managing machine authenticators across their lifecycle in DevOps workflows. |
| Recommendation — Apply authenticator lifecycle controls to issue, rotate, and retire pipeline credentials consistently. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Leaked pipeline credentials enable credential access and reuse across services and environments. |
| Recommendation — Map exposed pipeline secrets to credential access paths and hunt for lateral movement enabled by reuse. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article is fundamentally about cloud identity governance across multiple runtime environments. |
| Recommendation — Use IAM domain controls to standardise workload authentication across cloud and hybrid environments. | ||
Key terms
- 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.
- 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.
- 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.
- Machine-to-Machine Authentication: Machine-to-machine authentication is the process of proving the identity of one system to another before data or commands are exchanged. In practice, it must be paired with authorization, audit logging, and short-lived trust, or the same credential can become a reusable path into production systems.
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 June 25, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org