Just-in-Time Secret Delivery

Expanded Definition

Just-in-time secret delivery is a control pattern that issues a credential only at the moment a workflow, service account, or AI agent needs it, then narrows the window for reuse. In practice, the secret may be minted on demand, brokered through a vault, or exchanged for a short-lived token that can be revoked or expire quickly. This is different from static secret storage, where the credential exists persistently and can be harvested long before use. In NHI programs, the term sits alongside dynamic secret, ephemeral access, and zero standing privilege, but definitions vary across vendors on whether a cached token, a leased secret, or a one-time secret exchange all qualify. NHI Management Group treats the important characteristic as task-scoped exposure, not the specific delivery mechanism. The model aligns closely with the OWASP Non-Human Identity Top 10 guidance on reducing secret risk through tighter lifecycle controls.

The most common misapplication is treating a long-lived credential wrapped in a temporary wrapper as just-in-time delivery, which occurs when the underlying secret remains reusable after the task completes.

Examples and Use Cases

Implementing just-in-time secret delivery rigorously often introduces orchestration overhead, requiring organisations to weigh stronger containment against added dependency on vaults, brokers, and policy engines.

• A CI/CD job requests a short-lived database credential only after the build passes policy checks, then loses access when the pipeline ends. This pattern is frequently discussed in the CI/CD pipeline exploitation case study.
• An AI agent receives a time-bound API key for a single tool call, with scope limited to one repository and one action. That reduces the blast radius if the agent is redirected or prompt-injected.
• A production job obtains a lease-based cloud secret from a vault just before connecting to an internal database, rather than reading a standing secret from config or code. The Guide to the Secret Sprawl Challenge shows why this matters when secrets are otherwise copied across systems.
• A privileged maintenance script is allowed to retrieve a one-time certificate only after an approval step, then the certificate expires before reuse becomes possible.
• A third-party integration obtains a short-lived token through federation rather than being handed a reusable credential that can persist beyond the business transaction.

Patterns like this are commonly paired with the OWASP Non-Human Identity Top 10 recommendations for reducing standing exposure and with vault-driven issuance workflows.

Why It Matters in NHI Security

Just-in-time secret delivery matters because NHI compromise is often a speed problem as much as an access problem. NHI Management Group reports that 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage, which shows how quickly exposed credentials can turn into operational loss. When a secret exists only for a narrow task window, attackers have less time to extract, replay, or lateral-move with it. This also supports zero standing privilege by ensuring that access is granted only when the workload has a legitimate need. The operational value becomes clearer in incidents where secrets are discovered in code, CI/CD tooling, or pipeline logs, because those exposures are easier to exploit when credentials remain valid for long periods. The Ultimate Guide to NHIs and the 52 NHI Breaches Analysis both reinforce that visibility and revocation discipline are as important as issuance controls. Organisations typically encounter the need for just-in-time secret delivery only after a secret leak, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Hardcoded Secret
• What is the difference between secret rotation and just-in-time access?
• Who should own onboarding secret delivery and lifecycle control?
• Single-Use Secret Delivery