Per-call authorization is a control model where each action is evaluated at the moment it is requested. Instead of trusting a session or a broad role, the system decides allow or deny using identity, resource details, and runtime context. This reduces standing access risk for agents and workloads.
Expanded Definition
Per-call authorization is the practice of making an access decision for each individual action at the moment it is requested, rather than inheriting trust from a session, token lifetime, or broad role. In NHI environments, this means an agent, workload, or service account must be evaluated against the target resource, the requested operation, and the runtime context every time it acts.
This model is closely related to Zero Trust thinking, but it is more granular than simple request gating because it can incorporate device posture, workload provenance, data sensitivity, and policy conditions that change during execution. Standards-oriented guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports this kind of continuous enforcement through access control, auditability, and least privilege. In practice, definitions vary across vendors, especially where “per-call” is used interchangeably with token exchange, step-up checks, or policy enforcement points, so the control should be understood as decision frequency plus runtime context, not just a technical API pattern.
The most common misapplication is treating a short-lived token as per-call authorization, which occurs when the token is reused across multiple actions without a fresh policy decision.
Examples and Use Cases
Implementing per-call authorization rigorously often introduces latency and policy complexity, requiring organisations to weigh stronger containment against execution overhead and engineering effort.
- An AI agent requests access to a customer record, and the policy engine approves only the read action while denying export or bulk retrieval.
- A deployment pipeline uses a service account that can publish artifacts only when the request originates from an approved build environment and passes integrity checks.
- A secrets retrieval workflow grants a token for one specific vault item and one specific operation, then reevaluates before any subsequent access.
- A privileged automation task is allowed to restart a service during a maintenance window, but the same task is blocked from changing IAM policy outside that context.
These patterns align with the governance concerns described in Ultimate Guide to NHIs, especially where excessive privilege and weak rotation create a standing-access problem. They also fit the broader access control discipline in NIST SP 800-53 Rev 5 Security and Privacy Controls, where each decision should be traceable and policy-driven.
Why It Matters in NHI Security
Per-call authorization matters because NHI compromise often turns on one overbroad credential being used repeatedly without fresh scrutiny. NHIMG research shows that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, which makes session-level trust especially dangerous when agents, API keys, or service accounts can chain actions across systems. Per-call checks reduce the blast radius by forcing the platform to re-evaluate intent, scope, and context before every sensitive operation.
This is especially important for agentic workflows, where a single autonomous process may touch tickets, data stores, cloud APIs, and secrets managers in one chain of execution. If the authorization decision is made only at login or token issuance, compromise can persist long after the original context has changed. Operationally, the control also supports stronger audit trails because every allow or deny can be tied to a specific action rather than a vague session state.
Organisations typically encounter the need for per-call authorization only after an agent abuses a broad token or a service account performs an unexpected high-impact action, 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 CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Per-call checks reduce standing access and enforce action-by-action authorization for NHIs. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be managed to enforce least privilege at the request level. |
| NIST Zero Trust (SP 800-207) | Zero Trust assumes no implicit trust and evaluates access continuously per transaction. | |
| NIST SP 800-63 | AAL2 | Higher assurance requirements support stronger runtime checks before privileged actions. |
| NIST AI RMF | AI risk management calls for context-aware controls over autonomous system actions. |
Continuously assess agent actions against policy, context, and impact before allowing execution.
