Because each hop can change the acting identity. If an MCP server or downstream service uses its own credentials instead of the original user or agent context, accountability becomes fragmented and permissions can broaden unintentionally. The risk is highest when heterogeneous systems cannot preserve the same delegation semantics end to end.
Why delegation chains change the authorisation problem
Delegation is safe only when every hop preserves who is acting, what authority is being exercised, and whether the downstream system is truly operating on behalf of the original requester. Once a service substitutes its own credentials, the chain stops being a simple relay and becomes a new trust decision with new blast radius, new accountability, and a greater chance of privilege creep.
This is why heterogeneous stacks are harder: one system may support explicit on-behalf-of semantics, another may only know service credentials, and a third may accept either without preserving context. The result is often a quiet shift from constrained delegation to broad system-level access.
Where authorisation breaks down in practice
The first failure mode is context loss. If the original actor, request scope, or approval state is not carried end to end, the downstream service cannot enforce the intended policy. That matters for both human and machine flows, because authorisation is about the acting context, not just the transport path.
The second failure mode is identity substitution. A hop may authenticate with its own token or secret and then act with its own standing permissions, which can exceed the permissions the upstream actor should have had. This is the point where delegation becomes impersonation in effect, even if no one intended it.
The third failure mode is inconsistent policy interpretation. One system may treat a token as delegated authority, while another treats it as direct service access. When those semantics do not match, the chain can over-authorise actions, weaken separation of duties, and make audit trails hard to reconstruct.
What good delegation controls need to preserve
Good delegation design keeps the chain intelligible to both policy and audit. That means preserving the original subject, constraining the downstream action to the minimum necessary scope, and making it clear whether the action is performed directly, delegated, or impersonated. For agent and service flows, this usually requires explicit token exchange, short-lived credentials, and per-action checks rather than a single broad session token. AI Agent Authorisation Guide is useful here because it focuses on task-scoped access and per-action decisions for agents.
It also helps to design the chain around the policy model, not around convenience. If the downstream system cannot express the same delegation semantics, the safer choice is often to narrow the operation, insert an approval gate, or break the flow into smaller steps that can each be authorised cleanly. Authorisation Models Guide is relevant because this is fundamentally a policy-expression problem, not just a transport problem.
For multi-hop agent paths, the chain should also be observable. If you cannot attribute which hop used which authority at the moment of action, you do not really have delegation, you have opaque shared access. Multi-Agent and A2A Security Guide covers multi-hop delegation and containment, which is the exact operational pattern that creates these failures.
Risk and Threat Considerations
Delegation chains create authorisation risk because they multiply trust boundaries. Every extra hop increases the chance that a compromised agent, misconfigured service, or overly broad intermediary credential can turn a narrow request into a wider action than the original actor should have been able to perform.
Failure mechanism: A downstream component authenticates with its own standing privilege or loses the original delegation context, so the policy engine authorises the wrong subject or grants broader access than intended.
Impact: You get fragmented accountability, privilege expansion, and lateral movement potential through trusted internal pathways that were supposed to remain constrained.
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, OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Delegation chains can shift or overextend agent authority across hops. |
| Recommendation — Enforce per-hop authority checks and limit delegated agent privilege to the minimum needed. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Delegated service hops often fail when authentication context is not preserved end to end. |
| Recommendation — Use explicit on-behalf-of or token-exchange flows that preserve the acting subject. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Delegation risk rises when downstream services rely on reusable or long-lived credentials. |
| AC-6 — Least Privilege | Delegation chains create excessive access when intermediary services carry more privilege than required. | |
| AU-3 — Content of Audit Records | Auditability is essential when multiple hops can change the acting identity. | |
| Recommendation — Rotate and constrain credentials so delegated access cannot become standing access. Restrict each hop to the smallest scope needed for its delegated task. Record the original subject, delegated scope, and downstream actor for each action. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Delegation chains need continuous verification across trust boundaries and services. |
| Recommendation — Verify every request at each hop instead of trusting prior network or service context. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Downstream services can over-authorise delegated actions when function-level checks are weak. |
| Recommendation — Apply explicit function-level checks before executing delegated actions. | ||
Practitioner Guidance
What to verify: Confirm whether each hop preserves subject, scope, and purpose, or whether it silently converts delegated authority into direct service authority. If the answer is unclear, treat the chain as a privilege boundary, not a plumbing detail.
Decision rule: If a downstream service cannot enforce the original actor’s intent, do not let it inherit broad credentials. Use shorter-lived delegated tokens, narrower scopes, or a separate authorisation decision for the downstream action.
What practitioners underestimate: The real risk is not only abuse by an attacker, but also routine drift, where teams gradually add fallback credentials, service tokens, and permissive defaults until the delegation chain no longer reflects the original access decision.
Practitioner takeaway: Safe delegation is less about moving trust along the chain and more about proving that the chain never widens authority, loses attribution, or changes the subject being authorised.
Related resources from NHI Mgmt Group
- Why do service accounts and delegation settings create so much risk in Active Directory?
- Why do AI agent runtimes create more governance risk than ordinary service accounts?
- Why do borrowed sessions and shared service accounts create agent security risk?
- Why do service-provider and AI-agent access paths create extra Reg S-P risk for covered firms?