They should preserve the full delegation chain and evaluate authority at each hop, not just at the first caller. Sub-agents can amplify or obscure privilege if the chain is not signed, bounded, and carried into policy evaluation. The right design makes delegation explicit enough to audit and constrain.
How sub-agent delegation changes the trust decision
Once a workflow delegates work to a sub-agent, the trust decision is no longer a single check at the original caller. Each hop can change who is acting, what was delegated, and which permissions are actually in scope. Teams should treat the delegation chain as part of the security boundary, not as implementation detail, and preserve enough context to evaluate authority end to end.
That means the workflow should carry forward a delegation record that is explicit, bounded, and attributable. If the chain is collapsed too early, policy may see only the top-level principal and miss the effective actor, the delegated scope, or the fact that a sub-agent is reusing authority in a wider context than intended. For delegation mechanics, RFC 8693: OAuth 2.0 Token Exchange is the clearest external model for preserving on-behalf-of context across hops.
In practice, this is the difference between “the caller was allowed” and “this specific delegated action was allowed.” The second statement is what keeps policy aligned with actual execution, especially when sub-agents can fan out, hand work to other agents, or return results that look trustworthy but were produced under broader authority than the first caller had alone.
A useful design rule is that delegation should be explicit enough to answer three questions at audit time: who delegated, who executed, and under what bounds. If the answer requires inference from logs or tool traces, the chain is too opaque for reliable policy evaluation.
Where delegation becomes a control problem
Delegation becomes risky when authority is implicit, reused, or not reduced for the task. Sub-agents can inherit more access than they need, and that creates a pathway for overreach, confused deputy behaviour, or policy bypass if downstream steps are evaluated against the wrong identity or an incomplete delegation record.
Good controls therefore focus on bounded delegation, not just authentication. The workflow should carry task scope, expiry, and approval context so that each sub-agent action is evaluated against the rights actually granted for that hop. When the delegated chain reaches tools or APIs, those permissions should still be interpreted per action, not assumed from the original request alone. For agent authorization patterns, the AI Agent Authorisation Guide is a useful internal companion, and the Zero Trust for AI Agents guide reinforces the need to verify principal and request at each step.
When delegation crosses agent boundaries, signed or verifiable handoff becomes important because it reduces ambiguity about who asserted what. Without that, a later agent can appear to have legitimate authority simply because it received a token, message, or context blob, even if the provenance of that authority is unclear.
Teams should also watch for delegation chains that expand silently over time. A workflow that begins as a narrow helper can become a multi-hop execution path with much larger blast radius, especially if the original policy never gets re-evaluated after the first handoff.
What teams should build into the workflow by default
Teams should design sub-agent delegation so that every handoff is traceable, every delegation is bounded, and every action is policy-evaluable on its own merits. The practical standard is not “can the agent do the job?” but “can we prove which authority enabled this exact step?” That is what makes delegation auditable and controllable rather than merely functional.
What to verify: Confirm that the delegation record survives transport, that it cannot be stripped by an intermediate agent, and that policy checks use the delegated context rather than the upstream caller alone. The chain should remain intelligible even when several agents collaborate.
Implementation sequence: Start by defining the minimum delegation claims needed for task execution, then bound them by scope and time, then require downstream authorization to consume those claims explicitly, and finally log the full hop sequence for review and incident response.
Common mistake: Treating the first authenticated caller as the only identity that matters. That shortcut is convenient, but it breaks as soon as a sub-agent narrows, widens, or reuses authority in a way the original policy never expected.
Practitioner takeaway: If a sub-agent can influence a real system action, its delegated authority must be visible to policy and audit at the point of use, not reconstructed later from traces.
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 MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Sub-agent delegation can widen or obscure effective authority. |
| Recommendation — Enforce least privilege and per-action checks for each delegated hop. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service Organizations) | Sub-agents and tools authenticate as non-human actors in delegated flows. |
| Recommendation — Require strong service-to-service authentication for every delegated execution path. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Each hop should be verified and authorized independently in delegated workflows. |
| Recommendation — Verify the principal and request at every hop instead of trusting upstream context. | ||
| OWASP ASVS | V8 — Authorization | Delegated actions need explicit authorization checks on the effective actor. |
| Recommendation — Validate that each action is authorized for the delegated context before execution. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Delegation abuse can alter or extend effective access during execution chains. |
| Recommendation — Detect unexpected permission changes or delegation expansion during agent workflows. | ||