Agent Auth Across Boundaries: A Practical Guide (2026)

Single-agent auth is straightforward: the user authenticates to the agent; the agent acts as the user. Multi-agent breaks the symmetry. When agent A delegates to agent B, who is B running as? The user? The agent? A service identity with the user as a claim? Each answer leaks something different in production, and there is no obviously-correct default.

This guide covers the three identity shapes, the four scoping decisions, and the leak modes you only see after launch. Chapter 5 of A2A in Production is the long version.

The three identity shapes

1. Specialist runs as the user

The user's token (or a derived per-call token) propagates through every hop. The specialist authenticates upstream as the user. Audit trails show user actions; rate limits hit the user; permission models look exactly like single-agent.

Strengths: simple mental model; existing audit and rate-limiting infrastructure works.

Leak modes: the user has permissions they didn't expect to delegate (the agent can do everything the user can do, not what they asked it to do). Token scope is the only protection, and most user tokens are not scoped per-action.

2. Specialist runs as itself with a user-context claim

The specialist has its own service identity. Each call includes a claim asserting "this is being done on behalf of user X." Upstream APIs that understand the pattern apply authorization based on the user claim; ones that don't see the specialist's identity.

Strengths: limits blast radius; supports specialist-specific permissions; audit trail distinguishes agent from user.

Leak modes: most upstream APIs don't understand the user-context claim. They authorize the specialist; you've effectively granted the specialist all the user's permissions across those APIs.

3. Specialist runs as a service principal with no user link

The specialist authenticates upstream as itself. The user isn't part of the upstream call. Useful when the user has no upstream account and the specialist is acting "for the system" rather than "for the user."

Strengths: cleanest separation between agent and user identity.

Leak modes: zero audit trail tying user actions to upstream operations. Per-user rate limiting impossible. Cross-tenant scoping has to be entirely in your application layer because upstream doesn't see it.

The four scoping decisions

Independent of identity shape, you make four scoping calls:

1. Per-action token scope. Does the token agent A gives to agent B grant exactly the next action, or does it grant a class of actions? Tighter is safer, slower to develop.
2. Time bounding. When does B's token expire? Per-call is safest; per-session is most ergonomic.
3. Audience binding. Can B re-use the token to call C, or is it specifically bound to B? Binding prevents replay; lack of binding enables convenient composition.
4. Revocation propagation. When the user revokes their session, does that propagate to in-flight agent operations? Hard to do correctly; often skipped.

OIDC end-to-end

The cleanest pattern when you control all the agents: OIDC at every boundary. The user authenticates once; the resulting ID token includes claims; each agent verifies the token, may exchange it for a more-scoped token, passes it to the next hop.

Hard parts: token-exchange infrastructure (most orgs don't have it); scope-granularity decisions (every team wants different ones); the gap between the OIDC standard and what each upstream API actually supports.

Service-to-service auth

Separate from user identity, the agents themselves need to authenticate to each other. mTLS, signed JWTs, network policies -- the same toolkit you'd use for any microservice mesh. The choice is mostly determined by what your platform supports.

Leak modes

• The over-privileged specialist. Specialist B has the user's full token; the user only asked it to do one thing; B's prompt injection or bug exposes everything else the user can do upstream.
• The unsigned hand-off. Agent A tells agent B "this is for user X"; B trusts the claim without verifying. A compromised A can impersonate any user to B.
• The token-replay across audiences. Agent B's token wasn't bound to a specific audience; B uses it to call C; the user's permissions on C are now in B's reach.
• The orphaned session. The user logs out; in-flight agent work continues with cached tokens; actions appear in the audit trail after the user thinks they're gone.

Want the full chapter?

A2A in Production Chapter 5 is the auth chapter. It covers the three identity shapes in depth with worked examples, the four scoping decisions, OIDC end-to-end with the token-exchange details, the leak modes with concrete mitigations, and the "you don't know what your upstream supports" reality that constrains every decision.

Published by Yaw Labs.

Related

• A2A in Production -- the book.
• Multi-Agent Systems: A Practical Guide
• Agent Orchestration
• Federated Memory
• MCP Server Auth (companion volume)