Just-in-time runtime authorisation

Expanded Definition

Just-in-time runtime authorisation is the decision point where a privileged request is allowed or denied at execution time, based on live identity signals, task context, and policy. In NHI security, it is used to stop access from becoming a standing entitlement and instead require a fresh check for each sensitive action.

This pattern is closely related to Zero Trust thinking, but it is more specific than a general access model. Zero Trust Architecture treats trust as continuously evaluated, while just-in-time runtime authorisation focuses on the exact moment an agent, service account, or automation tool asks to perform a high-risk operation. That distinction matters because the request may be legitimate in one workflow and dangerous in another. Guidance varies across vendors on how much context should be included, but the practical goal is consistent: verify the current task, current actor, and current conditions before granting execution authority. The NIST Cybersecurity Framework 2.0 reinforces this emphasis on adaptive protection and access governance.

The most common misapplication is treating a previous approval as enough to justify later privileged execution, which occurs when teams confuse workflow approval with runtime enforcement.

Examples and Use Cases

Implementing just-in-time runtime authorisation rigorously often introduces latency and policy complexity, requiring organisations to weigh tighter control against the operational cost of more frequent checks.

• A deployment pipeline requests temporary permission to rotate production secrets only during a scheduled change window, then loses access immediately after completion.
• An AI agent is allowed to query a payment system only after policy confirms the prompt, task, and destination system match the approved use case.
• A service account can launch a backup job, but it must receive runtime approval before accessing encrypted storage keys or admin APIs.
• A break-glass workflow grants elevated access for incident response, with the decision logged and revoked as soon as the incident is closed.
• Teams using the Guide to NHI Rotation Challenges often pair short-lived credentials with runtime checks so compromise windows stay narrow.

In mature environments, the runtime decision is informed by device posture, workload identity, change ticket status, and whether the requested action matches the expected job function. For baseline access principles, the NIST Cybersecurity Framework 2.0 provides a useful governance anchor, even though it does not define this term directly.

Why It Matters in NHI Security

Just-in-time runtime authorisation matters because privileged NHI activity is often the fastest path from a small mistake to a broad compromise. When service accounts, API keys, or agents can act without a fresh control check, attackers can reuse that authority long after the original need has passed. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes runtime enforcement a practical containment layer rather than a theoretical improvement.

This control also reduces blast radius in environments where secrets are widely distributed and difficult to revoke quickly. The Ultimate Guide to NHI notes that only 5.7% of organisations have full visibility into their service accounts, while 96% store secrets outside secrets managers in vulnerable locations. Those conditions make standing privilege especially dangerous, because lost visibility means lost control. Runtime authorisation forces a decision at the point of use, when context is still available and abuse can still be blocked.

Organisations typically encounter the need for just-in-time runtime authorisation only after a service account is abused, at which point access timing becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How do agent-native payments change the decision between API keys and runtime authorisation?
• Why do containers create more risk at runtime than at build time?
• How should organisations combine admin time authorization with runtime policy?
• Runtime Authorisation