The request already passed a check at the front door. It was authenticated, it was authorized, it was routed. So why check it again three hops later when a sub-agent reaches a database. The instinct to trust the edge decision is exactly what turns a delegation chain into a lateral movement path. Here is why.
The edge decision knows what the user asked for. It does not know what the intermediate hops will do with that request. When an agent hands work to a sub-agent, and that sub-agent calls a tool, each of those hops is a new decision that the front door never saw. If the only authorization check happened at the edge, every hop after it is running on trust, and trust is not a control. This article is about the alternative, which is a policy decision at every hop, and why policy-based access control is the model that makes it practical. It builds on our blog on multi-hop delegation for AI agents.
What is per-hop authorization?
Per-hop authorization is the practice of making a fresh access decision at every step in a delegation chain, rather than once at the edge. Each service or agent that receives a delegated request evaluates, against its own policy, whether this caller, acting for this user, may take this specific action on this specific resource. The decision at one hop does not authorize the next. Every transfer of the request is a new question, answered where the action actually happens, with the full context of who is acting for whom. It is defense in depth applied to authorization, every hop its own checkpoint rather than one gate at the edge.
The shift is from a single gate to a series of them. The edge check is not wrong, it just cannot see past the front of the chain.
Why edge-only authorization fails in agent chains
The failure mode here has a name and a shape, and Reiner Mertens of KuppingerCole described it precisely at EIC Berlin 2026. The most common way agents and services pass identity down a chain is to forward the incoming token unchanged, or to swap the user's context for the service's own broad credentials. Either way, the downstream system stops seeing the user and starts seeing the service. His phrase for it was that the service's permissions replaced the user's permissions. The result is a database that returns every record the service can reach rather than the records the user should see, with filtering applied afterward, if at all.
The security consequence is worse than an over-broad query. When user context collapses into a broad service credential, a compromised middle hop can call any downstream service whose policy trusts that credential. There is no cryptographic delegation chain to stop it, so the blast radius of one compromised agent becomes everything the chain can reach. This is the lateral movement risk that per-hop authorization exists to close, and it is why forwarding a bearer token down a chain is treated as an anti-pattern rather than a convenience. The MCP security guidance states: a server must not accept a token that was not issued for it.
What each hop must check
The discipline that makes per-hop authorization work is written into the standards. RFC 8693, OAuth Token Exchange, says that the consumer of a token must only consider the token's top-level claims and the party identified as the current actor. In plain terms, each hop decides based on who is actually calling right now and who they are acting for, not on a chain of assumptions about what earlier hops must have checked. The decision is local and specific.
NIST codified the same idea for service meshes. SP 800-204B describes an authorization framework where mutual authentication happens between every pair of services and attribute-based decisions are made across the mesh, rather than a single perimeter check.
The pattern is not new. What is new is the number of hops an agent chain introduces, and the fact that those hops are created dynamically at runtime rather than wired up in advance.
Why per-hop authorization needs PBAC, not just roles
Making a decision at each hop is necessary but not sufficient. The decision also has to be expressive enough to represent what a delegation actually permits, and that is where role-based access control runs out of room. A role can say an agent is a support agent. It cannot easily say this agent may read this customer's record, but only while acting for a user who owns that record, only for the next ten minutes, and only if the request originated from an approved workflow.
Policy-based access control is built for exactly this. The decision is a policy that evaluates attributes, the acting agent, the user it represents, the resource, and the context, rather than a static role lookup. In a delegation chain, the attributes that matter are precisely the ones that change hop to hop. Who is acting, on whose behalf, over which resource, under what constraints. A policy can read the delegation relationship carried in the token and decide against it. A role cannot, because the role was assigned before any of this was known.
This is also why the decision has to be deterministic. Nathan Harris of Gartner made the point directly at Gartner IAM London 2026, that authorization decisions at runtime must be deterministic and fast, and that this is not a place for a model to improvise. Per-hop PBAC gives you a rule that returns the same answer for the same inputs, every time, at every hop.
Per-hop authorization in a single agent request
A concrete chain makes the difference obvious. A user asks an assistant to reconcile last month's invoices. The assistant delegates the data-gathering to a retrieval sub-agent, which calls a finance tool, which reaches the payments database. Four hops, one original user.
With an edge-only decision, the assistant is authorized once, up front, for the whole task. Everything after that runs on trust. The retrieval sub-agent inherits whatever the assistant could do, the finance tool runs with its own broad service credential, and the database returns whatever that credential can see. If the retrieval sub-agent is compromised, or simply prompted into asking for more than the task needs, nothing downstream stops it, because nothing downstream is deciding.
With per-hop PBAC, each transfer is a question. At the assistant-to-sub-agent hop, the policy checks that the retrieval sub-agent, acting for this user, may read invoices for this user's organization and nothing else. At the sub-agent-to-tool hop, it checks that this specific tool call, with these arguments, is within the reconciliation task. At the tool-to-database hop, it checks that the query is scoped to the user's own records. The same request, four decisions, each made where the action lands and each able to say no. A compromised middle hop gets exactly one hop further and then meets a policy that was not talked into anything.
The point of the example is that the decisions are not redundant. Each hop knows something the previous one could not. The assistant did not know which specific records the tool would touch. The tool did not know the query the database would run. Only the hop where the action happens has the arguments in hand, which is why that is where the decision has to be.
Verify workload identity before per-hop authorization
There is a prerequisite that per-hop authorization depends on and that is easy to skip. You cannot safely carry a user's identity to a service whose own identity you cannot verify. If the next hop could be anything, then the delegation you hand it means nothing. This is what workload identity provides.
SPIFFE, the CNCF standard, gives every workload a cryptographically verifiable identity document that it presents before it is trusted with anything on the user's behalf. Mertens called this a solved problem, and the point of calling it out is that per-hop policy decisions assume it. The policy at each hop can only reason about the acting workload if the acting workload's identity is real.
Does per-hop authorization add latency?
The objection an engineering leader raises first is cost. If every hop makes a policy call, does that not add latency to every request, multiplied by the length of the chain. It would, if the decision were a slow round trip to a distant service. The answer is to make the decision local and deterministic. A stateless policy decision point that runs as a sidecar or a nearby service evaluates a check in sub-millisecond time, so a per-hop decision adds microseconds, not milliseconds, per hop. The heavier work, analyzing access patterns and improving the policies, happens offline. The decision on the request path stays fast, which is what makes checking at every hop affordable rather than aspirational.
How Cerbos fits
Cerbos is an authorization management platform, and the Cerbos PDP component is the policy decision point each hop calls. At every step in a delegation chain, the service or agent asks the Cerbos PDP whether this caller, acting for this user, may take this action on this resource, and gets back a deterministic allow or deny. Policies are written in YAML with CEL for conditions, so a rule can read the delegation relationship carried in the token, the acting workload's identity, the resource, and the context, and decide on the specific hop in front of it rather than on a role assigned months ago.
Because the PDP is stateless and sub-millisecond, putting a decision at every hop does not become a latency tax, and because the same policy model covers every non-human identity in the estate, the agent hops are governed by the same layer as everything else. We go deeper on the audit side in why your audit trail breaks at the sub-agent boundary (coming soon).
Checking once at the edge tells you the request started out allowed. Checking at every hop tells you it stayed allowed the whole way down. In a chain of agents you did not fully design in advance, the second is the only one that holds.
Try Cerbos to enforce per-hop authorization across agent chains, or book a call to talk through your delegation model with the team.
Go deeper:
- Securing AI agents and non-human identities in enterprises (eBook) for the full agent authorization pattern
- Fine-grained authorization for non-human identities (Webinar) for per-hop, attribute-based control
FAQ
Tagged in
