liveBook · Manning

Delegation data

As explained in Authorization in Action

Delegation as data is a delegation model that represents transferred authority as structured data evaluated during authorization.

When a primary agent assigns work to a subagent, implicit trust can expand authority beyond its intended limits. Delegation data makes the transfer explicit and lets authorization policies evaluate it. section 18.6 section 18.6.1

A delegation record identifies the delegator and delegate, permitted actions, accessible resources, and validity conditions such as expiration. It narrows existing authority rather than granting new permissions. section 18.6.1 section 18.6.5

delegation_id: "d-1027"
delegator: Agent::"acme_assist"
delegate: Agent::"research_agent"
delegatedActions: [
  Action::"documents.search",
  Action::"documents.read",
  Action::"documents.summarize"
]
resourceScope: CustomerDocs::"CustCo"
expires: "2026-03-31T18:00Z"

A concrete record delegates document search, reading, and summarization for one customer’s documents until a specified expiration time. section 18.6.1

Evaluate delegated authority as part of every tool authorization request:

  • Require the requesting principal to match the delegate named in the record. section 18.6.3
  • Permit only actions listed in delegatedActions and resources within resourceScope. section 18.6.3
  • Reject requests outside the delegation’s validity window, regardless of other permits. section 18.6.3
forbid (
    principal,
    action,
    resource
)
when {
    context has delegation
}
unless {
    principal == context.delegation.delegate
};

A forbid rule creates a guardrail: a delegation record cannot be used by a principal other than its named delegate. section 18.6.3

permit (
    principal,
    action,
    resource
)
when {
    action in context.delegation.delegatedActions
    && resource in context.delegation.resourceScope
    && context.currentTime < context.delegation.expires
};

A permit rule grants only the delegated actions and resources while the delegation remains unexpired. section 18.6.3

Delegation can also evolve during a task: an agent may begin with document-reading authority and receive email permission only after completing an intermediate step. Policies still evaluate the current delegation state. section 18.4.5 section 18.6.6

How Authorization in Action covers it

How deep it goes
Defines delegation records and layered runtime policies, including identity, scope, resources, and expiration.
Examples
Uses customer-document access records, Cedar forbid and permit policies, and staged permission for sending email.
What it assumes
Assumes identity and policy-based authorization, while making implicit agent trust explicit through structured delegation data.
What you can do after
Operate/configure bounded subagent cooperation by encoding delegation constraints and enforcing them on every action.
How it connects
Connects agent identity, authorization policy, policy enforcement points, policy engines, task sequencing, and auditability.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Authorization in Action. The section links point to the parts of the book it draws on.