Multi-agent authorization

Multi-agent authorization checks each delegation from an accountable origin through parent and child agents, then evaluates the child’s proposed action against current policy.

01 / The operating case

What changes in a real workflow?

A coordinator assigns reconciliation to two agents; one child attempts to pay an invoice despite receiving only read and match grants.

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

Validate every ancestor, narrow rights at each handoff, check revocation and shared limits, and enforce at payment execution.

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

Architecture review / negative test

Make the boundary testable.

Start with the final effect and trace backward through every grant edge. An agent conversation transcript may explain intent but cannot substitute for a verifiable delegation chain. At each handoff, intersect the parent’s actual permission with the child’s scope and current policy, including restrictions on further delegation.

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

The child presents a valid identity while the parent-to-child grant or payment right is missing.

Evidence to retain

Retain chain references, subset-validation result, budget usage, final decision and observed payment state.

04 / Canonical scope

Why this reference stands alone

The existing multi-agent solution and guide introduce the model; this reference owns end-to-end decision mechanics.

Implementation review

Authorize the leaf effect against the whole handoff chain.

At the final action boundary, a child agent needs a valid identity, a live narrower grant from its parent, a valid origin and a policy decision for the concrete operation. Parallel children also share aggregate constraints; checking each in isolation can multiply an approved budget. The executor should use the effective intersection of origin, ancestor grants, resource policy and current context.

Two-child authority example
origin grant: reconcile invoices, release ≤ USD 25,000 total
child A: release invoice I-42, USD 20,000
child B: release invoice I-43, USD 20,000
A reserves USD 20,000 → ALLOW
B sees USD 5,000 remaining → DENY
parent revoked → both future calls DENY

Run the denial test

Race both child requests at the same executor and inject a lost provider response after A commits. The shared budget must hold A’s reservation until reconciliation; B cannot spend the unresolved capacity.

Evidence to examine

Retain each delegation edge, scope intersection, shared budget reservation, final action decision, provider reference and reconciled aggregate outcome.

Primary source: NIST NCCoE agent identity and authorization concept

Related: Shared authority budgets.

Architecture field test

Authorize the leaf against the whole chain

Can this child perform this action now?

Decision path for this question
  1. 01Authenticate child and host
  2. 02Validate every parent grant
  3. 03Apply shared constraints
  4. 04Decide at final executor

Work the boundary

A coordinator can inspect invoices and prepare payments but cannot release them. It delegates invoice matching to one child and fraud review to another. Neither child may release payment by combining their separate permissions or borrowing the coordinator’s API credential.

Decision contract and failure case
Required factsOrigin, child identity, every delegation edge, current revocation, action, target, policy and shared budget.
Allow only whenThe effective intersection of ancestry and policy covers the leaf effect, and aggregate limits remain available.
Deny whenA child gains a permission absent from its parent or siblings collectively exceed an origin ceiling.

Break the assumption

Present a chain with one wider edge in the middle, then route the same final call through another runtime. Both must reject. Race two permitted children against a shared amount ceiling to test aggregate enforcement.

Design tradeoff

A centralized leaf decision improves consistency but may add cross-runtime latency. Cached chain proofs need versioning and revocation rules; otherwise a once-valid parent can continue authorizing descendants after cancellation.

For authorize the leaf against the whole chain, consult NIST NCCoE agent identity and authorization concept. This worked decision and negative test are ProofGrid analysis.

Continue with Shared authority budgets.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation