No. Authority can only narrow as it passes down a chain of agents. A sub-agent acts within the lower of two limits: what the orchestrator itself holds for that task, and what the sub-agent is certified to do. The orchestrator cannot override either, and the platform, not the orchestrator's instructions, has to enforce it.
Why can authority only narrow?
Because the alternative is a loophole. If an orchestrator could hand out more than it holds, any agent able to delegate could reach any capability in the business by finding a sub-agent willing to act. Security engineers call this the confused deputy problem: a component with broad rights is tricked into using them on behalf of one with narrow rights.
With agents the risk is sharper, because orchestrators take instructions in natural language. A sentence in a customer email that reaches the orchestrator could become a delegation request. If delegation could widen authority, prompt injection would become privilege escalation.
The rule that prevents this is simple to state. A sub-agent's effective authority for a delegated task is the intersection of the orchestrator's authority for that task and the sub-agent's own. Both what an orchestrator agent is and what a sub-agent is are defined with this limit in mind.
Does depth 5 mean an orchestrator can do anything?
No, and this is the most common misreading. Depth 5 means an agent may coordinate other agents. It is a separate capability, not a level above depth 4. An orchestrator at depth 5 for coordination may still hold depth 1 for payments, meaning it can read payment data and nothing more.
So an orchestrator certified to coordinate month-end close can assign the bank reconciliation to one agent and the accruals to another. It cannot cause either to post a payment, because it holds no payment authority to pass on.
How is the limit applied at each action?
Every action a sub-agent takes on a delegated task meets the minimum chain: its role scope, its certificate, its sources, the customer's own limits and the platform guardrails. Delegation adds one more input: the orchestrator's authority for that task. The lowest bound wins.
| Orchestrator holds for refunds | Sub-agent certified for refunds | Effective depth on the delegated task |
|---|---|---|
| Depth 1 (read) | Depth 3 | 1: the sub-agent may look up the order, not issue the refund |
| Depth 2 (draft) | Depth 3 | 2: the sub-agent drafts; a person sends |
| Depth 3 | Depth 2 | 2: the sub-agent's own certificate decides |
| Depth 3 | Depth 3 | 3 within the customer's limits |
Each verdict names which bound decided. If a refund is held because the orchestrator lacked authority, the record says so, which tells you where to look if the outcome was wrong.
What does this look like in practice?
Take a retail bank's complaints orchestrator. It reads a complaint, decides it needs a fee refund, a letter and a case note, and delegates each to a specialist agent. The refund agent is certified to issue fee refunds up to the customer's limit at depth 3. The orchestrator is certified only to draft refund decisions at depth 2, because its job is triage, not redress.
The refund agent therefore drafts the refund and the platform holds it for a complaints handler. The letter agent drafts the response at depth 2, also held. The case-note agent writes the note at depth 3, because the orchestrator holds that capability at depth 3 and so does the case-note agent. One complaint, three verdicts, each traceable to the bound that decided it.
If the business later decides triage should also cover small refunds, it raises the orchestrator's refund depth through certification. It does not edit the orchestrator's prompt to tell it to "approve small refunds".
What controls should be in place?
- Delegation passes through the platform with a task id, never directly between agents. See how an orchestrator agent should delegate work.
- The platform computes effective authority at the moment of each sub-agent action, not when the task was handed over.
- Sub-agents cannot re-delegate with wider authority than they received.
- Every refusal and hold names the deciding bound.
- Raising an orchestrator's authority is a certification change with an approver, not a configuration edit.
Why this matters across a whole estate of agents is argued in orchestration without authority sprawl. The layer that enforces it is described in the governed agentic operating system guide.
Questions people ask
Can a sub-agent have more authority than its orchestrator in general?
Yes. A refund agent may be certified to depth 3 while the orchestrator that sometimes calls it is at depth 2. The sub-agent uses its full depth on work routed to it directly, and the narrower depth on work the orchestrator delegates.
What if a person asks the orchestrator to do something urgent?
The person can approve the held action, which is the designed route. They cannot instruct the orchestrator to bypass bounds; urgency changes who approves quickly, not what the agent may do.
Does this apply when the sub-agent is from another vendor?
Yes. The rule is enforced by the governing layer, so it holds whoever built the sub-agent, provided its actions pass through that layer.