Delegated approval in agent workflows

Specify who may approve a child agent’s proposed effect.

01 / The operating case

What changes in a real workflow?

A parent agent requests a manager review of a child’s account suspension proposal.

Trace the authority boundary
  1. 01Origin grant
  2. 02Parent agent
  3. 03Narrow child grant
  4. 04Action boundary

02 / Decision contract

What the executor must check

Verify approver authority for exact action, account and context; bind approval to request digest and expiry.

InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

A parent’s own delegated scope is mistaken for human approval rights.

Evidence to retain

Approver identity, displayed proposal, decision, expiry and final executor result.

04 / Canonical scope

Why this reference stands alone

Human approval covers one agent action; this page owns approval across a delegation chain.

Technical artifact

Approval and delegation are different edges

Conceptual trace
parent P delegates account.review to child C
C proposes account.disable(A42)
approver U9 has disable authority; parent P does not
U9 approval bound to request hash H
executor checks both C grant and U9 approval

Run the denial test

Let P emit “approved” as an agent message without a separate authenticated approver. The executor must deny.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation