Per-Call Policy Evaluation

Per-call policy evaluation means checking whether a specific request is allowed at the exact moment it is made. For non-human access, this moves authorisation into the execution path and reduces reliance on durable secrets that can be stolen, reused, or mis-scoped.

Expanded Definition

Per-call policy evaluation is the practice of authorising each request at the moment it is executed, rather than relying on a previously granted, long-lived permission. In NHI and agentic AI environments, this means the decision can incorporate current context such as workload identity, destination, data sensitivity, time, tool scope, and policy changes that occurred after the session began.

This approach is increasingly important where agents, service accounts, and API-driven automations can act repeatedly without human intervention. It aligns well with NIST Cybersecurity Framework 2.0 principles for governance and access control, but usage in the industry is still evolving and no single standard governs the exact evaluation model yet. Some teams implement it as a policy engine in the request path, while others pair it with short-lived tokens, identity claims, and policy decision points. The key distinction is that approval is not assumed to persist after issuance; it must be revalidated for each sensitive action.

The most common misapplication is treating a one-time login or token grant as equivalent to per-call authorisation, which occurs when teams check identity only at session start and ignore changes in scope, posture, or policy.

Examples and Use Cases

Implementing per-call policy evaluation rigorously often introduces latency and policy-engine complexity, requiring organisations to weigh tighter control against the operational cost of evaluating every request.

• A service account calls an internal API for every transaction, and each call is checked against current RBAC, device posture, and data-classification rules.
• An AI agent requests access to a tool, and the policy engine allows only the specific action and resource set requested in that moment.
• A workload can reach a payment service only while its attestation remains valid, with the decision refreshed on every request.
• After a secret is rotated, an old token is rejected immediately because the policy is evaluated at call time, not merely at session creation.

This pattern directly addresses the operational issues highlighted in Top 10 NHI Issues, especially where standing access and secret misuse overlap. It also maps cleanly to request-level access concepts described in NIST Cybersecurity Framework 2.0, where access decisions should be tied to current risk and control state rather than assumption.

Why It Matters in NHI Security

Per-call policy evaluation reduces the blast radius of compromised credentials because the decision is not frozen at issuance. That matters in NHI security, where secrets are frequently stored in weak locations, over-permissioned, or left valid far longer than intended. NHI Management Group research shows that 91.6% of secrets remain valid five days after the targeted organisation is notified, which means an attacker often has a meaningful window to reuse access unless the runtime policy can stop the next call. When combined with lifecycle controls from the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, per-call checks help turn revocation, rotation, and scope reduction into immediate enforcement rather than delayed cleanup.

It also supports auditability and containment when agentic systems act autonomously, because each sensitive action can be attributed to a contemporaneous policy decision. Organisations typically encounter the need for per-call policy evaluation only after a token, key, or agent action has been abused, at which point the concept becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What breaks when session policy is global instead of per application?
• What is the difference between policy evaluation and vector filtering in RAG?
• What should organisations do when policy evaluation becomes too slow?
• Why does data-shape fit matter so much in policy evaluation systems?