An Agent's Authority Should Narrow at Every Handoff

When one agent delegates work to another, the second agent should receive only the authority required for that task. The downstream grant should identify the initiating principal, the current actor, the target resource, the allowed operation, and the conditions under which the grant expires or can be revoked.

TL;DR — authority at each hop

Preserve the original principal. Authenticate each new actor. Limit every child grant to a subset of its parent’s audience, operations, resources, and lifetime. Let the resource server enforce the decision.

This is a narrower problem than agent identity. Identity answers which service or agent presented a credential. Delegation answers on whose behalf it acts and what that actor may do. A valid identity does not prove that a valid principal authorized the requested action.

The practical design rule is monotonic authority: each handoff must preserve the original principal and may reduce the grant’s scope, lifetime, audience, or budget. It must not silently add rights that were absent from the parent grant. This is an implementation recommendation; the standards below provide useful mechanisms, but they do not automatically enforce this rule for every agent workflow.

Communication does not grant authority

Agent protocols make it easier for independently built systems to exchange task requests and results. That connectivity does not decide whether the receiver may access a record, call a tool, send a message, or spend money.

The Agent2Agent (A2A) specification requires a server to authenticate each request and then authorize it based on the authenticated identity and its own policy. An Agent Card describes an agent’s identity, capabilities, skills, and authentication requirements, but discovery does not establish that the discovered agent is authorized for a particular task.

OAuth 2.0 Token Exchange (RFC 8693) defines a way to exchange one security token for another. It distinguishes delegation from impersonation and describes a subject token, an actor token, and an actor claim that can represent delegation. The RFC deliberately leaves the deployment trust model and detailed token security characteristics to implementation policy. Its nested actor claim can preserve prior actors as history, but those actors are informational for access control; consumers base decisions on top-level token claims and the current actor. The actor chain alone does not prove that a child grant was narrower. Check the issued token’s effective scope and audience, or a separate grant record linked to its parent. Token exchange is a mechanism, not a complete delegation policy.

Keep principal, actor, and permission distinct

A chain can contain several identities with different roles:

• Principal: the user or organization that owns the original intent.
• Delegator: the agent or service that hands off a bounded task.
• Delegatee: the downstream agent that accepts the task.
• Resource server: the service that decides whether a requested operation is allowed.

For example, a purchasing assistant may ask a research agent to compare vendors. The research agent may read approved public material and return citations. That handoff does not authorize it to contact vendors, edit the purchasing system, or approve a purchase. The parent’s identity and the child’s identity are both relevant; neither one alone defines the child’s permission.

Represent each grant with fields that an authorization service can evaluate:

A signed credential can protect integrity and support verification. It does not prove that its issuer had the right to make the grant. The verifier still needs an issuer trust rule and an authorization policy.

Check attenuation as a policy invariant

For each child grant, compare it with the parent grant across the dimensions that matter to the protected resource. At minimum, require:

1. The same principal remains visible throughout the chain.
2. The new actor is authenticated independently.
3. The child audience is no broader than the parent audience.
4. The child actions and data scope are subsets of the parent’s scope.
5. The child expiry does not outlive the parent grant.
6. A child cannot delegate again unless the parent explicitly permits it.
7. The resource server evaluates current policy before each consequential operation.

The subset check must match the meaning of the fields. Two different resource names may refer to the same protected data. A wildcard scope may be broader than a list of named actions. A shorter token lifetime does not reduce the authority of a dangerous operation during that lifetime. Policy designers should define these comparisons as code and review their edge cases.

NIST’s guide to attribute-based access control (ABAC) describes authorization decisions using attributes of the subject, object, requested operation, and sometimes the environment. That model fits agent delegation because the decision depends on more than a role name. A policy can consider the principal, actor, record, operation, organization, task context, and grant freshness together.

Example: a two-hop research request

A finance manager authorizes an assistant to compare renewal prices. The assistant delegates source collection to a research agent. The research agent invokes a web search service.

The authorization chain should preserve the manager’s identity as principal, the assistant as delegator, the research agent as current actor, and the search service as audience. The child grant should allow only the source collection needed for the comparison. It should not carry an account credential that allows the research agent to update the renewal, contact a supplier, or approve the expense.

The last denial should occur at the purchasing resource server, even if an upstream agent mistakenly forwards a broader credential. A chat message that says “do not approve” is not a substitute for a server-side check.

Where chains commonly fail

Identity substitution: the downstream service sees a trusted platform credential but loses the original principal. A later audit cannot distinguish user intent from an agent’s own decision.

Scope laundering: an intermediary exchanges a narrow token for a broad service credential, then treats the broad credential as delegated authority. The service credential must not erase the task’s original limits.

Audience confusion: a credential intended for one service is accepted by another. Bind tokens to the resource or audience that should consume them.

Over-delegation: the parent grants a child a broad role because the system cannot express a narrow task. Improve the authorization model instead of passing the parent’s full credential.

Stale authority: the parent’s task is canceled or expires while a child token remains valid. Use short lifetimes and a revocation path for consequential work.

Unbounded recursion: a child may delegate again, creating a longer chain than any reviewer expects. Require explicit delegation depth or prohibit onward delegation by default.

