Runtime access control is an approach to sensitive access in which an authorization system evaluates a request-including the current identity, requested action, target resource and relevant context-against policy when a sensitive action is attempted. The resulting authorization decision is enforced at an appropriate control point.
The central question is whether an identity should be allowed to use its available permissions or privileges for the current request under the conditions that exist now.
Key takeaways
- Available permissions or privileges do not automatically establish current authorization.
- Runtime authorization is the decision mechanism within runtime access control. Enforcement separately applies the resulting decision at an appropriate control point.
- The requested action and target resource are part of the authorization question, not just the identity.
- This approach can support Zero Standing Privilege by making sensitive privilege temporary, scoped and policy-driven when appropriate.
- The same underlying access-control principle can apply to workforce identities, non-human identities and AI agents, while the relevant authorization context differs by workflow.
Runtime access control at a glance
| Dimension | Runtime access control |
|---|---|
| Primary question | Should this identity be allowed to perform this action on this resource under the current conditions? |
| Decision timing | When sensitive access or an action is attempted |
| Typical inputs | Identity, requested action, target resource, policy and relevant authorization context |
| Decision mechanism | Runtime authorization |
| Enforcement | The resulting decision is applied at one or more appropriate enforcement points |
| Possible outcomes | Allow, deny or constrain the request, or require additional approval |
The defining distinction: available permissions or privileges are not current authorization
A standing or pre-granted permission defines what an identity is permitted to do in advance. It does not necessarily mean the identity is authorized to use that permission for every task, resource or set of conditions.
A runtime authorization decision determines whether the identity should be allowed to use its available permissions or privileges for a particular request under the conditions that exist when the request is made. This is why the current action, target resource and relevant context matter even when the identity already has a valid role or entitlement.
Example: production access during an incident
An engineer may belong to a role capable of administering production. During an approved incident, the engineer needs to change one production resource. The current request can be evaluated using the engineer's identity, requested action, target resource, applicable policy and incident context before the action is performed. Depending on policy and architecture, the result can allow, deny or constrain the request, require approval or make temporary authorization available.
Why runtime decisions matter
Modern access paths extend beyond a person signing in to an application. Developers administer production systems, service accounts and workloads act programmatically and AI agents can use tools or other identities to reach sensitive resources. The identity that starts the work may not be the identity that performs the final action.
Permissions granted well before a request often cannot reflect every condition that exists when sensitive access is actually used. A pre-granted entitlement describes permissions or privileges available to the identity. The current authorization question is whether the identity should be allowed to use them for this task, resource, action and context.
The PocketOS incident is a concrete example. A coding agent found an API token with no expiry and no approval gate. It deleted a production database and every backup in nine seconds. The model didn't go rogue, the permissions did. A runtime decision at the moment the destructive action was attempted could have required approval or denied the request outright. The pre-granted token made the deletion possible; the absence of a runtime check made it unstoppable.
The deeper problem analysis belongs to why modern access control requires runtime decisions.
How runtime authorization and enforcement fit
Runtime authorization determines whether a specific identity may perform a specific action on a specific resource under current conditions. The authorization decision can consider identity, delegated permissions or privileges, the requested action, target resource, policy, approvals, task or purpose and other relevant context. Not every implementation uses every input.
Enforcement is separate. An allow, deny or constraint decision-or a requirement for additional approval-matters only when an appropriate control point applies it. The complete lifecycle is covered in how runtime access control works.
Where authorization can be enforced
Access controls can operate at different layers, including credentials, sessions, groups or roles, tools, applications and target-system entitlements. These layers can complement one another, but they do not control the same object.
Native authorization uses the target system's own authorization mechanisms to help enforce an access decision. This is different from controlling only the credential, connection or session used to reach the system.
How this approach supports Zero Standing Privilege
Zero Standing Privilege (ZSP) is an operating model in which sensitive privilege is not persistently assigned and is made available only when policy permits, for the scope and duration required. Runtime decisions can support ZSP because the need for sensitive privilege can be evaluated when the work occurs instead of leaving that privilege assigned in case it might be needed later.
The two concepts are not synonyms. Runtime access control is the broader access-control approach. ZSP describes a desired operating state for sensitive privilege.
How an authorization control plane relates to runtime access control
As authorization spans more identities, policies, resources and enforcement points, an authorization control plane can coordinate identity and policy context, runtime decisions, enforcement and governance across distributed access paths. A control-plane architecture is one way to operationalize the broader model, not the definition of the category itself.
Where runtime access control applies
The model is not limited to one identity type. The authorization context changes across workforce, machine and delegated workflows, but the underlying question remains whether the requested sensitive action should be authorized under the current conditions.
Workforce identities
Developers, administrators and operators may need sensitive access to cloud infrastructure, production systems, data or code. The current task can be evaluated rather than relying only on persistent administrative privilege. See runtime access control for developer access.
Non-human identities
Service accounts, workloads and automation can also hold broad or persistent permissions. Runtime access control for non-human identities applies the same underlying principle while accounting for ownership, machine access paths and programmatic activity.
AI agents and delegated actions
Agent-mediated workflows can add an originator-the human, workload or agent that initiated the task-an acting agent, delegated permissions, tools and downstream resources to the authorization context. A tool-level decision does not necessarily authorize the resulting action on a downstream resource. When another identity or system acts on behalf of a user, the authorization decision may need to consider both the originator and the acting identity, as well as the permissions available to each and any permissions delegated for the task. See how to authorize actions performed on behalf of a user.
How runtime access control relates to IAM, PAM and just-in-time access
This category complements other identity and privileged-access controls, but the terms are not interchangeable.
Identity and access management (IAM) provides identity, authentication and access-management foundations. Runtime decisions use identity and other context to determine whether the current sensitive action should be authorized. See runtime access control vs IAM.
Privileged access management (PAM) can include credential, session and administrative-access controls. The architectural distinction depends on what object is controlled, where authorization is evaluated and where it is enforced. See runtime access control vs PAM.
Just-in-time (JIT) access primarily describes when access becomes available. Runtime access control is the broader approach that can determine whether temporary access should be authorized. See runtime access control vs just-in-time access.
What are the benefits of runtime access control?
- Reduced reliance on standing privilege. Sensitive privilege does not need to remain assigned simply because it may be needed later.
- Task-relevant least privilege. Authorization can reflect the resource, action, duration and context relevant to the current work.
- Use of current context. Policy can consider conditions that were not known when a role or permission was originally assigned.
- Stronger accountability. Authorization evidence can connect the relevant identity and permissions or privileges to the requested action, policy, enforcement point and outcome.
- A consistent underlying model across identity types. Workforce identities, non-human identities and delegated or agentic workflows can use the same runtime principle even when their context and implementation differ.
Technical foundations
Runtime access control builds on established access-control principles. NIST SP 800-162 describes authorization models in which policy evaluates attributes associated with the subject, protected object, requested operation and environmental conditions. The publication also distinguishes the policy decision point that computes an access decision from the policy enforcement point that applies it.
NIST defines least-privilege in terms of limiting system authorizations and resources to what an entity needs to perform its function. Together, these established principles provide technical grounding for contextual authorization, least privilege and the separation of authorization decisions from enforcement. Runtime access control builds on these principles while describing a broader access-control approach centered on evaluating the current request under current policy and context.
How P0 relates to runtime access control
P0 Security uses runtime access control as its primary category. P0 implements the model through the P0 Runtime Access platform™. The platform combines identity discovery, policy evaluation, native enforcement and continuous access governance across supported sensitive systems and workflows for AI agents, users and NHIs, with availability varying by workflow.
Frequently asked questions
Does runtime access control require temporary access?
No. Temporary authorization is one possible implementation pattern, but it is not what makes access control runtime. A current decision can allow, deny or constrain an action or require additional approval.
Does runtime access control require human approval?
No. Human review can be one policy outcome, but decisions can also be made and applied automatically when sufficient identity, action, resource, policy and contextual information is available. Human approval is a policy choice, not the definition of runtime access control.
Is runtime access control the same as authentication?
No. Authentication proves who or what is acting. Authorization determines what it can do. The two controls are related but answer different questions, and authentication alone does not establish authorization for every action.
What information can runtime access control evaluate?
A decision can evaluate the identity making the request, the requested action, target resource, applicable policy and relevant context. Depending on the use case, that context can include delegated permissions or privileges, task or purpose, approval state, ownership and runtime conditions. Not every implementation uses every input.
Summary
Runtime access control evaluates and enforces authorization using the current request and relevant context when a sensitive action is attempted. Its defining distinction is that permissions or privileges available to an identity do not automatically establish authorization for every current request. Runtime authorization supplies the decision mechanism, while enforcement applies the decision at the relevant control point. This approach can support least privilege and Zero Standing Privilege, and the same underlying principle can apply across workforce, non-human and AI-agent or delegated workflows.