Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
Expanded Definition
Runtime authorisation is the control decision made at the moment an NHI, service account, or AI Agent attempts an action, rather than at onboarding alone. It differs from provisioning-time access because the decision can account for current context, such as workload identity, request path, destination system, token freshness, and whether a secret has been rotated. In practice, it sits alongside NIST Cybersecurity Framework 2.0 concepts for access governance, but the term itself is still used inconsistently across vendors and platform teams.
For NHI security, runtime authorisation is most valuable when access must be continuously justified, not simply assigned. That is why it is often discussed with Zero Trust Architecture, JIT, ZSP, and policy engines that evaluate each request before it executes. The practical difference is simple: a token may exist, but the action still gets denied if the current trust signals are weak or the workload is outside expected bounds. The most common misapplication is treating runtime authorisation as a one-time API gateway rule, which occurs when teams enforce static allowlists but do not re-evaluate identity, session risk, or secret state during execution.
Examples and Use Cases
Implementing runtime authorisation rigorously often introduces latency and policy complexity, requiring organisations to weigh tighter control against application performance and operational overhead.
- An AI Agent requests database export permissions only after the policy engine confirms the request is tied to an approved workflow and a fresh workload identity assertion.
- A deployment pipeline can reach a secrets store, but the action is denied at runtime if the secret has been revoked or the request originates outside the expected CI/CD context.
- A service account used for payments receives read access during normal operation, then loses write permission when anomaly detection marks the session as high risk.
- During incident response, a compromised automation account is allowed to authenticate but blocked from lateral movement because runtime policy evaluates destination sensitivity in real time.
These patterns align with how the Ultimate Guide to NHIs frames continuous governance across the NHI lifecycle, and they map well to NIST Cybersecurity Framework 2.0 expectations for access control and monitoring. In mature environments, runtime authorisation is usually applied to machine-to-machine APIs, privileged automation, and agentic tooling where static roles alone are too blunt.
Why It Matters in NHI Security
Runtime authorisation closes the gap between a credential being valid and a task being safe. That matters because NHI risk changes during execution: a secret can leak, a workload can be repurposed, a vendor integration can expand blast radius, or an Agent can be redirected toward a sensitive action. The control becomes especially important where Ultimate Guide to NHIs findings show that 97% of NHIs carry excessive privileges, because excessive standing access makes delayed detection far more damaging.
Runtime decisions also support better alignment with Zero Trust Architecture. Instead of assuming an identity remains trustworthy after login or token issuance, the system keeps checking whether the request is still acceptable. That is a meaningful governance shift for service accounts, secrets, and autonomous software entities because compromise often appears as normal traffic until a downstream action is attempted. The operational benefit is reduced blast radius, but the tradeoff is that policy design, telemetry quality, and exception handling must all be disciplined. Organisations typically encounter the need for runtime authorisation only after a privileged token is abused, 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 Zero Trust (SP 800-207) 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-04 | Runtime decisions reduce damage from overprivileged NHIs and stale access. |
| NIST Zero Trust (SP 800-207) | JIT | Zero Trust requires continuous verification, not trust based on prior authentication. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be managed and enforced with least-privilege controls. |
Re-evaluate identity and request context at execution time before granting privileged access.
Related resources from NHI Mgmt Group
- What is MCP Step-Up Authorisation and how does it implement least privilege for agents?
- What are MCP Authorisation Extensions and why do they matter for enterprise governance?
- What is the difference between runtime protection and NHI lifecycle management?
- What is the difference between code scanning and runtime identity monitoring?
