Delegation Must Shrink Authority at Every Agent Handoff

An autonomous organization cannot safely scale by giving every specialist agent the authority of the coordinator that called it. A procurement agent may ask a pricing agent to prepare a quote. That pricing agent may ask a data agent to retrieve a contract term. Each handoff is an authority boundary, not merely a message between software components.

The governing rule should be simple: a child agent may receive only authority derived from, and no broader than, its parent’s grant. Not a copy of the parent credential. Not an assertion that the agents belong to the same workflow. A new, constrained grant with a demonstrable relationship to the one above it.

This is a distinct runtime problem from authorizing a final payment, deployment or external message at commit time. Commit-time authorization asks whether a proposed action may happen now. Delegation asks what bounded authority an agent may safely subdivide before several agents reach their own action boundaries. A sound organization needs both controls.

Identity records the relationship; it does not bound the power

RFC 8693 provides useful language for this problem. It distinguishes delegation from impersonation. In delegation, an actor keeps its own identity while exercising rights received from another principal. The specification supplies subject-token, actor-token and act-claim primitives to represent that relationship.

That distinction matters operationally. If a research agent acts under authority delegated by a finance principal, the runtime should be able to say both who remains responsible for the authority and which agent is acting now. Treating the agent as the principal through impersonation loses a material accountability boundary. Treating a delegation as an anonymous service call loses both.

But a visible chain is not a safety proof. RFC 8693 allows nested act claims to record delegation history, while explicitly stating that prior actors are informational and must not drive access-control decisions. The resource server considers the token’s top-level claims and current actor. A chain can explain how a token arrived; by itself it cannot show that each earlier handoff was narrower than the previous one.

“Delegation history is evidence for investigation. Attenuation is an invariant for enforcement.

A governed runtime should therefore keep identity and authority as related but separate objects. The first answers: which principal is responsible, and which actor is operating? The second answers: what may this actor do, against which resources, with what inputs, until when, and may it delegate any part of that authority again?

Model a delegation as a derived grant

The practical unit is a grant node in a parent-child graph. A parent grant authorizes a specific actor within a defined envelope. A child grant names a child actor, references its parent, and carries a smaller or equal envelope. The runtime issues the child only after proving that containment. It then verifies the same constraints whenever the child is used at a protected boundary.

The envelope should be structured rather than reduced to a single broad scope string. RFC 9396, Rich Authorization Requests, provides a relevant primitive: authorization details can express actions, resource locations, data types, privileges and transaction-specific constraints, and a user can grant only a subset of what was requested. Those objects do not by themselves impose recursive attenuation. They do, however, provide a vocabulary a runtime can compare.

For each dimension, the child’s allowed set must be contained in the parent’s. The comparison must be explicit and machine-checkable, including at least:

• actions: a child allowed to read invoices cannot acquire approval or payment actions;
• resources and tenants: a grant for one supplier record cannot become access to all supplier records;
• data classes: access to selected contract fields cannot become access to the full document set;
• argument values: an agent permitted to update a delivery date cannot alter bank details or legal terms;
• transaction limits: a child’s amount, currency or quantity ceiling cannot exceed the parent’s;
• time and spend: expiration and remaining budget may narrow, never extend or replenish;
• delegation depth: a grant with no further delegation cannot produce a grandchild grant.

Some dimensions are not simple sets. A monetary ceiling is an ordered bound. A spend limit is also stateful: the runtime must account for reservations or consumption, rather than compare the original number repeatedly. Argument restrictions may require a policy language with an explicit subset relation. The important design decision is not a universal syntax. It is refusing to issue a child grant when the runtime cannot prove that its requested envelope is contained by its parent.

Enforce at issuance and at use

Issuance enforcement prevents an agent from minting an overbroad credential. Use enforcement prevents an otherwise valid credential from being exercised outside its envelope. Neither replaces the other. A token can be well formed yet presented to the wrong resource, after its budget is exhausted, or after its ancestor has been revoked.

The enforcement point belongs at the service boundary, not in an agent instruction. NIST SP 800-207A describes granular authorization based on application and service identities, with runtime enforcement through components such as API gateways and sidecar proxies. In an agent runtime, those boundaries can validate the current actor, the responsible principal, the grant identifier, the requested operation and the relevant constraints before the downstream system receives the call.

Credential format is an implementation choice, not the architecture. Token exchange can carry subject and actor relationships, and structured authorization data can describe a constrained request. The Macaroons research offers a useful precedent: downstream credentials accumulate caveats that limit where, when, by whom and for what purpose they may be used. The governing property is monotonic reduction. A downstream party may add constraints; it must not remove constraints or invent broader rights.

Revocation needs graph semantics

A delegation tree also creates a lifecycle obligation. RFC 8693 is clear that token exchange does not generally create lifecycle linkage between input and output tokens; propagation of revocation is implementation-specific. An organization cannot assume that revoking a parent token automatically disables its children.

The runtime should make the linkage explicit. Every derived grant needs a parent reference, an independent identifier, an expiry, and a revocation state. When a parent is revoked, suspended or exhausted, descendants should become unusable according to a defined propagation rule. A boundary enforcement point can resolve that status online, validate a compact revocation representation, or accept only short-lived grants. The operational requirement is the same: a child must not remain actionable after the authority from which it derives has ceased to be valid.

This graph is also the basis for incident response. If a supplier-data agent is compromised, operators should be able to locate grants it received, grants it issued, affected resources and the responsible principal. A flat log of participating identities cannot provide this control surface reliably.

Make the proof visible to operators

For every handoff, persist a delegation record that links parent and child grants and captures the requested and issued envelopes, the containment decision, the policy version, the principal, the current actor, issuance time, expiry, depth and revocation outcome. Preserve enough normalized constraint data to answer a hard question later: why was this specific agent allowed to request this specific operation?

The system should reject ambiguity rather than turn it into privilege. If one agent requests a child grant whose data classification, resource selector or argument predicate cannot be compared to the parent, the safe result is denial or a smaller, intelligible grant. Human escalation may be appropriate, but silent broadening is not.

The consequence for autonomous organizations is architectural. Agent specialization becomes safer not because every agent is trusted, but because no handoff can enlarge the operational blast radius. A coordinator can distribute work while keeping payment limits, data boundaries, time windows and onward-delegation rights attached to the work itself. That is how an organization gains composability without allowing a task graph to become an uncontrolled privilege graph.

A minimum runtime contract

• Represent each delegation as a child grant with a parent reference, a responsible principal and a current actor.
• Define a machine-checkable containment relation for every authority dimension the organization delegates.
• Verify containment when issuing a child grant and verify the resulting constraints at each protected service boundary.
• Set explicit depth, expiry and spend semantics; do not infer them from workflow membership.
• Maintain descendant-aware revocation and make its propagation behavior observable.
• Treat history as audit evidence, not as a substitute for present-tense authorization.

The test is uncompromising: if an agent delegates work, can the runtime prove that the recipient acquired less authority, never more? If it cannot, the system has forwarded trust rather than governed it.