Delegated authority for AI agents

Delegated authority is a bounded grant from an accountable origin or parent to another principal for a stated task, scope and duration.

01 / The operating case

What changes in a real workflow?

A finance agent sends document matching to a child; the parent may prepare invoices, but only a separately approved principal may release payment.

Trace the authority boundary
  1. 01Authority origin
  2. 02Task and grant
  3. 03Current decision
  4. 04Observed outcome

02 / Decision contract

What the executor must check

Validate the parent grant, delegation permission, child identity, narrower operation and expiry before accepting the handoff.

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

Architecture review / negative test

Make the boundary testable.

Specify the issuer, recipient, parent reference, allowed verbs, target set, purpose, expiry and further-delegation right in a child grant. Check subset relationships in every dimension, not just a string scope. A child may be shorter-lived and more constrained than its parent, but must not add payment authority absent from the parent.

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

Copying the parent credential lets a child inherit every operation, including ones irrelevant to its task.

Evidence to retain

Preserve parent reference, narrowing proof and revocation state for every child decision.

04 / Canonical scope

Why this reference stands alone

The existing multi-agent guide introduces delegation; this reference owns the grant semantics and issuer responsibility.

Implementation review

A child grant must prove origin and narrowing.

Delegation is not a copy of the parent credential. The handoff record should name its issuer, child principal, task, purpose, allowed operations and resources, expiry and onward-delegation right. Before an action, a validator walks to a trusted origin and intersects every edge with current policy. An invalid ancestor, scope expansion or revoked parent makes the descendant request fail even if the child token is still cryptographically valid.

Delegation edge and effective scope
origin: operator → agent-A {read, prepare} invoice-I42
edge: agent-A → agent-B {read} invoice-I42, 10 min
child request: prepare invoice-I42 → DENY
reason: prepare absent from child edge
parent revoked → subsequent read also DENY

Run the denial test

Issue a child grant, revoke its parent, then attempt the same read through another runtime. The second runtime must not accept a stale child grant. Add a sibling grant and confirm rights are intersected where required, never unioned to manufacture a new operation.

Evidence to examine

Keep issuer and subject IDs, edge IDs, scope subset check, expiry, revocation observation, action decision and attempted effect. The lineage is more informative than the child credential alone.

Primary source: NIST NCCoE agent identity and authorization concept

Related: Authority chain validation.

Architecture field test

The authority narrowing principle

Can a child legitimately receive this permission?

Decision path for this question
  1. 01Trusted origin issues parent grant
  2. 02Parent delegates a subset
  3. 03Child presents chain at action time
  4. 04Executor checks every ancestor

Work the boundary

A purchasing agent can obtain supplier quotes and delegates catalog lookup to a short-lived child. The child may read the named supplier catalog, but cannot place an order. A token issued to the child proves identity; the chain explains why catalog read is in scope.

Decision contract and failure case
Required factsIssuer, child subject, task, action and resource subset, expiry, onward-delegation right and live ancestor state.
Allow only whenEvery child permission is contained in a live upstream grant and current policy also allows the leaf action.
Deny whenA read-only parent delegates payment release, or a valid child token survives a revoked ancestor.

Break the assumption

Revoke the parent immediately before a queued child request. Make the receiving runtime resolve revocation or deny when freshness cannot be established. Test a sibling grant separately; do not union sibling rights into the child.

Design tradeoff

Short-lived credentials reduce exposure but do not replace revocation or subset checks. Deep chains add validation cost, so deployments need a bounded depth and a defined freshness budget.

For the authority narrowing principle, consult NIST NCCoE agent identity and authorization concept. This worked decision and negative test are ProofGrid analysis.

Continue with Authority chain validation.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation