Per-request authorization means every action is checked individually instead of trusting a session once and assuming all later activity is safe. This matters for agents because the request that causes damage may be generated after the initial interaction has already been approved. It is a stronger fit for dynamic, tool-using identities.
Expanded Definition
Per-request authorization is a control pattern in which each action is evaluated at the moment it is invoked, rather than inheriting trust from a previously approved session. In NHI and agentic AI environments, this matters because an agent can remain active, change intent, or receive a new tool instruction long after the original request was validated.
Definitions vary across vendors on where the authorization boundary should sit. Some systems treat the request as the tool call itself, while others apply authorization at the API gateway, policy engine, or workload identity layer. The practical standard is closer to NIST Cybersecurity Framework 2.0 thinking: decision points should be continuous, contextual, and tied to least privilege, not assumed trust.
For NHI governance, per-request authorization is stronger than session-based approval because it can incorporate current context such as workload identity, resource sensitivity, time, destination, and user intent. It is especially relevant for tool-using agents, service accounts, and API-driven automation that can pivot across systems after the first successful check. The most common misapplication is treating a long-lived token or approved session as proof that every later action is safe, which occurs when teams confuse authentication at login with authorization for each downstream action.
Examples and Use Cases
Implementing per-request authorization rigorously often introduces latency and policy complexity, requiring organisations to weigh stronger control over agent actions against the cost of evaluating every call.
- An agent asks to read a CRM record, then later requests to export all customer data. The second request is re-evaluated because its risk profile is materially different.
- A CI/CD service account can deploy to staging but must be denied production deployment unless the current request matches a change window and approved target.
- A workflow bot uses a cached token to open a ticket, then attempts to access a secrets manager. Each request is checked separately, even though the bot identity is unchanged.
- A policy engine validates every model tool call against scope, destination, and data classification, which aligns with the lifecycle and visibility concerns discussed in the Ultimate Guide to NHIs.
- At the protocol layer, per-request checks can be paired with OAuth 2.0 style delegated access so that every token use is constrained by fresh policy rather than broad standing trust.
For organisations building agentic systems, the difference is often visible in how tools are exposed. A narrowly scoped request to query a log can be allowed, while a nearly identical request to mutate records can be blocked unless policy, context, and current risk all line up.
Why It Matters in NHI Security
Per-request authorization matters because most NHI failures are not caused by one dramatic login event, but by accumulated trust. Once an agent or service account is allowed to continue acting without fresh checks, excessive privilege and stale access become easy paths to data exposure, unauthorized changes, and supply chain impact. NHI Mgmt Group reports that Ultimate Guide to NHIs shows 97% of NHIs carry excessive privileges, 71% are not rotated on time, and only 20% have formal offboarding processes, all of which make broad session trust especially dangerous.
This control also fits Zero Trust expectations, where each action should be verified against current context instead of assumed safe because the caller was safe once. For governance teams, the issue is not whether the identity was initially authenticated, but whether the next tool call, API operation, or data access still deserves approval under present conditions. That makes it a core safeguard for agents with execution authority and for any workload that can act autonomously after the first decision point. Organisations typically encounter the need for per-request authorization only after an agent oversteps its intended scope, 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 and OWASP Agentic AI 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 Non-Human Identity Top 10 | NHI-04 | Per-request checks prevent over-privileged NHIs from reusing stale trust across actions. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification instead of relying on a prior session decision. | |
| OWASP Agentic AI Top 10 | A1 | Agentic tool use needs action-by-action control to stop unsafe follow-on requests. |
Authorize every NHI action independently and deny requests that exceed current scope or context.
