Delegation Governance

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.

---

​

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

---

​

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. 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