How to Secure Cross-Agent Delegation

How to Secure Cross-Agent Delegation

Secure cross-agent delegation requires more than authenticated transport. The system must preserve who asked, which agent is acting, what outcome was authorized, which downstream service may be reached, what data may be disclosed, how long the authority lasts, and what happens when the task fails or cannot be undone.

The central rule is simple: do not transfer the user's entire authority merely because one agent needs help from another.

A legitimate request can still become an authority escalation

Consider a shopping agent that asks a supplier agent to replace an item and schedule installation. The user may have authorized a comparison, not a purchase. The shopping agent may have access to an account token that can edit addresses, view past orders, and spend far beyond the current task.

If that token is copied to the supplier agent, a normal delegation has become an authority expansion. If the supplier agent then delegates again, the token may cross another trust boundary the user never saw.

A2A 1.0 provides messages, tasks, authorization-required state, security declarations, and task updates. Those are useful control points. The application still has to decide who may do what.

flowchart LR
    U["User or originating workload"] -->|"Intent and policy"| D["Delegating agent"]
    D -->|"Bounded task, minimal data"| R["Receiving agent"]
    D -->|"Request narrow token"| I["Identity and policy service"]
    I -->|"Audience, scope, actor, expiry"| R
    R -->|"Artifact or proposed action"| V["Validation and approval"]
    V -->|"Approved side effect"| X["Target system"]
    V -->|"Reject, cancel, or compensate"| C["Recovery path"]

Name every principal and target

Before connecting agents, identify the user or originating workload, the delegating agent, the receiving agent, the authorization service, and every target resource.

Preserve the difference between the subject and the actor. The user may be the subject whose rights are involved. The delegating or receiving service is an actor using some portion of those rights.

OAuth 2.0 Token Exchange defines delegation and impersonation concepts and can represent subject and actor information. It can also request tokens for a resource, audience, and scope. The standard does not decide which exchanges your organization should allow.

If the audit trail cannot answer who acted for whom, at which resource, under which policy, the design is not ready for consequential delegation.

Bind authorization to the actual task

The authorization decision should describe the intended action, target, data, amount or other material limit, and expiration.

A user approving "find a delivery time" should not authorize "change my address, buy the item, and schedule any contractor." A manager approving a 20 percent discount should not create an open-ended discount credential for future customers.

Use policy before execution, not a prompt after the agent has already committed the effect. For material actions, present the exact proposal a person or policy engine will approve.

Issue a narrow downstream credential

Do not put a broad bearer token in an A2A Message, Part, Artifact, task metadata field, log, or model context.

Prefer a new short-lived credential issued for the receiving agent or target resource. Bind it to the intended audience or resource, minimum scope, actor, and task lifetime. OAuth 2.0 Resource Indicators defines a way to request a token for a specific protected resource. Avoid refresh authority unless the use case explicitly requires offline access and policy permits it.

The A2A specification recommends out-of-band credential fulfillment when a task enters the authorization-required state. It warns that in-band credential exchange can expose a credential to each agent in a delegation chain.

When token exchange is unavailable, use a brokered call, capability handle, signed one-time request, approval service, or other architecture that prevents raw user authority from spreading. The exact pattern depends on the identity system and threat model.

Minimize the data, not just the token

An agent can have narrow API scope and still receive excessive personal, commercial, or confidential data.

Construct a task-specific payload. Remove unrelated conversation history, internal prompts, hidden chain-of-thought, credentials, customer records, and identifiers. Replace direct identifiers with opaque references where the receiving agent does not need the original value.

Validate every returned file and structured object before it reaches another model, tool, browser, or employee. Remote content can carry instructions, malformed data, unexpected links, oversized payloads, or content intended to influence later agents.

Isolate tenants, tasks, and execution

The receiving service must authorize every task and task lookup against the authenticated client, tenant, and resource. An unguessable task identifier is not authorization.

Keep task state, artifacts, credentials, logs, caches, and callbacks separated by tenant. Enforce size, complexity, concurrency, rate, and cost limits. Run risky parsing or execution in an isolated environment with bounded network and filesystem access.

Where push notifications are used, verify the sender and expected task, process duplicate delivery safely, prevent replay, rate-limit the endpoint, and avoid revealing whether an unauthorized task identifier exists.

Design replay and retries before timeouts happen

Distributed requests fail ambiguously. A client can time out after the remote side committed an action but before the response arrived.

Retrying a read is different from retrying a purchase, deletion, email, or booking. Consequential operations need idempotency keys or a reconciliation query that can determine whether the effect already occurred.

Record the task identifier, request digest, policy decision, attempt, remote status, artifact digest, external effect identifier, and final disposition. Do not let a model decide that "try again" is safe from an error string alone.

Separate cancellation from compensation

A2A allows a client to request task cancellation, but cancellation is not guaranteed. Work may already be complete or beyond a cancelable point.

Define what stopping means for each stage. Before an external commit, cancellation may halt work. After a commit, recovery may require voiding a transaction, restoring a record, sending a correction, refunding a charge, or escalating to a person.

Compensating actions need their own authority, validation, and audit. An automatic rollback can be as consequential as the original action.

Make human review specific and usable

Human review should appear where it changes risk, not as a decorative step at the end.

Show the person the proposed action, target, material data, cost or commitment, source, uncertainty, and available alternatives. Let the person approve, edit, reject, or defer. Bind the resulting approval to the displayed proposal and expire it when the proposal changes.

Avoid asking a person to approve raw model reasoning or a vague request to "continue." The review surface should describe the business decision.

Exercise the incident path

Before production, test a compromised card, wrong tenant, expired token, excessive scope, replayed request, duplicate callback, injected artifact, invalid schema, unbounded task, missed cancellation, unavailable agent, ambiguous timeout, and irreversible side effect.

Confirm that the system can revoke credentials, quarantine an agent, stop new delegations, preserve evidence, locate affected tasks, notify the right owner, and execute a reviewed recovery path.

Passing the happy path proves very little about delegation security.

The production gate

A cross-agent task is ready only when the authority can be explained without relying on the model's discretion. The receiving agent should get the minimum data and power needed for one outcome. Every consequential effect should be attributable, bounded, observable, and recoverable to the extent the underlying system permits.

This guide is not a security certification or a complete identity design. It requires an environment-specific threat model, architecture review, application testing, and incident plan before production use.

This article was developed with AI assistance and reviewed against A2A 1.0, OAuth 2.0 Token Exchange, and the episode evidence linked above. Dalton Anderson is responsible for the final editorial judgment.