A control pattern where credentials are fetched only when needed and delivered directly into a controlled execution context. The broker becomes part of the trust boundary, so authorization, logging, and cleanup must all be enforced at request time.
Expanded Definition
Runtime secret brokering is a dynamic delivery pattern in which an application, workload, or agent receives a credential only at the moment it needs to act, rather than carrying a persistent secret in memory, files, or environment variables. In NHI operations, this changes the trust model because the broker is no longer a passive storage layer; it is a control point that must authenticate the requester, authorize the request, issue the secret into a bounded execution context, and ensure cleanup after use.
Definitions vary across vendors on whether a broker includes just-in-time issuance, temporary wrapping, workload identity exchange, or secretless proxying. NHI Management Group treats the term as an operational pattern, not a product category, and the distinction matters because some systems only mask retrieval while others actually reduce secret residency. The closest standards-adjacent reference point is the OWASP Non-Human Identity Top 10, which emphasizes controlling how machine credentials are issued, stored, and used.
The most common misapplication is treating a vault lookup as runtime brokering when the credential is still cached broadly or written to logs, which occurs when request-time controls are not enforced at the execution boundary.
Examples and Use Cases
Implementing runtime secret brokering rigorously often introduces latency and orchestration overhead, requiring organisations to weigh tighter secret exposure windows against added complexity in deployment and debugging.
- A CI/CD job requests a short-lived cloud API key only after pipeline approval, then discards it at job completion. This reduces exposure compared with static secrets stored in build variables, a pattern discussed in the Guide to the Secret Sprawl Challenge.
- An AI agent uses a broker to obtain a database token for a single task invocation, with policy checks tied to the tool call and workload identity.
- A Kubernetes workload fetches a certificate from a broker at startup and renews it only through authenticated workload identity, instead of embedding a long-lived key.
- A developer platform issues a wrapped secret to an ephemeral runner and unwraps it only inside that runner’s isolated context, limiting reuse if the job image is compromised.
- A supply chain response team revokes brokered credentials after detecting malicious code execution, as seen in incidents such as the Reviewdog GitHub Action supply chain attack.
At the design level, runtime brokering is most effective when paired with workload identity rather than shared service accounts, because the broker can then evaluate each request against a distinct machine principal.
Why It Matters in NHI Security
Runtime secret brokering matters because most real-world NHI compromise begins with credentials that were easy to reuse, copy, or exfiltrate. NHI Management Group reports that 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, which is exactly the kind of exposure this pattern is meant to reduce. If a broker is designed poorly, it can centralise risk instead of shrinking it: overbroad issuance, weak request authentication, missing audit trails, or delayed revocation can turn a control into a single point of failure.
For NHI governance, runtime brokering supports least privilege, shorter secret lifetime, and better traceability across agentic systems, but only if the broker itself is treated as a high-value security component. That means logging every issuance event, verifying request context, preventing secret persistence, and ensuring cleanup in crash paths as well as normal exits. The model also aligns with zero trust thinking because trust is evaluated per request rather than assumed for the lifetime of a process.
Organisations typically encounter the operational need for runtime secret brokering only after a secrets leak, compromised pipeline, or agent misuse exposes how many credentials were static all along, at which point the pattern 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 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 improper secret storage and exposure patterns that runtime brokering is meant to reduce. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control aligns with per-request credential issuance and constrained use. |
| NIST Zero Trust (SP 800-207) | SC-32 | Zero trust requires continuous verification, which fits runtime issuance and short-lived trust windows. |
Issue secrets only at request time and prevent persistence outside the controlled execution boundary.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
