Blog · October 9, 2026 · 12 min read

AI agent delegation that preserves authority

AI agent delegation fails when a parent creates a child task but leaves the user's limits behind. The child might inherit a broad service token, receive records the parent could not combine, outlive a revoked grant, or keep running after the user cancels the visible job. Each request can pass its own access check while the completed workflow reveals or changes something nobody authorized. A product-owned delegation envelope prevents that drift. It narrows authority, context, time, depth, and budget at each handoff and ties every descendant and returned artifact to the initiating user and run.

Why request-level authorization is not enough

Most product authorization answers a local question: may this actor perform this action on this resource now? That check does not capture the relationships between tasks in a delegation chain.

The parent may retrieve customer accounts and the child may retrieve support tickets. Each read can be valid in isolation, yet joining the two datasets may reveal restricted account status to a support workflow. A grant may also expire while a child waits in a queue. A parent can stay within its own call limit while ten descendants exceed the user's aggregate budget.

The May 2026 preprint Authorization Propagation in Multi-Agent AI Systems treats these as failures of the whole workflow. It separates them into three classes:

• Transitive delegation: a child receives authority the parent did not possess or could not delegate.
• Aggregation inference: individually allowed outputs combine into a result that exceeds the user's information boundary.
• Temporal validity: a delayed action executes after its underlying grant, approval, or business condition changed.

Role-based checks at each service validate individual edges. They do not prove that the full path stayed within one grant.

Start from an authenticated root grant

A delegation tree needs a clear root principal. The MIT paper on authenticated delegation and authorized AI agents describes a chain from a human principal to separately identified agents, with authorization and auditability attached. In an existing product, that chain should begin with a product-owned grant rather than a copied browser session or tenant-wide service credential.

Record these facts before the parent starts work:

• authenticated user and tenant;
• eligible product workflow and requested outcome;
• current resource and action scope;
• immutable agent release and policy version;
• maximum duration, spend, tool calls, and side effects;
• whether delegation is allowed and its maximum depth;
• approval requirements and approval-object version;
• cancellation and revocation handles;
• data classes permitted in context and output.

Trusted product code must derive these values from the authenticated request, current authorization, registered workflow, approved release, and policy service. Model output cannot set them.

Build a delegation envelope for every child

Create a fresh envelope for every delegation. The envelope is an integrity-protected capability description and task contract, not a natural-language prompt.

{
  "version": "delegation-envelope-v1",
  "delegation_id": "dlg_01K2",
  "root_run_id": "run_01K0",
  "parent_task_id": "task_01K1",
  "child_task_id": "task_01K2",
  "principal": {
    "tenant_id": "tenant_42",
    "user_id": "user_108"
  },
  "agents": {
    "parent": "support-orchestrator-v12",
    "child": "refund-evidence-agent-v4"
  },
  "purpose": "collect evidence for refund eligibility",
  "resources": [
    "order:ord_319",
    "ticket:ticket_882"
  ],
  "tools": [
    "orders.read.v3",
    "tickets.read.v2"
  ],
  "data_classes": [
    "order-summary",
    "customer-authored-ticket"
  ],
  "output_schema": "refund-evidence-v2",
  "constraints": {
    "expires_at": "2026-08-12T12:10:00Z",
    "deadline_ms": 30000,
    "remaining_depth": 0,
    "max_tool_calls": 6,
    "max_side_effects": 0,
    "max_cost_usd": "0.08"
  },
  "cancellation_ref": "cancel_01K0",
  "policy_version": "delegation-policy-17",
  "parent_signature": "integrity-protected-value"
}

Put identifiers and constraints in the envelope, but leave out secrets and full source records. The child can resolve authorized references through ordinary product tools. Permission checks then stay close to the data, and the parent does not have to copy a broad context blob into another runtime.

Narrow by intersection, never by union

Calculate the child's effective authority as the intersection of all relevant limits:

child authority =
  current user authority
  INTERSECT parent effective authority
  INTERSECT child agent policy
  INTERSECT task purpose and resource set
  INTERSECT current workload and environment policy

If any required authority is absent, deny the delegation. Never merge the parent's grants with the child's service permissions. A union creates a confused deputy because the parent supplies the intent and the child contributes unrelated power.

An active OWASP contribution on agentic controls proposes intersecting user, agent, and workload authority. It also calls for aggregate limits across a delegation tree, approval objects bound to the approved action, and another authorization check when deferred work executes. The issue is a contribution proposal rather than a finalized standard. Its controls are still specific enough to test as product invariants.

Narrow context separately from tool authority

A child rarely needs every record its parent saw. Build its context from the declared purpose and data classes. Pass references only to the records, fields, and provenance needed for that subtask.

Keep four distinct lists:

1. resources the child may read;
2. fields or data classes it may receive;
3. tools and operations it may invoke;
4. fields allowed in its returned artifact.

These separate lists stop an authorized read from becoming an unauthorized output. A refund-evidence child, for example, may inspect an internal fraud flag and return manual_review_required: true. It may not pass the flag, model score, or rule details to the customer-facing parent.

Issue child-specific credentials

Do not forward the parent's bearer token. Mint or exchange a child-specific credential bound to:

• child task and agent identity;
• tenant and initiating user;
• destination audience;
• exact scopes and resources;
• expiry no later than the envelope;
• approved workload and environment;
• delegation ID and policy version.

WorkOS recommends distinct agent identities, scoped delegation, token exchange, communication trust, and traceability. TrueFoundry's authorization-propagation guide explains how inherited broad credentials, individually valid retrievals, and stale grants can break a workflow even when every service checks authorization.

Use the shortest relevant lifetime for credential expiry. If the user grant expires in five minutes and the child task allows ten, the child credential still expires in five. When the parent is cancelled, revoke or disable every descendant capability instead of waiting for each one to expire.

Treat delegation as a durable state machine

A remote child will not always return within one request. It may sit in a queue, ask for input, stream progress, fail, or finish after the parent process restarts.

The A2A Protocol specification handles agent discovery, task identity and context, asynchronous updates, cancellation, artifacts, authentication, and authorization as separate concerns. Those lifecycle primitives are useful when A2A fits the integration. The product's delegation envelope remains authoritative because protocol compatibility does not decide what the child may do.

Use explicit states:

proposed -> authorized -> issued -> running
running -> input-required | completed | failed | cancelled | expired
input-required -> authorized -> running

Store the delegation ID, root run, parent, child, actor, policy version, and timestamp on every transition. Transition handlers must be idempotent so retries cannot create a second child or apply the same result twice.

Before changing proposed to authorized, confirm the child identity, capability, destination, schema version, and remaining depth. Before authorized becomes issued, mint the child credential and register it under the cancellation handle. Before accepting completed, verify the artifact and the current root grant.

Propagate budgets across the entire tree

Fan-out makes per-agent limits easy to evade. A parent with a ten-call budget can create ten children with ten calls each unless every child reserves capacity from a root ledger.

Maintain one atomic budget ledger for the root run:

Use atomic compare-and-set or a serializable transaction when reserving budget. Two parallel children must not both observe the same remaining allowance.

When a child needs more capacity, send a typed request to the parent. The parent may narrow other reservations or ask the product for new approval. A child cannot enlarge its own envelope.

Propagate cancellation and revocation downward

Cancelling the visible run should stop its hidden work too. Implement cancellation as a tree operation:

1. mark the root cancellation handle requested;
2. stop issuing new children;
3. revoke active child credentials or broker grants;
4. send cancellation to every running child;
5. prevent queued and paused children from starting;
6. wait for bounded acknowledgements;
7. mark unresponsive children abandoned and deny their future results;
8. reconcile side effects that may already have occurred.

Cancellation does not undo a completed external action. Child tools still need idempotency keys, receipts, postcondition checks, and compensation where possible.

Role changes, tenant suspension, revoked approvals, deleted resources, and policy updates can invalidate authority without a user clicking cancel. Recheck mutable grants when work starts and again before consequential side effects. Otherwise, queued and long-running tasks can execute under an obsolete decision.

Verify child artifacts before synthesis

Authentication proves which child sent a response. It does not make the response trusted. Validate the artifact before the parent sees or summarizes it.

Check:

• response matches the declared output schema;
• artifact belongs to the expected delegation and child task;
• cited resource references were allowed by the envelope;
• returned fields fit the output data classes;
• execution receipts cover claimed tool actions;
• artifact arrived before expiry and cancellation;
• child release and policy versions match the issued task;
• no undeclared attachment, URL, executable content, or nested instruction is present.

Next, check the combination itself. Determine whether adding the artifact to the parent's current context creates a field, inference, or action outside the root grant. Field-level data policy and resource scopes may make this a deterministic check. Sensitive workflows can require a separate policy decision or human approval before synthesis.

Do not ask the model to judge whether its own combined context is authorized. The product must enforce output fields and data policy before model context is assembled.

Keep an attributable delegation graph

Disconnected logs make a delegation chain hard to reconstruct. Store a graph where each node is a task or agent execution, and each edge records the parent, child, envelope, credential reference, reservations, and state transitions.

A useful edge record contains:

{
  "delegation_id": "dlg_01K2",
  "root_run_id": "run_01K0",
  "parent_task_id": "task_01K1",
  "child_task_id": "task_01K2",
  "initiating_user": "user_108",
  "tenant_id": "tenant_42",
  "purpose": "collect evidence for refund eligibility",
  "authority_digest": "sha256:policy-input-digest",
  "context_manifest_ref": "ctx_01K2",
  "credential_ref": "grant_01K2",
  "reserved_budget_ref": "budget_01K2",
  "issued_at": "2026-08-12T12:09:20Z",
  "final_state": "completed",
  "artifact_ref": "artifact_01K2",
  "receipt_refs": ["receipt_771", "receipt_772"]
}

