> ## Documentation Index > Fetch the complete documentation index at: https://docs.visiqlabs.com/llms.txt > Use this file to discover all available pages before exploring further. # Delegation Governance > Governs agent-to-agent handoffs — when one agent delegates authority to another, the child's power is the parent's authority intersected with an explicit, revocable grant. Delegation governance controls what one agent can **hand off** to another. When a parent agent asks a child agent to act on its behalf, the platform issues a scoped, time-boxed, signed grant — and the child's authority is never more than the parent's own authority intersected with what the grant explicitly permits. `delegation` is a first-class operation alongside `action` and `retrieval`, evaluated by the same rule engine. Delegation is the third governed operation. Where action governance decides what an agent can **do** and retrieval governance decides what it can **see**, delegation governance decides what authority an agent can **pass on** — and holds that transfer to a signed, revocable, audited grant. *** ## The invariant One rule holds throughout the delegation surface: > **child authority = parent authority ∩ explicit grant** A child can never receive more than the parent already holds, and never more than the grant names. Both the tool scope (which actions) and the context scope (which resource types) are intersected on every handoff, so authority only ever narrows as it flows down a delegation chain — it can never widen. Every grant is backed by a **synchronous, fail-closed record proof**: the platform writes the tamper-evident record row *before* it returns a grant id or a token. No proof, no grant. This closes the gap that fire-and-forget audit envelopes leave open — a delegation that isn't provably recorded never happens. *** ## The grant lifecycle The parent calls `POST /orchestrate/grants` naming the child agent and the tool/context scopes it wants to hand off. The platform runs a policy check on the delegation itself, intersects the scopes against the parent's authority, and returns a `pending` grant with a short **accept window** (5 minutes). The child calls `POST /orchestrate/grants/:id/accept`, declaring its own identity in the `X-Agent-ID` header. Only the named child can accept. On success the platform issues a **signed grant token** scoped to that child, bound to the grant, and expiring per the requested duration. For each action the child performs under the grant, it calls `POST /orchestrate/evaluate` with the grant token. The platform verifies the token, walks the ancestor chain, checks the action against the grant's tool and context scopes, and returns `permit` or `deny` — recording a handoff event for every decision. Either side revokes with `POST /orchestrate/grants/:id/revoke`. Revocation cascades eagerly to every descendant grant in one atomic step, so cutting a grant high in the chain instantly invalidates everything delegated beneath it. *** ## Bilateral identity A handoff has two sides, and both are verified. The parent is the authenticated caller that creates the grant; the child proves its identity at accept time through the `X-Agent-ID` header, which must match the `child_agent_id` the grant was created for. Both agents must be registered for your organization — an unregistered agent on either side is rejected. The grant token issued at accept time is signed and carries the child's identity, so a token minted for one child can never be replayed by another. *** ## Sub-delegation and depth A child that holds a grant can itself delegate onward by passing its grant token as the `parent_grant_token` on a new `POST /orchestrate/grants` call. Each hop increments the chain depth, and every grant carries a `max_depth` ceiling (default 3, hard cap 16). A delegation that would exceed the ceiling is rejected, so a chain can only run as deep as the root grant allows. Because authority is intersected at every hop, a grant three levels down holds at most the intersection of all three grants above it — the transitive floor of the whole chain. Enforcement also re-walks the ancestor chain on every `POST /orchestrate/evaluate`: if any ancestor grant has been revoked or expired, the descendant's action is denied, even before the descendant's own token expires. *** ## Fail-closed throughout Delegation is an authority transfer, so it defaults to the most restrictive outcome at every step: * **Uncovered delegation in enforce mode is denied.** A delegation with no rule permitting `orchestrate.delegate` for the parent fails closed — authority transfer requires an explicit permitting rule (or an agent still in monitor mode during onboarding). * **An unreadable ancestor chain denies.** If the platform cannot verify the chain of grants above an action, it denies rather than permits. * **A missing record proof aborts the grant.** If the synchronous proof write fails at create time, the grant is immediately revoked and the call errors. *** ## Relationship to the unified engine Delegation is not a separate system. The delegation decision itself rides the same event spine as every action and retrieval: creating a grant writes an audit event tagged `operations: ["delegation"]`, evaluated by the same engine. You can also run delegation-facet policy directly through the unified `POST /evaluate` call with `operations: ["delegation"]` — see [Unified Rules](/rules/unified/api-reference). The `/orchestrate/*` surface on this page is the **grant lifecycle and per-action enforcement**; the unified evaluate call is the **stateless policy check** for a single delegated event. *** ## Next steps REST API for grants, acceptance, revocation, and per-action enforcement. One rule surface over every operation, including `delegation`. Every grant, acceptance, and revocation is a verifiable record. What agents can do — the operation delegation hands off.