Runtime access control works by evaluating a sensitive request when it is attempted, using the current identity, requested action, target resource, policy and relevant context. Runtime authorization produces the decision, and an appropriate enforcement point applies it. Sensitive access can be limited to the scope the policy permits, and temporary permissions or privileges can later expire or be revoked. Evidence preserves the authorization path and outcome.
Key takeaways
- The current request is part of the authorization decision, not just permissions assigned in advance.
- Runtime authorization is the decision mechanism. Enforcement separately applies the resulting decision.
- The target resource and requested action matter because the same identity may be authorized for one action and denied another.
- Access can be constrained to the permissions, resources and duration appropriate to the task.
- Temporary permissions or privileges can expire or be revoked when the approved need ends or policy no longer permits them.
- Evidence should connect the request, decision, enforcement and outcome.
Runtime access control at a glance
| Stage | What happens |
|---|---|
| 1. Identify the request | Determine who or what is acting, what action is requested and which resource is targeted. |
| 2. Gather relevant context | Use policy inputs such as role or entitlement, delegated permissions, task or purpose, approval state, ownership, time and risk when relevant. |
| 3. Evaluate policy | Runtime authorization determines whether the current request should be allowed, denied or constrained, whether approval is required or whether access should change. |
| 4. Enforce the decision | Apply the authorization result at a control point capable of governing the intended access or action. |
| 5. Keep access scoped | Limit sensitive access to the permissions, resources and duration appropriate to the approved task. |
| 6. Expire or revoke access | Remove temporary permissions or privileges when the approved period ends or policy no longer permits them. |
| 7. Preserve evidence | Record enough information to explain the request, decision, enforcement and outcome. |
1. Start with the current request
The process begins with a concrete authorization question: who or what is acting, what is being requested and which resource is the target? Authentication can establish the identity, but identity alone does not determine whether the requested action should be allowed.
For example, a developer may be authenticated and may have a production-related role. Runtime access control asks the narrower question of whether that developer should perform this production action on this resource under the current conditions. This separates permissions or privileges that may be available to an identity from authorization to use them for the current request.
2. Add the context that matters to policy
The authorization system can evaluate information beyond identity. Depending on the use case, relevant context can include delegated permissions, role or entitlement, task or purpose, approval state, resource ownership, time and risk. In a delegated workflow, the originating identity and acting identity may also need to remain distinct.
Not every decision needs every input. The goal is to use the context required to answer the current authorization question. The complete input taxonomy belongs to what a runtime authorization decision evaluates.
3. Make the runtime authorization decision
Runtime authorization evaluates the current request against policy and relevant context. Depending on the policy model, the result can allow or deny the action, constrain its scope, require approval or direct an enforcement mechanism to grant, modify or revoke access.
This is the decision step. It should remain distinct from enforcement: deciding that an action is allowed or that access should change does not by itself make a target system, application, tool or other enforcement layer apply that decision. NIST’s access-control architecture makes the same architectural distinction between a policy decision point, which computes an access decision, and a policy enforcement point, which enforces the decision.
4. Enforce the decision at the right control point
The authorization decision must be applied at an enforcement point capable of controlling the object the policy is meant to govern. Depending on the workflow, enforcement can occur at a credential, session, group or role, tool, application or target-system entitlement layer. Different layers control different things, so the enforcement point determines what the authorization decision can actually govern.
For sensitive target-system access, native authorization is one approach in which the target system’s own APIs, controls or entitlement model participate directly in enforcement. A temporary credential or controlled session can also be useful, but controlling an access path is not automatically the same as changing the authorization state recognized by the target system.
5. Keep sensitive access scoped to the task
When elevated permissions or privileges are required, access can be limited to the permissions, resources and duration appropriate to the approved task. This applies the scope dimension of least privilege: the identity should receive no more access than the current work requires.
For example, an engineer who needs to change one production resource does not necessarily need broad administrative privileges across the environment. The authorization workflow can constrain what becomes available so that the permitted access matches the approved action more closely.
6. Expire or revoke access when conditions change
Access is not necessarily permanent once granted. Temporary permissions or privileges can expire at the end of an approved period, and active access can be revoked when policy no longer permits it. The exact mechanism depends on the enforcement layer and architecture.
This time dimension can support Zero Standing Privilege by making sensitive privilege available when policy permits and removing it when the approved need ends. Expiration and revocation are therefore distinct from the initial authorization decision: they govern what happens to authorization state after access has been granted.
7. Preserve evidence of the authorization path
Useful evidence connects the identity, requested action, target resource, policy decision, enforcement point and outcome. In delegated workflows, evidence can also preserve the originator and acting identity separately so the identities and permissions behind an action are not lost when another identity performs it.
This makes it possible to explain not just that access occurred, but what was requested, why the request was permitted or denied, where the decision was applied and what happened afterward. Evidence supports accountability without becoming a substitute for the authorization control itself.
Example: one production change
A developer needs to modify one production resource during an incident. The developer authenticates through the organization’s identity system. When the sensitive change is requested, runtime authorization evaluates the developer, target resource, requested action, incident context and applicable policy. If the request is authorized, an enforcement mechanism makes only the required permissions or privileges available and applies the decision at the relevant control point. When the approved need ends, the enforcement mechanism removes the temporary access, and the decision and action are preserved as evidence.
The important shift is that the developer’s existing role or entitlement can inform the decision without automatically becoming authorization for every production action.
How decisioning and enforcement fit together
Runtime access control includes both authorization decisioning and enforcement, but they are different functions. The decision evaluates the request against policy. Enforcement applies the result at the point that can actually control the requested access or action. NIST SP 800-162 describes this separation explicitly and notes that decision and enforcement functionality can be centralized, distributed or logically separated.
This distinction matters because an authorization system can make a precise decision yet still fail to control the intended action if the result is enforced at the wrong layer. A tool-level decision, for example, governs use of the tool but does not automatically authorize every downstream resource action.
Frequently asked questions
Does runtime access control require human approval?
No. Human approval is one possible policy outcome, not a requirement of runtime access control. A request can be authorized automatically when policy and the available context are sufficient, denied automatically when it violates policy or routed for review when additional judgment is required. What makes the control runtime is that the current request is evaluated when access or an action is attempted.
Does runtime access control require temporary access?
No. Temporary authorization is a useful access pattern, but it is not the definition of runtime access control. A runtime decision can allow or deny an action, constrain its scope, require approval or direct an enforcement mechanism to grant, modify or revoke access. Temporary access becomes especially useful when sensitive privilege should exist only for a particular task or approved period rather than remain persistently assigned.
Is runtime access control the same as runtime authorization?
No. Runtime authorization is the decision-making mechanism within runtime access control. It evaluates whether a specific action on a specific resource should be permitted under the current policy and context. Runtime access control is broader because it also includes applying that decision at an appropriate enforcement point and managing the authorization state and evidence associated with the request.
Where can a runtime access-control decision be enforced?
A decision can be enforced at the control point appropriate to the policy and requested action. Examples include credential controls, sessions, groups or roles, tools, applications and target-system entitlements. These layers are not interchangeable: a tool decision controls tool invocation, for example, while target-system entitlement enforcement governs authorization recognized by the downstream system itself.
Technical foundations
The decision-and-enforcement model behind runtime access control builds on established access-control architecture. NIST SP 800-162 describes authorization decisions that evaluate subject, object, requested operation and environmental attributes against policy. It also distinguishes the policy decision point that computes an access decision from the policy enforcement point that applies it. This separation helps explain how runtime authorization decisioning and enforcement work together while remaining distinct functions.
- NIST SP 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations
- NIST CSRC Glossary: policy decision point
- NIST CSRC Glossary: policy enforcement point
Summary
Runtime access control makes the current sensitive request part of authorization. It identifies the identity, action and target, gathers relevant context, evaluates policy through runtime authorization, applies the resulting decision at an appropriate enforcement point, keeps sensitive access within the permitted scope, expires or revokes access when necessary and preserves evidence of the authorization path.
The architecture separates decisioning from enforcement while connecting them into one control lifecycle. That makes it possible to use current policy and context to govern what an identity can do now rather than treating permissions or privileges granted in advance as sufficient authorization for every later action.
Explore runtime access control
- What is runtime access control?
- What is runtime authorization?
- What does a runtime authorization decision evaluate?
- What is native authorization?
- How to implement runtime access control