Delegate work without inventing new authority

TL;DR: Give each worker only the task authority needed for its part, and validate the requested effect against the current grant at the resource service. Authentication identifies a worker; it does not make the worker's claims true or permit it to create broader child grants. Shared limits and cancellation belong to the whole task, not to independent copies held by each agent.

Where you are. Module one, lesson two. You will extend CedarDocs task T-17 into a delegation map and test a small grant-admission model offline.

Split responsibilities before splitting prompts

The planner coordinates the CedarDocs maintenance task. A reader examines the designated renderer and guide. A patch worker proposes changes. A controlled test service can run the approved test workload. These names describe intended responsibilities; inspect actual credentials and reachable services before treating them as boundaries.

The planner should not give the reader publication authority simply because the planner can request a later publication decision. The reader also should not be able to modify the task service, select an arbitrary workload identity or write the policy that checks its own requests.

Keep these questions separate for every handoff: who sent it, which task authorizes the request, which data may cross, and what evidence supports the returned claims. An authenticated reader can still misunderstand a file or repeat misleading repository text.

Make the child grant a checked object

For T-17, the reader's child grant identifies its parent, the assigned worker, allowed resource IDs, effects, recipients, expiry and remaining delegation depth. The task service creates and stores this object after authenticating the requester and checking current parent authority. The child does not receive a general copy of Priya's account access.

A permitted read of Cedar's renderer does not imply a permitted read of Flint's private notes. A child can request more resources, but a controlled authority must decide whether the parent or a new grant covers them. The same applies to data audiences: a result may return to the Cedar planner while remaining ineligible for publication to a wider workspace.

Not every delegation uses identical scope strings. In a real integration, a parent permission may map to a narrower service-specific capability. That mapping requires an explicit policy. The exercise below deliberately uses the same closed vocabulary so set inclusion has a clear meaning; it does not claim that comparing arbitrary token scopes is sufficient.

Predict an admission decision before running it

This pure Python model checks whether a proposed child fits a known current parent. It uses trusted synthetic fixture records, logical time and exact resource identifiers. It does not authenticate callers, issue credentials, query current revocation state or perform network calls.

The two grants share the task's budget reference. A child-specific quota may further restrict its work, but must not reset the parent's shared 20 runner-minute limit from lesson one. Equal references alone do not enforce a counter; the budget service must check and reserve it atomically when work is admitted.

from dataclasses import dataclass, replace

@dataclass(frozen=True)
class Grant:
    grant_id: str
    task_id: str
    actor: str
    resources: frozenset[str]
    effects: frozenset[str]
    audiences: frozenset[str]
    expires: int
    depth: int
    budget_ref: str
    parent_id: str | None = None
    can_delegate: bool = False
    active: bool = True


def admits_child(parent, child, now):
    return (
        parent.active
        and parent.can_delegate
        and now < parent.expires
        and child.active
        and child.parent_id == parent.grant_id
        and child.task_id == parent.task_id
        and child.actor == "cedar-reader"
        and child.resources <= parent.resources
        and child.effects <= parent.effects
        and child.audiences <= parent.audiences
        and now < child.expires <= parent.expires
        and child.depth == parent.depth + 1
        and child.depth <= 1
        and not child.can_delegate
        and child.budget_ref == parent.budget_ref
    )


parent = Grant(
    "G-1", "T-17", "cedar-planner",
    frozenset({"renderer-v4", "guide-v8"}),
    frozenset({"read", "prepare-patch", "request-tests"}),
    frozenset({"cedar-planner", "cedar-reviewers"}),
    100, 0, "budget:T-17", can_delegate=True,
)
child = Grant(
    "G-1-reader", "T-17", "cedar-reader",
    frozenset({"renderer-v4"}), frozenset({"read"}),
    frozenset({"cedar-planner"}), 80, 1, "budget:T-17",
    parent_id="G-1",
)
print(admits_child(parent, child, 10))  # => True
print(admits_child(parent, replace(child, effects=frozenset({"publish"})), 10))  # => False
print(admits_child(parent, replace(child, resources=frozenset({"flint-note"})), 10))  # => False
print(admits_child(parent, replace(child, budget_ref="fresh-budget"), 10))  # => False
print(admits_child(replace(parent, active=False), child, 10))  # => False
print(admits_child(parent, child, 80))  # => False

The worker name and maximum depth are example policy choices. They are not a general delegation standard. Empty resource sets or other combinations may be useless even when they are subsets; admission validity and task usefulness are different questions. A production service also validates representation, supported effects and all relevant resource policy.

Creation-time admission is only one boundary

A child that passed at logical time 10 may be used after the parent is revoked. The resource service needs the current state and the relevant revocation model, not only a valid historical issuance record. A child credential does not universally become invalid merely because a parent credential was revoked; the system must implement that relationship.

Bind every effect to the actual child actor and task. Do not accept a grant identifier copied into arbitrary message text as proof of possession or permission. Restrict audiences and use the grant only at the intended services. When another organization is involved, explicitly map authority and resource identity rather than assuming matching tenant labels mean the same thing.

If the authority service is unavailable, follow the action's defined dependency policy. A high-impact effect may need to pause; already covered local analysis may continue if it does not depend on the missing decision. Document bounded caching and revocation delay where used rather than claiming instantaneous current-state checks everywhere.

Preserve evidence through the return path

The reader returns the source versions it inspected, its findings and uncertainty. The planner should be able to distinguish an observed line from a proposed interpretation. A typed response does not make a claim true, and a worker signature does not grant the planner permission to publish private evidence.

Correlate parent and child task IDs, operation attempts and policy decisions without copying secrets into logs. Retain the information needed to determine whether a child received an improper resource or exceeded its scope. An end-to-end trace helps; missing paths still require explicit coverage checks.

Do this before moving on

Add three cases to the fixture: a later child expiry, a new data audience and a valid reader request for the guide. Predict each result, then run the example in an isolated interpreter. Finally, write the additional check needed if G-1 is revoked after child creation but before the read.

Worked feedback. A child expiry beyond the parent and an audience outside the parent's set are rejected. The guide read can be admitted when the child remains a reader, keeps the shared budget reference and satisfies the other conditions. Later parent revocation requires current validation under the deployed revocation model; rerunning this function on an old parent snapshot would miss it.

Add a delegation row to the review packet: authenticated requester, child worker, task, resources, effects, audience, shared budget and revocation dependency. Identify who can change the mapping. The answer is incomplete if the child can edit that authority source itself.

Go deeper

• Multi-agent trust separates peer identity, task authority and evidence in handoffs.

• Multi-agent authorization checks resource and recipient policy across cooperating workers.

• Cross-organization agent trust explains why names and scopes need explicit mapping.

• Cascading failures follows shared limits and uncertain effects through task trees.

• Agentic AI security connects worker identity and resource authority to the broader system.

Key takeaways

• A child grant needs controlled issuance and execution-time validation.
• Scope comparisons require a defined vocabulary and policy mapping.
• A child shares the parent's aggregate accounting even when it has a tighter local limit.
• Provenance and authenticated messages support investigation but do not prove truth or permission.