A procurement agent is asked to renew a vendor contract. It is a competent agent with a narrow job, and the renewal needs a payment, so it does what agent frameworks now make trivial: it hands the payment step to a payments agent.
That handoff is one line of code. It is also the moment your authorization model quietly stops describing reality.
The procurement agent was scoped to procurement. It could read vendor records and draft contracts. It was never granted the authority to move money. The payments agent was granted that authority — for payments initiated by the treasury workflow, under a limit, in a specific environment. Neither agent is compromised. Neither is behaving badly. But the task that arrives at the payments agent carries no trace of the fact that it originated somewhere with less authority than the agent now executing it.
Ask the obvious question afterwards — who authorized this payment? — and every answer you get is locally true and collectively useless. The payments agent was authorized to make payments. The procurement agent was authorized to renew contracts. The user was authorized to ask for a renewal. Nobody was authorized to turn a contract renewal into a wire transfer, and no component in that chain was in a position to notice.
When one agent hands work to another, does the second agent inherit the first agent’s authority, its own, or the intersection of the two? Most systems have never answered this — and the default answer, in practice, is the union.
Why this became urgent in about eighteen months
Single-agent deployments hid this problem. One agent, one identity, one set of permissions: authorization at the edge was a reasonable approximation of authorization overall.
Multi-agent systems removed that approximation. Google announced the Agent2Agent (A2A) protocol at Cloud Next in April 2025 and donated it to the Linux Foundation that June, alongside AWS, Cisco, Microsoft, Salesforce, SAP and ServiceNow. By April 2026 more than 150 organizations were behind it, and A2A had been integrated natively into Azure AI Foundry, Amazon Bedrock AgentCore and Google Cloud. Model Context Protocol did the same thing for tools that A2A did for agents: it standardized the wire format for delegation.
Standardizing the handoff is genuinely useful. It also means an agent in one team's stack can now hand work to an agent in another team's stack, across a framework boundary, without anyone writing integration code that might have prompted someone to ask what happens to permissions.
The security community caught up quickly. The OWASP Top 10 for Agentic Applications lists ASI03: Identity & Privilege Abuse — agents misusing credentials, tokens or inherited permissions to reach beyond intended limits — and ASI07: Insecure Inter-Agent Communication, covering agent-to-agent messages that are spoofed, replayed or unauthenticated. Those are two views of one structural fact: in a multi-agent system, the handoff is a privilege boundary, and almost nothing treats it as one.
Three things that go wrong at the handoff
These are not exotic. They are the ordinary consequences of delegation without a resolver.
1. Privilege amplification
An agent grants a sub-agent something it did not itself hold. Sometimes this is sloppy configuration — a delegation template copied from a more privileged workflow. Sometimes it is emergent: an agent reasons that the task needs database write access, and the platform it is running on is happy to provision a sub-agent with it. The delegating agent becomes a privilege laundering step. Authority appears in the child that has no ancestor.
2. Grants that outlive their basis
A delegation is issued under a parent authority that later expires, is revoked, or is reorganized away. The child grant does not know it was standing on something. It keeps working. This is the multi-agent version of the orphaned-credential problem, and it is worse, because a delegation edge is usually created programmatically and nobody has it on an offboarding checklist.
3. Cycles and unbounded depth
Agent A delegates to B, which delegates to C, which — under a slightly different task framing — delegates back to A. Each hop is individually reasonable. The chain has no root. In a system that resolves authority by walking parents, that walk does not terminate. In a system that does not walk parents at all, the cycle is invisible and the effective authority is whatever the last hop asserted.
Each one is a case of authority being asserted at a hop rather than derived from a chain. If the only thing a receiving agent can check is the message in front of it, then every hop is a fresh, unanchored claim.
Authority is a graph, and effective authority is an intersection
The architectural fix is to stop treating delegation as message-passing and start treating it as a graph with a root.
Model each grant as an edge: a delegator, a delegate, a parent edge, a validity window, and the scopes being conveyed — tools, actions, resources, destinations, environments, data classifications, geographies, and any monetary limit. An edge with no parent is a root grant, and a root grant is where organizational authority actually enters the system. Every other edge must trace back to one.
Then define an agent's effective authority as the strict intersection along the path from the root down to that agent — not the union, not the last hop, and never the assertion in the incoming message.
This is the model implemented in EVE's delegation resolver (core/agent_authority/delegation.py). It walks from the agent up to a root, then folds the chain back down, narrowing at each edge. Two rules make the fold safe:
An empty scope list means inherit. An edge that says nothing about, say, allowed destinations is not silently granting all destinations; it is declining to narrow what it received.
A non-empty scope list must be a subset of what the parent already had. If a child edge grants something its delegator lacks, that is not a narrowing — it is amplification, and the resolution fails. This is the rule that makes privilege laundering structurally impossible rather than merely discouraged: an agent can never delegate authority it does not itself hold.
Money folds the same way, in one direction only. A child edge may reduce a financial limit; it can never raise one. The effective limit is the minimum along the path, so a $2M treasury root grant narrowed to $50k at a workflow edge cannot be widened back to $2M by anything downstream.
What a resolver rejects, and why each one matters
Resolution is deterministic and fails closed — an unresolvable chain is not a warning, it is a denial with a reason code. Those codes are the part auditors and incident responders actually use, because each one names a specific organizational failure rather than a generic “access denied.”
| Reason | What it means about the delegation |
|---|---|
SCOPE_EXCEEDED | A child edge granted authority its delegator did not hold — privilege amplification |
DELEGATION_CYCLE | The chain loops; there is no root, so there is no organizational grant behind it |
DELEGATION_DEPTH_EXCEEDED | The chain is longer than the configured maximum hops |
DELEGATION_EXPIRED | An edge on the path is outside its validity window |
DELEGATION_REVOKED | An edge on the path was revoked |
AUTHORITY_CHAIN_INVALID | An orphaned edge, or a chain that never reaches a root grant |
CROSS_TENANT_AGENT | An edge crosses a tenant boundary; tenant graphs are never mixed |
The depth bound deserves a note, because it looks arbitrary and is not. EVE caps delegation at eight hops. A bound is required to guarantee termination on a hostile graph, but the practical argument is stronger than the theoretical one: a chain nine agents deep is not a delegation structure anyone designed. It is a structure something grew. The bound converts an unreviewable topology into a denial someone has to look at.
What actually changes at the handoff
| At the moment Agent A hands work to Agent B | Message-passing | Resolved chain |
|---|---|---|
| Authority the receiver acts under | Its own, or the message’s claim | Intersection from root to B |
| Grant exceeding the delegator’s scope | Accepted | Rejected before execution |
| Parent grant revoked mid-chain | Child keeps working | Whole path fails closed |
| Answer to “who authorized this?” | The last hop | The full path, root to leaf |
| Reconstructable months later | Only from logs, if they exist | From the recorded path and its version digest |
That last row is the one that decides audits. A resolver that returns only allow or deny has answered the runtime question and lost the forensic one. EVE's resolver returns the authority path — the ordered edge identifiers from root to leaf — together with an authority_chain_version, a digest over the content of every edge on that path.
The digest is what makes the decision replayable. Edges change: limits get lowered, windows get extended, delegations get revoked. If a decision record names only the edges, then re-resolving it a year later reconstructs today's graph, not the graph that actually decided. Binding the decision to a digest of the exact edge contents means a later reviewer can tell the difference between “this was authorized” and “this would be authorized now.” Those are different claims, and audits turn on which one you can make.
Operational reality: three things that bite
Fail-closed has a cost, and you should price it before you arm it. A resolver that denies on an unresolvable chain will deny work that used to succeed, because delegation graphs assembled without a resolver contain edges nobody can justify. That is the system working. It is also, on day one, an outage you did not schedule. This is why the sane rollout is a ladder — observe, then shadow, then enforce for a slice, then enforce broadly — and why EVE's agent gateway ships with enforcement off by default behind an explicit mode setting. Shadow mode exists so you can see your real denial rate before it becomes your real denial rate.
Delegation edges are declared, not discovered. A resolver reasons over the graph it is given. It does not go looking for agents, and no honest system claims otherwise. If a team stands up a sub-agent outside the registry, the resolver will not catch it — the control that catches it is a chokepoint at execution, where an unregistered agent has no path to a root and therefore no authority. Registration discipline is the precondition, not a nice-to-have.
Revocation is a timing problem, not a state problem. Revoking an edge is easy. Ensuring that a chain resolved a moment before revocation is not still being acted on a moment after is not. Any system that resolves authority once at the start of a long-running multi-agent workflow has a time-of-check-to-time-of-use window, and the longer the workflow, the wider it is. Resolving at the point of execution rather than the point of planning is what closes it.
What to ask your platform team
You do not need to adopt anyone's product to find out whether you have this problem. Four questions will do it, and all four have concrete answers:
Can an agent in our stack grant a sub-agent a permission it does not itself hold? If the honest answer is “probably not, but nothing checks,” you have amplification exposure.
When a delegation is revoked, what happens to the grants issued under it? If they survive, you have orphaned authority.
For a specific action an agent took last quarter, can we produce the full chain of authority behind it? Not the calling agent — the chain, back to the human or committee that holds the grant.
Would that reconstruction reflect the graph as it was then, or as it is now? If the answer is “as it is now,” the reconstruction is not evidence.
Authentication tells you which agent is acting. Authorization at the edge tells you whether that agent may act at all. Neither tells you whether the work it was handed was authorized to become the work it is now doing. In a multi-agent system, that gap is the whole attack surface — and it opens at the handoff, not at the boundary.
Agent-to-agent delegation is not going away; it is becoming the default architecture, with a standard and a foundation behind it. The question is only whether authority travels with the work or gets re-asserted at every hop. If it is re-asserted, then every handoff is an unanchored claim, and the org chart your agents are actually operating under is one nobody wrote down.
EVE governs the handoff itself. An A2A task — create, delegate, message, deliver — is evaluated as a governed action through the same deterministic resolver as any tool call, before the receiving agent acts, with the authority path and its version digest written into the decision record. If you want to see how that applies to your delegation topology, talk to us, or read how the same model handles the single-agent case in AI Agent Authorization Before Execution.