Per-hop authorization is a model where each service or agent in a delegation chain makes its own access decision. The check happens at the point of action, using the current caller, the resource, and the context for that hop. It prevents one edge decision from silently authorizing the entire downstream path.
Expanded Definition
Per-hop authorization means access is decided at each step in a delegation chain rather than being inherited once and reused everywhere. In practice, a service, proxy, workflow engine, or agent evaluates the current caller, the target resource, and the context for that specific hop before allowing the next action.
This matters because delegation often crosses trust boundaries. A token, session, or upstream approval may prove that a caller was valid earlier, but it does not automatically prove that the caller should be allowed to perform every downstream action. Per-hop authorization narrows that gap by forcing each component to check whether the request is still legitimate at the moment it is made.
The boundary is easy to misunderstand. Per-hop authorization is not the same as authentication, and it is not just reusing the same policy everywhere. It is a decision model for chained execution, which is why it becomes especially important in service-to-service calls, brokered APIs, and autonomous agent workflows.
Examples and Use Cases
Per-hop authorization shows up wherever one system acts through another system on a user’s or service’s behalf.
- A microservice receives a request with a valid upstream token, but still checks whether that caller may access the specific record it is about to read or change.
- An API gateway authorizes entry, then the downstream service re-checks scope before executing a sensitive operation that the gateway cannot fully judge.
- An AI agent uses tools in sequence, and each tool call is checked separately so one approved action does not imply unlimited tool access.
- A workflow engine moves through approval stages, with each stage confirming whether the current actor may advance the request at that point in the process.
The main tradeoff is latency and policy complexity. Per-hop checks add control points, but they also reduce the chance that a single broad grant silently authorizes every later step in the chain.
Security Implications
When per-hop authorization is missing, downstream systems may trust a prior decision that is no longer sufficient for the next action. That creates authorization drift: the caller, data, or context may have changed, but the access path continues as if nothing changed. The result is often over-privilege, lateral abuse through service chains, or unintended escalation across internal boundaries.
A common failure mode is treating an upstream token or gateway decision as proof that all later actions are safe. In a chain of services, that can widen blast radius because one overly broad authorization can unlock multiple resources, not just the first one. The symptom is often visible as “everything works” until a sensitive downstream action is reached, where enforcement is either absent or inconsistent.
For NHIMG readers, the practical warning is that delegation chains become harder to audit as they grow. If each hop does not make its own decision, ownership for the final action becomes unclear and security review has fewer places to detect policy drift.
Domain and Governance Relevance
Per-hop authorization is most relevant in distributed systems, identity-aware service architectures, and autonomous execution environments. In those settings, the question is not only whether a caller was once trusted, but whether every subsequent service or agent is still entitled to proceed with the exact next action.
In NHI and agentic AI contexts, that distinction is important because non-human actors often chain tool use, API calls, and delegated credentials. A single upstream approval should not be treated as blanket permission for the entire run, especially when the agent changes context, target, or privilege level mid-execution.
Governance-wise, per-hop authorization supports clearer accountability. It makes it easier to explain which component approved which action, and it reduces the risk that delegated authority quietly expands beyond the original intent.
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, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | Per-hop checks enforce permissions at each delegated access point. |
| Recommendation — Apply PR.AC-4 to re-evaluate authorization at each service or agent hop. | ||
| CIS Controls v8 | 6 — Access Control Management | Delegation chains need scoped access decisions and revocation boundaries. |
| Recommendation — Use CIS Control 6 to restrict downstream actions to current, approved access. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Authorization and Least Privilege | Non-human actors must be re-authorized for each action they perform. |
| Recommendation — Apply NHI-04 to validate each NHI or agent action against current least privilege. | ||
| OWASP Agentic AI Top 10 | A1 — Agentic Access Control | Agent tool use should be checked per action, not inherited from one grant. |
| Recommendation — Enforce A1 so every agent tool call is individually authorized. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Weak downstream checks can let attackers expand effective access through chains. |
| Recommendation — Map chained authorization failures to T1098 and hunt for unauthorized privilege changes. | ||
