Runtime secret delivery is the practice of supplying credentials only when a workflow actually needs them, rather than storing them permanently in a file or environment. Used well, it reduces exposure, but it still depends on strong ownership, logging, and revocation discipline across the full lifecycle.
Expanded Definition
Runtime secret delivery is a delivery model for OWASP Non-Human Identity Top 10 that supplies a secret only at execution time and only to the workload that needs it. In NHI practice, the secret may be fetched from a broker, injected by an orchestrator, or exchanged for a short-lived credential just before use. The point is not simply to hide a value, but to reduce standing exposure by avoiding durable storage in code, images, or environment variables. Definitions vary across vendors on whether ephemeral token minting, sidecar injection, or workload-bound secret brokering all count as runtime delivery, but the shared control objective is the same: narrow the window in which a credential exists and restrict who can reach it. NHI Management Group treats it as part of the broader secret lifecycle, not a substitute for ownership, auditability, or revocation. The most common misapplication is treating any on-demand fetch as safe, which occurs when teams skip access scoping, logging, and post-use revocation.
Examples and Use Cases
Implementing runtime secret delivery rigorously often introduces dependency complexity and failure handling overhead, requiring organisations to weigh reduced secret exposure against added orchestration and availability risk.
- A CI/CD job requests a short-lived deployment token only when it reaches the release step, instead of storing an API key in pipeline variables. This pattern directly addresses the secret sprawl risk described in the Guide to the Secret Sprawl Challenge.
- A Kubernetes workload receives a just-in-time database credential at pod start, then loses access when the pod terminates. This aligns with the dynamic secret model discussed in Ultimate Guide to NHIs — Static vs Dynamic Secrets.
- A GitHub Action pulls a vault-issued secret only during a release workflow, limiting blast radius if the runner is compromised. Incident patterns like the Reviewdog GitHub Action supply chain attack show why delivery timing matters.
- A service-to-service call uses a short-lived bearer token minted from a workload identity exchange rather than a long-lived shared credential. This is common in federated NHI designs.
- A production script obtains an access certificate only for the duration of a backup task, then the certificate is invalidated immediately after use.
The practical question is whether the runtime path is measurable and enforceable, not whether the secret is merely hidden somewhere else. For implementation guidance, teams often pair this model with the OWASP Non-Human Identity Top 10 and NHI governance controls for rotation and revocation.
Why It Matters in NHI Security
Runtime secret delivery matters because NHI compromise usually becomes severe after a secret is copied, cached, or reused beyond its intended window. NHI Management Group research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage. That is why runtime delivery is not just a convenience pattern, but a risk-reduction measure against secret persistence in logs, CI/CD artifacts, and misconfigured vault paths. It also supports Zero Trust thinking by making credentials more ephemeral and more context-bound. The downside is that poor ownership or weak revocation can turn “temporary” secrets into long-lived exposure. In practice, this term becomes urgent after an incident reveals that a pipeline runner, container image, or integration test had broader secret access than anyone expected.
These failures are often visible in supply-chain incidents and automated exfiltration campaigns such as the CI/CD pipeline exploitation case study and the Shai Hulud npm malware campaign. Organisations typically encounter the operational cost of runtime secret delivery only after a leak, a compromise, or a failed audit forces them to prove exactly when a secret was issued, used, and revoked.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret management, rotation, and exposure risks for non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access must constrain which workload can obtain a runtime secret. |
| NIST Zero Trust (SP 800-207) | SC.AA | Zero Trust requires contextual, continuous authorization for credential use. |
Deliver secrets just in time and verify storage, rotation, and revocation controls around NHI-02.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
