Decision-time evaluation means checking access at the moment a request is made, using current identity, context, and resource state. It is stronger than setup-time assignment because it reflects the live conditions under which the action will actually occur.
Expanded Definition
Decision-time evaluation is the practice of authorising an action only after checking current identity, request context, and resource state at the exact moment the request is made. In NHI and agentic AI environments, that means the system does not rely solely on an earlier approval, provisioning event, or static role mapping. It re-evaluates whether the requester still qualifies right now.
This matters because machine identities often act at high speed and across dynamic infrastructure. A service account may be valid, but the request may originate from an untrusted workload, an unexpected network path, or a resource that has changed state since assignment time. In that sense, decision-time evaluation is a live control plane concept, not just an identity recordkeeping exercise. It aligns closely with NIST Cybersecurity Framework 2.0 principles for continuous access management and with Zero Trust models that assess each request independently.
Definitions vary across vendors when this term is used to describe policy engines, adaptive authentication, runtime authorisation, or zero trust gateways. The common thread is dynamic enforcement at the point of use rather than trust based on setup-time assignment alone. The most common misapplication is treating a one-time provisioning approval as if it were sufficient for every later action, which occurs when teams do not re-check context before each privileged request.
Examples and Use Cases
Implementing decision-time evaluation rigorously often introduces latency and policy complexity, requiring organisations to weigh stronger control against operational friction.
- A CI/CD pipeline requests access to a production secret, but the policy engine denies it because the workload is running outside the approved deployment window.
- An AI agent tries to invoke a tool with elevated permissions, and the system checks the live task scope before allowing the action.
- A service account is technically active, yet a request is blocked because the source workload no longer matches the expected attested environment.
- A temporary integration token is still unexpired, but the resource has been quarantined, so the request is denied at evaluation time.
- An NHI governance team compares runtime policy enforcement with the lifecycle guidance in Ultimate Guide to NHIs and applies the same principle to secret rotation and offboarding.
In practical deployments, decision-time evaluation is often paired with NIST Cybersecurity Framework 2.0 aligned access decisions, where current telemetry influences whether the request proceeds. The same pattern appears in workload federation, service-to-service access, and agent tool invocation, especially when the request context changes faster than the entitlement catalogue.
Why It Matters in NHI Security
For NHI security, the key value of decision-time evaluation is preventing stale trust from becoming a standing privilege path. This is especially important when secrets, tokens, and service accounts are reused across automation, because setup-time assignment can survive long after the original assumptions have changed. NHI Mgmt Group reports that Ultimate Guide to NHIs shows 97% of NHIs carry excessive privileges and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
That combination creates a dangerous pattern: the identity may be legitimate, yet the request is no longer safe. Decision-time evaluation helps reduce blast radius by forcing current-state checks before access is granted, which is essential when responding to lateral movement, token replay, workload compromise, or agent misuse. It also supports more defensible audit trails because each approval or denial reflects a concrete runtime condition, not just a historical assignment.
Organisations typically encounter the need for decision-time evaluation only after a token is abused, a workload is hijacked, or a dormant privilege is discovered in an incident review, at which point the concept 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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be enforced continuously at request time, not only at assignment. |
| NIST Zero Trust (SP 800-207) | JIT | Zero Trust requires dynamic, per-request access decisions based on current trust signals. |
| OWASP Non-Human Identity Top 10 | NHI-06 | Runtime authorization is central to preventing excessive or stale NHI privilege use. |
Re-evaluate each NHI request against current context and deny when live conditions fail policy.
Related resources from NHI Mgmt Group
- What is Just-in-Time (JIT) access and why is it important for NHI security?
- What is the core decision loop Agentic AI follows and why does it create security risk?
- When do NHI access reviews create more value than a one-time cleanup?
- When does just-in-time access reduce risk for agentic AI, and when does it fall short?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org