The practice of issuing credentials only when a workload or agent actually needs them, then letting them expire or become unusable after the task is complete. This reduces standing access and creates a clearer audit trail than storing long-lived secrets in pipelines or agents.
Expanded Definition
Runtime credential brokering is the control pattern that delivers credentials only at execution time, then removes or invalidates them when the task ends. In NHI programs, this is a practical way to replace static secrets in CI/CD systems, agents, and service workloads with short-lived access that is easier to trace and revoke. It aligns with the direction of the OWASP Non-Human Identity Top 10, where secret exposure and standing privilege are treated as core NHI risks, and it supports the identity assurance logic described in NIST SP 800-63 Digital Identity Guidelines when applied to machine actors.
Definitions vary across vendors on whether brokering means token exchange, just-in-time secret issuance, or workload-to-workload federation, so the term should be read as an operational outcome rather than a single protocol. NHI Management Group treats the control as strongest when the broker is policy-driven, time-bounded, and able to bind access to workload identity, environment, and task scope. The most common misapplication is issuing a long-lived token through a broker but calling it runtime brokering, which occurs when the credential survives beyond the actual execution window.
Examples and Use Cases
Implementing runtime credential brokering rigorously often introduces latency and orchestration complexity, requiring organisations to weigh tighter exposure windows against the cost of integrating identity policy at runtime.
- A CI/CD job requests a short-lived cloud token at job start, then the broker revokes it as soon as the pipeline completes, reducing the blast radius if the runner is compromised. This pattern is discussed in NHIMG’s CI/CD pipeline exploitation case study.
- An AI agent receives narrowly scoped access to a database only while it performs a retrieval task, instead of carrying a reusable API key inside the agent runtime.
- A production workload exchanges its workload identity for a temporary secret through a broker rather than reading a static value from a vault at startup. This approach is consistent with the Ultimate Guide to NHIs — Static vs Dynamic Secrets.
- A Kubernetes pod requests ephemeral access to a signing service only for the duration of a deployment approval, then loses the right to mint new credentials after the window closes.
- Security teams use the broker to centralise issuance logs, making it easier to correlate which agent, workload, or pipeline step consumed which credential and when.
These patterns also help organisations respond to secret exposure narratives documented in the Guide to the Secret Sprawl Challenge, where credential distribution and reuse become the underlying weakness rather than a single system failure.
Why It Matters in NHI Security
Runtime credential brokering matters because attackers routinely target the shortest path to reusable machine access. When a service account, agent, or pipeline can mint credentials only on demand, the value of stolen configuration files, logs, and build artifacts drops sharply. That matters in environments where, according to NHIMG research in The 2024 Non-Human Identity Security Report, 59.8% of organisations see value in dynamic ephemeral credentials, yet 88.5% say non-human IAM still lags human IAM maturity. Runtime brokering helps close that gap by turning access into an event, not a possession.
It also reduces exposure during incidents involving credential theft, such as the attacker behaviour described in LLMjacking: How Attackers Hijack AI Using Compromised NHIs, where exposed credentials can be acted on within minutes. The practical governance benefit is clearer incident scope, faster containment, and less dependence on blanket secret rotation after compromise. Organisations typically encounter the need for runtime credential brokering only after a pipeline leak, agent takeover, or cloud access abuse, at which point the control becomes operationally unavoidable to address.
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 SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Addresses secret sprawl and the need for short-lived non-human credentials. |
| NIST SP 800-63 | Provides digital identity assurance concepts that inform machine credential strength. | |
| NIST CSF 2.0 | PR.AC-1 | Access control governance depends on limiting who or what can receive credentials. |
Replace standing secrets with time-bounded issuance and revoke access immediately after task completion.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
