T50 · OWASP Agentic AI v1.1
Delegation-Scope Escalation
A multi-hop delegation chain (A→B→C) hands each successive hop a scope no narrower than the one it received, so authority compounds across hops instead of shrinking to what each link actually needs.
Definition
Delegation-Scope Escalation is the failure to narrow authority as it passes down a chain of delegations. When agent A delegates to agent B, and B in turn delegates to C, each hop should hand forward only the subset of scope the next link genuinely needs — the principle of least privilege applied per hop. When instead each hop forwards a scope that is the same as, or broader than, the one it received, authority does not shrink toward the leaf; it compounds. The final agent in the chain ends up holding permissions no single delegation ever intended it to have, assembled by accumulation rather than by any explicit grant.
It is distinct from T3 Privilege Compromise (which concerns a single agent holding more than it should) and from T14 (agent-to-agent authentication): here every individual hop may be authenticated and individually plausible, yet the composition of the hops produces an over-privileged endpoint. The escalation lives in the chain, not in any one edge.
What it looks like in practice
A user grants a planning agent broad access to their calendar, mail, and a payments API for a “book my trip” task. The planning agent delegates the payment step to a specialist booking agent, forwarding the same token scope it holds rather than a payment-only sub-scope. The booking agent, needing to confirm a reservation, delegates to a third-party confirmation agent — again forwarding its full inherited scope. The confirmation agent, which only ever needed read access to a booking reference, now transitively holds the user’s mail and calendar scope as well. Nothing in the chain narrowed. A prompt injection or a compromise at the leaf now reaches back across the whole scope the user originally granted at the root.
The chain is often assembled dynamically at runtime, so no single design review ever sees the composed authority the leaf ends up with.
Why it’s dangerous in multi-agent context
Multi-agent systems delegate constantly, and delegation is exactly where least privilege is easiest to lose. A bare bearer token forwarded unchanged carries the full scope of the caller; even OAuth 2.0 on-behalf-of exchange (RFC 8693), which preserves the original caller’s identity through the hop and so improves attribution, does not by itself guarantee that the scope is narrowed at each step. Because each hop can look individually legitimate, the escalation is invisible to per-edge checks — it is only detectable by reasoning about the chain as a whole and comparing the scope entering a node against the scope it forwards. This is the mechanism behind the OWASP Non-Human Identities Top 10 risk NHI5 “Overprivileged NHI”: authority that accretes across delegations until a non-human identity holds far more than its task requires.
Detection signals
The escalation is a property of the chain, so detection compares scope across hops rather than inspecting any single delegation.
- A node with both an incoming and an outgoing delegation whose outgoing scope is the same as, or broader than, the widest incoming scope it received. This same-or-wider comparison across a hop is the direct signal that narrowing did not occur.
- A delegation edge that forwards a bare bearer token or a full inherited credential rather than a freshly minted, audience-restricted, scope-narrowed token for the specific downstream call.
- A leaf agent whose effective (transitively inherited) scope exceeds the union of scopes any of its own tasks require — surfaced by walking the delegation graph from each root and accumulating forwarded scope.
- Use of OAuth on-behalf-of exchange without an accompanying scope-narrowing step: identity is preserved through the hop, but the token’s granted scope is unchanged from the caller’s.
Mitigations
- Narrow scope at every hop: mint a fresh, audience-restricted (RFC 8707 resource-indicator) token scoped to exactly the downstream call, rather than forwarding the inherited credential.
- Model delegation scope explicitly on each delegation edge and enforce, at the delegating node, that the outgoing scope is a strict subset of the incoming scope.
- Prefer short-lived, task-scoped credentials issued per delegation over long-lived tokens that carry broad standing authority through the chain.
- Govern non-human identities against the OWASP NHI Top 10, treating an over-privileged transitive scope as a first-class finding rather than an accident of composition.
Relation to base threat (T1–T17)
T50 extends T3 Privilege Compromise and T14. Where T3 concerns a single agent holding excessive privilege and T14 concerns authentication between agents, T50 is the compositional variant: every hop may authenticate correctly and hold an individually plausible scope, yet the chain as a whole delivers an over-privileged leaf because no hop narrowed. It is the multi-hop, scope-accumulation failure that neither a per-agent privilege review (T3) nor a per-edge authentication check (T14) catches on its own.
Design principles at stake
When T50 is present, these security design principles are the ones being violated or tested. Each links to the full principle; the mitigations below are how you restore them.
- Defence-in-DepthIndependent controls at multiple layers, so defeating one still leaves others standing.
Recommended mitigations
Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T50, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).
A Non-Human Identity (NHI) is the service account, machine principal, or formal agent identity under which an agentic system authenticates and acts. When an NHI is provisioned with broad scope, never rotated, and has no named owner, a stolen or leaked credential gives an attacker persistent access for as long as that credential remains valid. NHI lifecycle management treats each agent identity as a first-class governance object: provision narrowly with a declared scope and owner, rotate on a short schedule using platform-native short-lived credentials, audit every authentication and rotation event, re-attest that the identity is still needed, and decommission by deletion when the agent is retired.
why it helps Delegation-Scope Escalation compounds when every NHI in a chain is provisioned with whatever scope was convenient rather than the narrowest the hop needs. Narrow provisioning at issuance and periodic re-attestation are the lifecycle-governance side of the same fix RFC 8693 token exchange enforces mechanically — the identity a hop mints or holds should never be broader than the delegation it is currently exercising.
Role-Based Access Control (RBAC) assigns every agent identity a named role that sets the outer limit on what it can reach. Attribute-Based Access Control (ABAC) narrows individual decisions inside that role by evaluating contextual attributes at request time. Used together, they enforce least privilege for non-human identities: the agent can only do what its role permits, and only when the request attributes satisfy the policy.
why it helps Delegation-Scope Escalation is a multi-hop chain where each hop hands the next one a scope no narrower than what it received. Evaluating the ABAC policy fresh at every hop — rather than forwarding an inherited grant unchanged — forces each link to justify its own outbound scope against the downstream task, which is what stops the chain from compounding authority instead of shrinking it.
- Tier 3Intent attestation(Intent attestation tokens — a cryptographic binding from user approval to tool execution)
An agent acts on behalf of the user, but nothing in a standard OAuth bearer token records what the user actually approved. If the agent's planning is manipulated, it can invoke tools with parameters the user never sanctioned, while presenting credentials that look valid. Intent attestation fixes this by issuing a short-lived signed token that encodes the exact action and parameter envelope the user authorised, and requiring the resource server to verify that envelope before executing the call.
why it helps Delegation-Scope Escalation is a multi-hop chain (A→B→C) where each hop hands the next one a scope no narrower than what it received. RFC 8693 Token Exchange is the mechanical fix: each hop requests a NEW token scoped to exactly what the downstream call needs, carrying the prior subject/actor chain forward rather than re-issuing the same broad grant unchanged — so down-scoping is a property of the exchange, not something the author has to remember to do by hand.
References
- OWASP Non-Human Identities Top 10 (2025), NHI5 Overprivileged NHI — owasp.org/www-project-non-human-identities-top-10/
- RFC 8693, OAuth 2.0 Token Exchange (on-behalf-of delegation) — datatracker.ietf.org/doc/html/rfc8693
- IETF draft-klrc-aiagent-auth (individual draft, v-02, 2026-06-01) — authorization for AI agents; not yet a working-group item.
- Cloud Security Alliance, Non-Human Identity governance whitepaper (2026-05-20).
Sources
- OWASP-Agentic-AI ↗ · 1.1 · Extends T3 Privilege Compromise + T14 across a multi-hop delegation chain
Adapted by Helmwart from the OWASP source(s) above underCC BY-SA 4.0(changes: normalized IDs, added MAESTRO-layer, agentic-factor, and mitigation mappings). This entry is licensed CC BY-SA 4.0.