The graph should answer who initiated the work, which parent delegated it, what authority and context were granted, which child acted, which effects occurred, what output returned, and whether cancellation or policy changes arrived during execution. Do not log raw credentials or unrestricted customer records.

A practitioner project described in Hacker News as "Sudo for AI agents" proposes cryptographic delegation instead of distributing API keys. This is the author's project report, not proof of a universal design. It does show direct implementation interest in attributable, constrained delegation.

Handle delegation failures explicitly

Child unavailable or unsupported

Reject before credential issue if discovery cannot prove the expected identity, protocol, capability, and schema version. The parent may use a registered fallback agent only if the fallback is covered by the same or narrower policy. Do not select an arbitrary endpoint supplied by model output.

Partial completion

Return completed artifacts with their receipts and mark unfinished branches separately. The parent cannot describe the entire task as successful. Release unused reservations, keep a record of spent side effects, and choose recovery based on the root workflow.

Child requests broader access

This is a denied escalation, not an ordinary retry. Return the missing scope and business reason to trusted product code. A human or policy service may create a new envelope after checking current authority. Never edit an issued envelope in place.

Parent crashes

Reload the delegation graph, reconcile child status, and resume with the same task IDs and reservations. Do not create replacement children until the product proves that the originals did not start or can no longer report accepted results.

Child returns after cancellation

Keep the late artifact as incident evidence, but reject it from synthesis. Reconcile external receipts to determine whether a side effect needs compensation. A valid signature does not override a cancelled or expired root grant.

Test authorization propagation, not just each agent

Build fixtures that exercise the tree as a system:

1. Parent lacks a tool but child service owns it. Delegation must fail.
2. Parent may read two datasets separately but may not join them. Combined output must fail aggregation policy.
3. Child grant expires in a queue. Execution must reauthorize and fail closed.
4. User loses a role while the child waits for approval. Resume must fail.
5. Ten children race for the final budget unit. At most one reservation succeeds.
6. Parent cancellation arrives while grandchildren run. Every descendant stops or becomes unable to commit results.
7. Child tries undeclared re-delegation at depth zero. No credential is issued.
8. Child returns fields outside its output schema. Parent never receives them.
9. Child claims a write without an execution receipt. Completion remains unverified.
10. A result arrives from the wrong task, tenant, child release, or policy version. It is rejected.
11. Parent crashes after child issue. Recovery maps to the original task rather than duplicating work.
12. A child follows hostile instructions embedded in delegated context. Resource, tool, destination, and output controls still hold.

Add release gates:

• no child authority is broader than its parent or current user grant;
• root budget equals spent, reserved, and remaining amounts across all descendants;
• cancellation reaches every active descendant within the declared bound;
• no expired or revoked task can commit an artifact;
• every accepted artifact maps to one envelope and required receipts;
• every synthesis passes output and aggregation policy;
• every edge in the graph maps to the initiating tenant, user, root run, and immutable release.

Start with one bounded handoff

Choose one read-only subtask with a clear schema and no recursive delegation. Build the root grant, envelope, child credential, budget reservation, cancellation path, artifact validation, and graph record. Run the negative suite before adding side effects.

Avoid starting with an open-ended supervisor that discovers arbitrary agents. Register the child identity, capability, schema, and destination in trusted product configuration. Add a second child type only after the first handoff preserves authority through cancellation, expiry, recovery, and synthesis. Increase delegation depth after aggregate budgets and descendant revocation work under concurrency.

Pick one existing parent workflow and write down its root grant. Then express one child task whose permissions and output are strict subsets. If that requires free-form prose or a copied user token, the product is not ready for safe AI agent delegation.

References

• Authorization Propagation in Multi-Agent AI Systems supports the workflow-level treatment of transitive delegation, aggregation inference, and temporal validity.
• Authenticated Delegation and Authorized AI Agents supports authenticated, authorized, and auditable delegation from a human principal to separately identified agents.
• A2A Protocol specification supports remote agent discovery, task identity and context, asynchronous updates, cancellation, artifacts, authentication, and authorization as distinct concerns.
• TrueFoundry: Authorization Propagation, Explained supports the exact-fit failure modes of authority widening, unauthorized synthesis, and grants that become stale during long workflows.
• WorkOS: How to secure AI agent delegation and multi-agent communication supports distinct agent identities, scoped delegation, token exchange, secure communication, and end-to-end traceability.
• OWASP contribution: controls for confused deputies and cross-fleet limits supports the proposed controls for authority intersection, aggregate action limits, approval binding, and execution-time reauthorization.
• Hacker News: Sudo for AI agents provides practitioner project evidence for cryptographically constrained delegation instead of distributing reusable API keys.