A decision process that evaluates each individual call before it reaches a tool or data source. It is stronger than blanket network access because it can distinguish between actions, resources and context at the moment the request is made.
Expanded Definition
Request-layer authorisation is the control point where an agent, service, or application is evaluated at the moment it asks for a specific action on a specific resource. It differs from coarse network allowlists because the decision is tied to intent, context, and scope rather than mere connectivity. In NHI environments, this matters because an API key or service account can technically reach a system without being entitled to every method, record, or function exposed by that system.
In practice, request-layer authorisation is closest to policy enforcement at the call boundary, where the system can decide whether a request to read, write, delete, mint a token, or invoke a tool should proceed. Guidance varies across vendors on how fine-grained this should be, but the security goal is consistent: the decision should be made per request, not assumed from prior network trust. The NIST Cybersecurity Framework 2.0 reinforces the broader least-privilege posture that this model supports, while NHI governance guidance in Ultimate Guide to NHIs shows why identities with standing access become risky at scale.
The most common misapplication is treating network reachability or a valid token as proof that every downstream request should be accepted, which occurs when teams confuse authentication with action-specific authorisation.
Examples and Use Cases
Implementing request-layer authorisation rigorously often introduces latency and policy complexity, requiring organisations to weigh tighter control against the operational cost of evaluating every call.
- An API client can authenticate successfully but is denied access when it tries to export records outside its approved tenant boundary.
- An AI agent is permitted to read a ticketing queue but blocked from creating payments, even though both actions use the same service identity.
- A build pipeline may fetch dependencies from one repository, yet request-layer policy prevents it from invoking production-only deployment endpoints.
- A service account can read metadata but cannot retrieve secrets, aligning per-call checks with the principle behind NIST Cybersecurity Framework 2.0.
- NHIMG research shows why this matters: in Ultimate Guide to NHIs, 97% of NHIs carry excessive privileges, so request-layer checks help contain what a credential can actually do.
Why It Matters in NHI Security
Request-layer authorisation is one of the few controls that can still limit damage after an NHI has been compromised, because it evaluates each action instead of trusting the identity indefinitely. That matters in environments where NHIs outnumber human identities by 25x to 50x, as described in Ultimate Guide to NHIs, and where standing permissions are often far broader than operators realise.
When this control is missing, a stolen token or over-permissioned service account can pivot across tools, data stores, and automation paths without interruption. The result is not just unauthorised access but also uncontrolled execution in agentic workflows, where one request can trigger a chain of downstream actions. That is why the broader governance model in the NIST Cybersecurity Framework 2.0 becomes operational only when request-level checks are enforced.
Organisations typically encounter the true value of request-layer authorisation only after a compromised NHI starts invoking actions it was never meant to perform, at which point per-request policy 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Per-request checks limit what an NHI can do even after authentication succeeds. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control depends on evaluating each request against policy. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous, context-aware authorization for each access attempt. |
Enforce action-specific policy at each call boundary before allowing tool or data access.
