Agent-to-agent chains

Why does another agent change the access problem?

A chain starts when one agent delegates work to another, which may call further agents or tools. The initial permission decision cannot answer every downstream question.

The existing pattern describes A2A as the protocol for discovering and calling agents. Treat communication support and authorization enforcement as separate requirements during procurement.

A receiving agent needs enough trusted context to distinguish its immediate caller from the person behind the task. Otherwise, delegation becomes indistinguishable from unrelated service traffic.

As a design recommendation, narrow authority at each handoff rather than copying the original token. A downstream assignment should not create broader access than its parent.

What context should each handoff preserve?

Require the immediate caller, receiving agent, original person when present, intended tool, requested action and task purpose. Give autonomous chains an accountable owner instead of inventing a user.

Use a shared task identifier to connect the records. Keep individual call identifiers too, so retries and parallel branches remain distinguishable during investigation.

Treat purpose as policy input that needs validation, not permission simply because an agent supplied it. Ask vendors how they prevent callers from rewriting delegation context.

Token exchange can replace a caller token with a narrower token aimed at the next recipient. Do not assume every exchange automatically narrows scope or preserves every ancestor.

Require a demonstration of audience restriction, expiry and downstream rejection of inappropriate tokens. These are evaluation requirements, not claims that every listed product implements complete chain tracking.

How would a hypothetical chain work?

Consider a hypothetical procurement assistant helping an employee compare suppliers. It delegates research to one agent and purchase preparation to another.

The research agent receives permission to read approved supplier records. It cannot create purchase orders merely because the employee has that permission.

The purchase agent receives the selected supplier and proposed order details. Its gateway checks the requested tool action before allowing any write.

If policy requires approval, the order waits for a named person. Approval should authorize that proposal, not every later purchase within the conversation.

Both branches retain the task identifier while recording distinct callers and decisions. Investigators can then reconstruct how research became an order without treating every call as equivalent.

This example is a recommended design, not a documented deployment. Test each boundary with your actual agents, tools and authorization server.

Which documented products cover parts of the chain?

NewCore documents a gateway that identifies the agent and person behind every tool call. It also documents task-scoped access and per-agent revocation.

Its governance material describes allow, ask and deny outcomes, with tool calls, sessions and approvals in one audit trail. Those features fit downstream enforcement and evidence requirements.

Silverfort documents an MCP Gateway that evaluates each tool call before execution. Its outcomes include approve, block or step up to a human.

Aembit documents secretless credential exchange and an MCP Identity Gateway hosted on a customer VM. Its listed standards include A2A, MCP, SPIFFE and Cross App Access.

Aembit also describes a Blended Identity combining agent and human context. Standards support alone does not establish arbitrary delegation depth or end-to-end ancestry preservation.

Descope documents short-lived scoped tokens and per-tool authorization with Deny policies. Its documented authentication options include SPIFFE SVIDs, mTLS and DPoP.

Use these products as candidates for specific controls, not interchangeable guarantees of complete multi-agent governance. Require evidence for the chain behavior your application actually needs.

What should the implementation sequence be?

First, map one real workflow from the initiating request to every downstream tool. Record identities, owners, token audiences, permissions and enforcement points at each hop.

Second, replace shared credentials and forwarded user tokens where feasible. Require each agent to authenticate separately and request only the authority needed for its assignment.

Third, enforce policy at downstream tool boundaries, not just the first agent. Check whether direct API routes can bypass the intended gateway.

Fourth, connect call records with the shared task identifier. Preserve the policy outcome and approval reference beside each consequential action.

Fifth, test revoked agents, expired tokens, denied tools and unavailable policy services. Define whether work stops, retries or requires human intervention before production rollout.

What should vendors demonstrate before selection?

Ask vendors to trace one request across two agents and a tool. Require them to identify the original person and immediate caller independently.

Ask which components validate token audience and scope, and which component performs exchange. Request a failed demonstration where a downstream agent attempts a broader action.

Recommend limits on delegation depth, unexpected branching and repeated calls. Ask whether these limits are native controls or application responsibilities.

Require an export showing task linkage, individual decisions and revocation effects. A dashboard showing several agent identities is not sufficient evidence of a connected chain.

Which pitfalls deserve explicit tests?

A gateway cannot enforce calls that bypass it. Inventory alternate endpoints and retained credentials before assuming every tool action receives the same checks.

Do not equate successful authentication with permission to delegate. Do not assume the final agent can inherit every privilege available to the original person.

Retries can obscure whether an action already executed. Recommend recording execution outcomes separately from authorization decisions, especially for purchases, messages and production changes.

Questions buyers ask