Use monotonic narrowing. Each downstream hop should receive only a subset of the upstream authority, and the resource server should reject any request whose scope grows at a later hop. That keeps the chain auditable and prevents one agent from silently expanding its access by calling another service.
Why monotonic narrowing is the right delegation model
Multi-agent systems become risky when authority is treated like a reusable credential instead of a bounded, purpose-specific capability. The safer pattern is monotonic narrowing, where each hop can only pass on a smaller or equal subset of what it received, never a broader one. That keeps delegation inspectable, limits blast radius, and stops downstream agents from quietly accumulating power through composition.
In practice, the control objective is to make authority shrink as the chain length grows. If a worker agent only needs read access to one dataset and the next agent only needs a single write action, then neither should inherit the full upstream envelope. This is especially important when agents can call tools, other agents, or brokered services in sequence, because delegation failures often appear as ordinary workflow behavior until the scope expands too far.
Monotonic narrowing also creates a cleaner trust model for multi-agent and A2A security, where the question is not just whether an agent is allowed to act, but whether each handoff preserves a tighter, auditable boundary. If a downstream request asks for more than the upstream grant allowed, the resource server should fail closed rather than trying to infer intent or accept convenience-based escalation.
How to enforce shrinking authority across hops
The enforcement point should sit at the resource server or policy decision layer, not in the agent’s own promise to behave. Each request should be evaluated against the current hop’s effective scope, the original delegated scope, and any chain constraints that cap what can be re-delegated. That is how you prevent an agent from using a legitimate starting grant to mint a broader one later.
Authorisation should be expressed as task-scoped, time-bound, and action-specific. A downstream hop should inherit only the minimum authority needed to complete its own step, not the full permissions of the caller. Where the workflow requires on-behalf-of delegation, use explicit token exchange or equivalent delegation semantics so the chain can be traced and each hop’s authority can be compared to the previous hop.
The practical design issue is identity and delegation hygiene, not just policy syntax. Agentic AI identity patterns help teams separate who initiated the task from which agent is executing it, while least-privilege authorisation for AI agents keeps per-action access from drifting into blanket operational power.
What breaks when delegation grows instead of narrows
The main failure mode is privilege amplification across a workflow. One agent begins with a legitimate narrow grant, then passes a broader token, a wider role, or an unconstrained service credential to another component that was never meant to hold it. Once that happens, the chain no longer reflects the original decision, and the system has lost the ability to prove that each hop stayed within policy.
Another failure mode is confused deputy behaviour. A downstream service may accept a request because the caller is trusted, even though the caller is acting on behalf of a less-privileged principal. If the system does not preserve delegation context, the resource server can no longer distinguish original authority from borrowed authority, which makes abuse hard to spot and hard to unwind after the fact.
Chains that are meant to be temporary also become easier to misuse when they are not bounded by expiry, scope, and audience. That is why zero trust for AI agents is a useful companion concept here, because it treats every hop as a fresh authorisation decision instead of assuming earlier trust should automatically continue.
Risk and Threat Considerations
Delegated authority in multi-agent systems creates a real escalation path if the chain can widen at any hop. The danger is not only accidental overreach, but also deliberate abuse, because a compromised or rogue agent can use trusted delegation to reach resources that were never meant to be directly exposed.
Failure mechanism: A downstream agent receives a broader token, a reusable credential, or an unrestricted delegation path, then presents that authority to a later service that fails to compare the new request against the original constrained scope. The chain stops narrowing and starts compounding privilege.
Impact: Attackers can turn one compromised hop into wider access, lateral movement, data exposure, or unauthorized tool use, while defenders lose a clean audit trail for which agent actually had authority at each step.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Multi-agent delegation can expand privilege across hops. |
| Recommendation — Enforce per-hop authorization to prevent delegated authority from widening. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Authority narrowing is a least-privilege control problem in agent chains. |
| AU-12 — Audit Record Generation | Hop-by-hop delegation needs traceable audit evidence for authority changes. | |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Agent-to-agent delegation depends on authenticating non-human actors and their tokens. | |
| Recommendation — Limit each agent hop to the minimum authority needed for its task. Log delegation context at each hop so scope changes remain attributable. Authenticate each non-human hop before honoring delegated authority. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Delegated non-human credentials can become overprivileged as they traverse agents. |
| Recommendation — Prevent downstream agents from inheriting broader credential scope than required. | ||
Practitioner Guidance
What to prioritise: Put the strongest enforcement on the resource server and policy layer, because that is where scope growth can be rejected consistently. If the server cannot prove that a request is still within the upstream grant, it should deny the action rather than trying to “help” the workflow continue.
What to verify: Check that every delegation hop has explicit bounds for audience, duration, and allowed actions, and that the chain cannot be expanded by a later service minting its own broader authority. Also verify that audit logs preserve the hop-by-hop delegation context, not just the final caller identity.
Common mistake: Teams often secure the first token issuance and assume the rest of the chain will stay honest. In a multi-agent system, the real control problem is re-delegation, so the design must treat every hop as a potential privilege change, not just an execution step.
Practitioner takeaway: The goal is not to eliminate delegation, but to make authority strictly shrinkable, inspectable, and rejectable at every hop so no agent can expand its own power in transit.