Request-time authorisation is the practice of checking policy at the moment an action is attempted rather than only at login or provisioning. For AI agents, this matters because identity context and tool choice can change during a session, so earlier decisions may no longer be valid.
Expanded Definition
Request-time authorisation is the policy decision point that evaluates an action when an AI agent, service account, or application actually attempts it. That makes it different from login-time checks, provisioning-time approval, or coarse role assignment. In NHI and agentic AI environments, the identity context can shift mid-session as tools change, data sensitivity changes, or an agent inherits new tasks, so a prior allow decision may no longer be valid. The idea aligns with Zero Trust thinking in NIST Cybersecurity Framework 2.0, which emphasises continuous risk management rather than once-only trust decisions. Definitions vary across vendors on whether request-time authorisation implies token re-evaluation, policy re-check, or full step-up verification, so implementation details still differ.
The most common misapplication is treating request-time authorisation as a one-time gateway check, which occurs when teams enforce policy only at session start and then assume later tool calls remain equally safe.
Examples and Use Cases
Implementing request-time authorisation rigorously often introduces latency and policy-engine complexity, requiring organisations to weigh tighter control against execution speed and developer friction.
- An AI coding agent asks to open a production secret at runtime; policy re-checks whether the current task, repository, and environment justify that access.
- A support automation agent begins with read-only access, then requests a write action after detecting an incident; the system confirms the new action against current incident scope.
- A service account is permitted to call an internal API only when the request originates from an approved workload and the secret is still in a valid state, reinforcing guidance found in the Ultimate Guide to NHIs.
- An orchestration workflow moves from non-sensitive telemetry to customer records, and the authorisation layer requires a fresh policy decision before the data boundary is crossed.
- A privileged automation job attempts an out-of-band remediation step; request-time checks can enforce just-in-time approval rather than relying on a standing role grant.
In practice, this pattern is most useful where the requested action matters more than the identity label alone, because the same agent can be safe for one tool and unsafe for another. It also fits environments that use NIST Cybersecurity Framework 2.0 to segment access decisions by business impact and operational context.
Why It Matters in NHI Security
Request-time authorisation closes a major gap in environments where non-human identities act faster than human reviewers can intervene. NHI security failures often stem from static privileges that outlive their original purpose. NHI Mgmt Group research shows that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, which means a single stale allow decision can become a broad path to misuse. That is why request-time evaluation is closely related to least privilege, Zero Trust, and secrets governance rather than being a niche access-control feature. It also matters for lifecycle hygiene because secrets and roles drift over time, and policy at issue time is rarely enough to contain that drift. A mature program will connect request-time decisions to visibility, rotation, and offboarding practices described in the Ultimate Guide to NHIs and to the continuous verification mindset in NIST Cybersecurity Framework 2.0.
Organisations typically encounter the consequences only after an agent misuses a tool, a secret is exposed, or a privileged workflow is abused, at which point request-time authorisation 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 Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agent tool calls need fresh authorization before each risky action. |
| OWASP Non-Human Identity Top 10 | NHI-04 | Least privilege for NHIs depends on decisions made at request time. |
| NIST Zero Trust (SP 800-207) | JIT | Zero Trust supports just-in-time authorization instead of standing trust. |
Use continuous verification and just-in-time approvals for sensitive non-human actions.
Related resources from NHI Mgmt Group
- What is Just-in-Time (JIT) access and why is it important for NHI security?
- What is MCP Step-Up Authorisation and how does it implement least privilege for agents?
- What are MCP Authorisation Extensions and why do they matter for enterprise governance?
- When do NHI access reviews create more value than a one-time cleanup?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