Credential propagation: passing a bearer token through each agent exposes it to every intermediary. Prefer obtaining a resource-specific token for the next actor and service. Where a credential must cross a boundary, define its holder, audience, scope, and lifetime.

Measure attenuation across the chain

Track whether each handoff preserves the principal, keeps the requested audience inside the parent grant, and rejects an added action or broader resource. A useful metric is the rate of invalid child grants rejected by policy tests; a separate metric records missing actor or parent-grant data.

Set a threshold before rollout: test cases that request wider scope must have zero accepted grants. Set the allowed revocation delay according to the protected action and document the reason; no universal duration fits every workflow.

The implementation should compare child attributes when issuing a token and again at the resource server. That second check contains damage if an intermediary forwards the wrong credential. The tradeoff is policy latency and more frequent token renewal for long tasks. If the policy service cannot validate a consequential action, the safe rollback is to deny that action and return a bounded failure, not to fall back to the parent’s broader credential.

A handoff acceptance test

A builder can test the policy without trusting agent explanations:

1. Create a parent grant with one principal, task, resource, and action.
2. Request a child grant with a smaller scope and a shorter lifetime.
3. Confirm the authorization service issues only the narrower grant.
4. Request a child grant with an added action, broader audience, or longer expiry.
5. Confirm the authorization service rejects the broader request.
6. Replay a valid child token at a different resource server.
7. Confirm the server rejects the wrong audience.
8. Revoke the parent grant and attempt the child action again.
9. Confirm that the downstream action stops within the documented revocation window.
10. Inspect the audit record and reconstruct principal, delegator, delegatee, resource, action, and decision.

Run the test at each boundary that issues or consumes authority. A correct policy at the first exchange does not protect a later service that ignores the actor chain.

What the protocols provide—and what they leave to you

A2A provides an interoperability and task model and relies on standard web security practices for authentication and authorization. RFC 8693 provides token-exchange parameters and delegation semantics. NIST ABAC guidance helps structure policy inputs. None chooses your business policy, proves that the principal approved every downstream action, or defines the acceptable blast radius for your workflow.

Armalo’s Agent Trust Network works on agent trust and accountability. This article makes a narrower engineering point: trust signals and identity records cannot replace resource-side authorization. A receiving service must decide whether this actor may perform this action for this principal now.

Compare grants by meaning, not by string

A literal string comparison is not enough to prove that a child grant is narrower. An action named “manage” may include more operations than a list of explicit verbs. Two resource identifiers may resolve to the same account. A parent token may carry a wildcard audience while the child uses a named service. The policy must understand those relationships before it compares them.

For each protected resource, define canonical actions and resource identifiers. Then define which child attributes must be equal, which may be narrowed, and which cannot be delegated. Keep “not specified” distinct from “unrestricted”; otherwise an omitted field can accidentally mean broader access. Reject ambiguous requests when the resource owner cannot establish their scope.

A practical policy table can record the parent value, requested child value, comparison rule, and result for each dimension. Review the rules with the team that owns the resource, because an identity platform cannot infer the business meaning of “approve,” “send,” or “read all records.”

Design revocation for work already in flight

Revoking a parent token does not always stop a child operation already accepted by a service. Short-lived tokens reduce the window, while revocation events and server-side policy checks can narrow it further. A system should state which control applies to queued work, active streams, scheduled callbacks, and retries.

For an asynchronous task, bind the callback to the original task and expected receiver. On completion, check whether the grant is still valid before accepting the result or allowing another side effect. Make retries safe to identify so a delayed callback cannot repeat an irreversible operation after the parent task ended.

The acceptable revocation delay depends on consequence. A research query may tolerate a different delay than a production write or payment. Record the chosen threshold, how it is measured, and what the service does when it cannot reach the policy owner. If a high-impact action depends on fresh authorization, failing closed may delay work; falling back to a broader credential can exceed the user’s grant.

Separate token validity from task validity

A token can be cryptographically valid while the task that justified it has been canceled, completed, or superseded. A long-running workflow therefore needs a task-state check as well as token verification. The resource server should know enough to reject a token whose task is no longer active or whose parent delegation has expired.

That link also helps with disputes. A reviewer can reconstruct the principal, each actor, the resource, the requested action, the policy decision, and the task state at the time. The resulting record proves what the service evaluated; it does not prove that the underlying business request was wise or that the returned work was correct.

These limits are why identity, token exchange, authorization, and work acceptance should remain separate decisions. Combining them into a single “trusted agent” flag makes delegation easier to explain and harder to audit.

FAQ

Does OAuth Token Exchange guarantee that each child grant is narrower?

No. RFC 8693 defines token-exchange parameters and delegation semantics. The deployment must define and enforce its own trust and attenuation policy.

Does an A2A Agent Card authorize a task?

No. An Agent Card describes an agent and its interaction requirements. The receiving server still makes an authorization decision for the request.

Should every agent be allowed to delegate again?

No. Onward delegation should require an explicit parent permission and a policy that limits chain depth, scope, audience, and expiry.

Specifications and guidance

• OAuth Working Group, RFC 8693: OAuth 2.0 Token Exchange.
• Agent2Agent Protocol, Authentication and authorization in the specification.
• National Institute of Standards and Technology, SP 800-162: Guide to Attribute Based Access Control.