They should move the access decision to runtime and bind it to workload identity, so the credential is issued only when a verified workload needs it. That reduces exposure from copies in code, pipelines, and config files. Rotation still matters for legacy systems, but the stronger control is removing the static secret from the workflow entirely.
Why This Matters for Security Teams
Static secrets fail because they turn access into a reusable artifact instead of a real-time decision. Once a token, API key, or certificate is copied into code, CI/CD, chat, or a config file, the leak becomes a persistence problem, not just a disclosure event. NHIMG research shows how widespread this has become: in the The 2024 State of Secrets Management Survey, 88% of security professionals said they are concerned about secrets sprawl, and only 44% reported using a dedicated secrets management system.
That matters because the access path is often broader than the workload itself. A secret that works everywhere is a standing privilege, even if the original use case was narrow. Current guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s Guide to the Secret Sprawl Challenge both point to the same operational pattern: stop treating secrets as durable assets and start treating them as short-lived proof tied to workload identity.
In practice, many security teams discover the weakness only after a leaked secret has already been reused across pipelines, chat tools, and production systems, rather than through intentional control design.
How It Works in Practice
The practical shift is from static secret distribution to runtime credential issuance. A workload proves who it is using workload identity, then receives a short-lived credential only when policy says the request is valid. That credential should be scoped to the task, time-boxed, and revoked automatically when the task ends. This is the model behind JIT access and modern zero standing privilege design.
For agents, services, and CI/CD runners, that usually means a chain like: authenticate workload identity, evaluate policy at request time, issue an ephemeral token, call the target service, then expire or revoke. The strongest implementations pair cryptographic workload identity with policy-as-code so authorisation depends on context, not just a preassigned role. For identity primitives, SPIFFE and SPIRE are common implementation references, while Anthropic — first AI-orchestrated cyber espionage campaign report is a useful reminder that autonomous systems can chain tools quickly once they get a foothold.
- Issue credentials only after verifying the workload identity, not before deployment.
- Scope each credential to one service, one action class, or one short execution window.
- Use automated revocation and rotation for any legacy static secret still in use.
- Store secrets outside source control, chat, and pipeline variables wherever possible.
NHIMG’s research on Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack shows why this is urgent: CI/CD and developer tooling are now routine secret-exposure paths, not edge cases.
These controls tend to break down in legacy environments that cannot validate workload identity or where one shared secret still powers multiple services and batch jobs.
Common Variations and Edge Cases
Tighter runtime controls often increase implementation overhead, so organisations have to balance security gain against migration complexity. There is no universal standard for this yet, especially when a service is deeply embedded in a monolith, a mainframe adapter, or a vendor integration that cannot consume short-lived tokens.
In those cases, best practice is evolving toward a staged approach: isolate the legacy secret, wrap it with the narrowest possible broker, and reduce its lifetime while the service is refactored. That is still better than leaving a long-lived secret embedded in code or a pipeline variable. The Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful for deciding when a secret can be replaced outright versus temporarily contained.
Another edge case is high-frequency automation, where an agent or service may request credentials repeatedly in a short span. In that scenario, the policy must be precise enough to avoid excessive friction but strict enough to stop privilege creep. This is where intent-based authorisation and real-time evaluation matter more than broad RBAC assignments. NHIMG’s broader breach analysis in the 52 NHI Breaches Analysis shows the same pattern across incidents: once standing access exists, leakage becomes reuse.
Current guidance suggests treating leaked static secrets as a migration signal, not a cleanup task. If the workload cannot survive without a reusable secret, that dependency itself needs to be redesigned.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses secret rotation and lifecycle control for non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Supports least-privilege access decisions for workloads at runtime. |
| NIST AI RMF | Relevant where autonomous agents request credentials and act on their own. |
Replace reusable secrets with short-lived NHI credentials and automate revocation where static access remains.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
