In December 2025, in an incident that the post-mortem later named the "Decagon-Sierra confusion," a customer-support agent built on Decagon called a returns-management agent built on Sierra. The call was authenticated. The call was logged. The call was, by every observable metric, legitimate. The Sierra agent issued a refund for $1,847. The problem: the Decagon agent was acting as the customer, not on behalf of the customer. Identity had collapsed across the A2A hop. The customer's account had not actually requested the refund; a chained agent had impersonated them. This lesson is about the auth posture that prevents that incident from ever happening: mTLS for tenant-to-tenant trust, OAuth 2.0 client-credentials for cross-vendor SaaS, signed Agent Cards with cryptographic domain verification, and the principal-on-behalf-of pattern as the only safe way to inherit a human user's permissions across an A2A hop.

The Decagon-Sierra Confusion: A 2025 Failure Mode Named

The December 2025 incident, anonymized in the post-mortem, walked like this:

1. A customer messaged an e-commerce site's chat. The site's frontend authenticated the customer with a session cookie and routed the chat to a Decagon-built customer-service agent.
2. The Decagon agent identified the customer's account, looked up the recent order, and determined the customer was eligible for a return.
3. The Decagon agent invoked a Sierra-built returns-processing agent via A2A. The A2A call carried OAuth client-credentials authentication — the Decagon agent's own service identity, not the customer's identity.
4. The Sierra agent received the call, validated the OAuth token (legitimate Decagon service), and processed a refund "as the customer."
5. The audit trail showed: the Decagon service called the Sierra service, the Sierra service issued the refund. The customer's account showed a refund the customer had not actually requested in that exact form.

The vulnerability was not in either vendor's code. The vulnerability was in the identity model. The Decagon agent had been given broad permission to invoke the Sierra agent. There was no representation, at the protocol level, of the human user on whose behalf the chain was acting. The downstream agent had no way to verify "this refund is being requested by the actual account holder, not just by an upstream agent that decided to ask for one."

This failure mode has a name in 2026: agent impersonation. The Decagon-Sierra confusion is the canonical example. The lesson the industry took from it is that A2A identity must answer three questions for every hop, not one:

• Who is the calling agent? (Service identity. mTLS or OAuth client-credentials.)
• Who is the caller's operator? (Organizational identity. Signed Agent Card with domain-bound key.)
• Who is the human principal on whose behalf this chain is acting, if any? (User identity. Principal-on-behalf-of token.)

A 2024 auth posture answered only the first question. A 2026 production posture answers all three.

Three Auth Postures for Three Relationships

Cross-agent calls fall into three relationship categories. Each has a default auth posture in the 2026 A2A operator playbook.

1. Tenant-to-tenant (same org, different teams, different runtimes)

Two agents owned by your own organization, deployed on different runtimes or clouds, talking to each other. An ADK orchestrator on GCP calling a CrewAI specialist on AWS. A LangGraph workflow on Kubernetes calling a Semantic Kernel agent on Azure Functions.

Default posture: mTLS plus a private trust anchor. Both sides present X.509 certificates signed by your organization's internal certificate authority. The trust anchor is the org's root CA, distributed via your service mesh (Istio, Linkerd) or directly in deployment configs. No tokens to rotate; no client-credentials grant flows. The certs themselves are the identity, and your internal PKI handles rotation.

Why mTLS for this case: it is the cheapest and lowest-latency option when both sides are inside your trust boundary. It scales to thousands of services. And the failure mode is observable — a cert mismatch is a clean handshake failure, not a silent authorization bypass.

2. Cross-org (different operators, persistent relationship)

Two agents owned by different organizations with an ongoing business relationship. Your e-commerce orchestrator calling a partner's KYC agent. Your CRM agent calling a SaaS vendor's enrichment agent. Your research platform calling a contracted data-provider's specialist.

Default posture: OAuth 2.0 client-credentials plus a signed Agent Card with public-key trust anchor. The calling agent holds a client ID and a client secret (or a private key for client-credentials with key authentication, the JWT-based variant). It mints a short-lived bearer token at the token endpoint and presents it on every A2A call. The receiving agent validates the token against the issuer's JWKS endpoint. The Agent Card is signed with the operator's domain-bound key, and the calling side validates the signature against a trust anchor — typically the operator's public key fetched via DNSSEC-protected DNS, or a Web PKI certificate chain.

This is the most common cross-org posture in 2026 because OAuth's tooling is mature, the secret rotation story is well-understood, and bearer tokens compose cleanly with downstream service-to-service hops.

3. Cross-vendor SaaS (different operators, marketplace or open relationship)

One-time or low-volume invocations across organizational boundaries. Your agent invokes a specialist found on a public agent marketplace. Your workflow opportunistically calls a third-party agent for a one-off task.

Default posture: OAuth 2.0 client-credentials at the marketplace level, with the marketplace as the identity broker. The marketplace authenticates you (the calling org) and brokers access to the specialist (the receiving org). You don't have a direct OAuth relationship with the specialist; you have a relationship with the marketplace, which guarantees identity propagation. The Agent Card is signed by the marketplace's signing authority, which has verified the operator's domain control.

This is the emerging 2026 pattern. Marketplaces — Agent Garden (Google), AgentHub (Microsoft), the OpenAgents Registry (community) — act as identity brokers for agent-to-agent calls in the same way Stripe acts as a payment broker. You trust the marketplace's KYC; the marketplace trusts the operators.

The auth posture follows the relationship, not the technology. mTLS for inside-org trust. OAuth client-credentials for ongoing cross-org. Marketplace-brokered identity for opportunistic cross-vendor. Pick the posture for the relationship; do not paint one tool over every case.

Signed Agent Cards and Domain Binding

The signed Agent Card is the foundation that makes all three postures trustworthy. Without the signature, you have authentication (the OAuth token or mTLS cert is valid) but not identity verification (the agent claiming to be the partner's KYC service might be a clever impostor that happens to have a valid OAuth token issued by an attacker-controlled issuer).

A2A v1.2 specifies the signed Agent Card. The signature is over the entire card document. The signing key is bound to the operator's domain via one of three mechanisms:

• DNS-anchored key. The operator publishes the public key at a DNSSEC-protected DNS record (typically a TXT record under _agent-key.example.com). Validators fetch the key over DNSSEC-validating DNS. This is the most common 2026 mechanism for sophisticated operators.
• Web PKI binding. The signing key is rooted in a certificate chain to a Web PKI CA (the same CA system that signs HTTPS certificates). The Agent Card's signature includes the certificate chain; the validator walks the chain to a trusted root. Easier to set up; depends on Web PKI semantics being appropriate for your relationship.
• Marketplace-attested. A marketplace (Agent Garden, AgentHub, OpenAgents Registry) signs a meta-card that asserts the operator's domain control. The operator's Agent Card includes a marketplace attestation. Validators trust the marketplace's signing authority transitively.

A real example from a Q1 2026 deployment: a financial-services org's KYC agent uses DNS-anchored keys. The TXT record at _agent-key.kyc.partner.com contains the public key fingerprint. The Agent Card at /.well-known/agent-card on the partner's domain is signed with the corresponding private key. The calling agent's A2A client fetches the card, fetches the public key over DNSSEC, verifies the signature, and confirms "this card is genuinely from partner.com." Without DNS-anchored keys, an attacker who briefly compromised the partner's web server could publish a malicious card and route real traffic to themselves. With DNS-anchored keys, the attacker would also need to compromise the partner's DNS — a much higher bar.

The Principal-on-Behalf-of Pattern

The Decagon-Sierra incident's root cause was the absence of principal-on-behalf-of identity. The Decagon agent had its own service identity, fully authenticated. What was missing was a representation, in the A2A call, of the human user whose request initiated the chain. The Sierra agent had no way to enforce "this refund must be requested by the actual account holder."

The 2026 fix is the principal-on-behalf-of pattern, modeled on the OAuth 2.0 Token Exchange specification (RFC 8693) and adopted as the canonical A2A principal-propagation mechanism in v1.2. The pattern, abbreviated POBO in deployment configs and documentation, works like this:

1. The customer authenticates at the frontend; a short-lived bearer token (id_token or equivalent) is issued representing the human principal.
2. The frontend invokes the first agent (Decagon, in the failure story) and passes the principal token alongside the agent's own service authentication.
3. When the first agent invokes a downstream agent (Sierra, in the story), it exchanges the principal token at its own identity provider for a "delegation token" — a JWT carrying claims that say: "this token represents principal [email protected] delegated by service decagon-agent-prod for operation create_refund, with TTL 5 minutes."
4. The downstream agent (Sierra) validates both the delegation token (proving the principal authorized the operation) and the calling service's identity (proving Decagon is who they say they are).
5. The downstream agent enforces authorization against the principal's permissions, not the calling service's permissions. The refund is authorized only if the customer's account is allowed to request that refund.

The delegation token includes:

• sub — the human principal (e.g., [email protected])
• act — the acting service (the calling agent, e.g., decagon-agent-prod)
• aud — the intended audience (the downstream agent, e.g., sierra-returns-agent)
• scope — the constrained operations (e.g., read:order create_refund)
• exp — short expiry (5-15 minutes is the 2026 norm)
• act_chain — if there are multiple hops, the full chain of acting services for audit

The downstream agent validates the token at its identity provider, reads the principal claim, and authorizes against the principal's actual permissions in the system. The acting-service chain is preserved for audit. The refund is authorized if and only if the principal would be authorized in a direct call.

The 2026 principal-on-behalf-of pattern is what would have prevented the Decagon-Sierra confusion. With POBO, the Sierra agent would have seen "this refund is being requested by Decagon on behalf of [email protected]" and validated against the customer's actual account permissions. The customer's account permissions did not include "issue an arbitrary refund the customer never asked for." The check would have failed; the refund would not have been issued; the incident would not have happened.

Implementing POBO in the 2026 Stack

The canonical implementation uses three components:

Identity provider with token exchange (RFC 8693)

Auth0, Okta, Azure AD, AWS Cognito, and Google Cloud Identity all support RFC 8693 token exchange as of 2026. You configure the calling agent's service identity at the IdP. When the agent needs to invoke a downstream peer on behalf of a user, it makes an OAuth token-exchange request to the IdP carrying the user's principal token plus its own service credentials. The IdP issues a delegation token with the principal as subject, the service as actor, and the requested scope.

A2A client library with POBO support

The 2026 native-A2A framework wrappers (Google ADK, LangGraph, CrewAI, LlamaIndex, Semantic Kernel, AutoGen) ship POBO support out of the box. In ADK, you pass a principal argument when invoking an A2A peer; the framework handles the token exchange transparently. In LangGraph, the A2APeer node accepts a principal-context object that gets propagated. CrewAI's A2A client accepts a delegated_principal parameter on each call.

A2A server with delegation-aware authorization

On the receiving side, the A2A server validates the delegation token, extracts the principal claim, and passes it to the agent's authorization layer. The agent's tools enforce against the principal's permissions, not the calling service's. The principal claim is also propagated in tool calls — when the Sierra returns agent calls a refunds API, it passes the principal forward, and the refunds API enforces against the principal's account permissions.

What this looks like in a Google ADK orchestrator calling a CrewAI returns agent on behalf of a customer:

# Frontend authenticates the customer, gets id_token
customer_token = frontend_auth.get_id_token(request)

# Orchestrator processes the chat
orchestrator = Agent(...)
response = orchestrator.invoke(
    user_message="I want to return order 12345",
    principal=customer_token,  # propagated through reasoning loop
)

# When the orchestrator calls the returns-triage A2A peer, ADK
# automatically exchanges customer_token for a delegation token
# bound to (subject=customer, actor=orchestrator-prod, audience=returns-triage,
# scope=create_refund, exp=5min) and presents it to the peer.
# The peer authorizes against the customer's account permissions.

The customer's identity, the orchestrator's identity, and the scope of authorized operations all travel together. The Sierra agent (or its CrewAI 2026 equivalent) cannot issue a refund the customer would not be authorized to request directly. Agent impersonation becomes structurally impossible, not just policy-discouraged.

When POBO Is Not the Right Pattern

Not every A2A call is acting on behalf of a human principal. Three cases where POBO is the wrong tool:

• Service-to-service operations not user-initiated. A nightly enrichment agent that calls a data-provider's agent to refresh records does not have a human principal in the loop. It's acting under its own service identity, with its own service authorization. OAuth client-credentials is the right pattern; POBO would be a misrepresentation.
• Aggregated/batch operations. A monthly billing agent that processes refunds for a batch of customers is acting on its own service authority granted by an internal billing operations team, not on behalf of each individual customer. Service-to-service with audit-trail enrichment (carrying batch metadata) is the right pattern.
• Public/anonymous read operations. An agent that calls a public knowledge-base agent to look up reference information does not have a principal. Anonymous or low-trust authentication is appropriate; POBO would be theater.

The discipline: POBO when a human's permissions should constrain the operation; service identity when the service is the legitimate actor; anonymous when the operation is genuinely public. Mixing these up creates exactly the failure mode the Decagon-Sierra incident illustrated — operations that look authenticated but lack the right authority model.

Agent Card Discovery and Poisoning Defenses

The Agent Card discovery flow is itself an attack surface. Three failure modes worth designing against:

Card poisoning

An attacker who briefly controls the operator's web server publishes a malicious Agent Card pointing to attacker-controlled endpoints. Calling agents fetch the card, trust the contents, and route traffic to the attacker.

Defenses: DNS-anchored signing keys (attacker would also need to compromise DNS). Trust-on-first-use with cryptographic pinning (subsequent fetches verify against the pinned key). Card-fetch caching with manual invalidation (rapid card changes trigger review). Marketplace attestation (the marketplace's signing authority must also be compromised).

Stale card consumption

An operator rotates their signing key. Calling agents continue using a cached card signed with the old key. New calls fail. Or worse — an attacker who compromised the old key can keep impersonating the operator until consumers refresh.

Defenses: short card-fetch TTLs (1-24 hours typical). Operator publishes a previous_keys revocation list for legitimate rotation. JWKS-style key URIs that point to a key-set endpoint, not an inline key, so rotation is observable.

Skill manifest drift

The Agent Card advertises a skill with a particular input/output schema. The operator quietly changes the schema. Calling agents continue constructing calls against the old schema; behavior breaks subtly.

Defenses: schema versioning in the skill declaration (evaluate_return/v2). Strict client-side schema validation on every call. Consumer-side regression tests that fetch the live card and verify against expected schema before deploying. Marketplace registries that flag breaking schema changes.

The Six-Step Identity Posture Build

Here is the routine we walk teams through to design and ship a 2026 A2A identity posture. Two to five days of focused work; longer if the org's identity infrastructure is immature.

1. Inventory the A2A relationships. Map every A2A call you plan to make. For each: who calls (your service), who answers (which agent at which operator), is there a human principal in the loop, what's the relationship type (tenant-to-tenant / cross-org / marketplace).
2. Pick the auth posture per relationship. mTLS for tenant-to-tenant. OAuth client-credentials for cross-org. Marketplace-brokered for opportunistic. Do not pick one tool for everything.
3. Stand up the IdP support for POBO. Configure RFC 8693 token exchange at your identity provider. Validate that you can mint a delegation token with subject + actor + audience + scope + expiry. Test the end-to-end flow with a sample call.
4. Sign your Agent Cards. Generate operator signing keys, bind to your domain via DNS or Web PKI, sign cards, publish at /.well-known/agent-card, distribute trust anchors to peers.
5. Wire POBO through your agent stacks. Pass principal tokens through your reasoning loops. Configure native-A2A framework wrappers (ADK, LangGraph, CrewAI) to perform token exchange transparently. Validate end-to-end that the receiving agent sees the principal.
6. Add observability and revocation paths. Trace store records principal, actor chain, scope, and outcome for every A2A call. Build a revocation path — if a principal token is compromised, you must be able to invalidate it and all downstream delegations. The shortest TTL you can tolerate is your operational baseline.

What to Avoid

• Sharing one service identity across all calling contexts. "We have one orchestrator service account for all A2A calls" is the precursor to the Decagon-Sierra incident. Service identity must be paired with principal-on-behalf-of when a human is in the loop.
• Long-lived bearer tokens. A 24-hour bearer token compromise gives an attacker 24 hours of impersonation. 5-15 minute tokens with refresh-via-IdP is the 2026 norm.
• Unsigned Agent Cards. A card without a signature is not A2A; it is wishful thinking with a JSON schema. Sign from day one.
• Trusting Web PKI alone for high-stakes relationships. Web PKI assumes the entire trust ecosystem of HTTPS certificate authorities. For critical operator-to-operator trust (financial, healthcare, regulated), DNS-anchored keys or private trust anchors are stronger.
• Skipping POBO when there's a human in the loop. If the chain started with a human user's session, the human's identity must propagate. Anything else is agent impersonation by structural omission.
• Forgetting the audit chain. The act_chain claim on the delegation token preserves the full chain of acting services. If you lose this, your post-incident forensics are blind. Log it; preserve it.
• Manually managing OAuth client secrets across dozens of A2A relationships. Use a secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager) with automatic rotation. Hand-managed secrets become stale and leak.
• Ignoring the principal's revocation surface. If a customer logs out or has their account suspended, in-flight delegation tokens issued on their behalf should not continue authorizing operations. Build the revocation path before you need it.

Three Deployment Shapes from Q1-Q2 2026

A 90-person consumer-finance fintech. Customer chats route through a Google ADK orchestrator that invokes specialist agents (account history, dispute review, refund processing) over A2A. Every call carries a POBO delegation token derived from the customer's authenticated session. Identity provider is Auth0 with RFC 8693 token exchange. Specialists enforce against the customer's actual account permissions. The architecture survived a Q1 2026 security review with the only finding being "shorten the principal TTL from 15 minutes to 5"; no agent-impersonation gaps were found.

A 400-person healthcare SaaS. Provider-facing agents call patient-record specialists over A2A across HIPAA-compliant infrastructure. mTLS for cross-cluster trust (internal CA), OAuth client-credentials for the cross-vendor data-exchange peer. POBO delegation tokens carry the provider's identity plus the patient context. Every A2A call is logged with principal, actor chain, scope, and patient-id for HIPAA audit. Six months in production, zero authority-confusion incidents.

A 60-person research startup. Single orchestrator invokes specialist agents found on the OpenAgents Registry marketplace. Marketplace-brokered identity: the registry asserts operator domain control via DNS-anchored attestation, signs each registered Agent Card, and provides a token-exchange endpoint that bridges the calling org's IdP to the receiving operator's auth. Total custom auth code on the calling side: under 30 lines. The marketplace earns its place by handling the cross-org identity story.

Key Takeaways

• The December 2025 Decagon-Sierra confusion named the failure mode: agent impersonation. A downstream agent issued an action "as the customer" when the upstream agent had no principal-on-behalf-of token representing the customer.
• A 2026 A2A identity posture answers three questions, not one: who is the calling service, who is the operator, and who is the human principal on whose behalf the chain is acting.
• Three auth postures for three relationships. mTLS for tenant-to-tenant. OAuth 2.0 client-credentials plus signed Agent Card for cross-org. Marketplace-brokered identity for opportunistic cross-vendor.
• Signed Agent Cards with cryptographic domain verification are the foundation. Three binding mechanisms: DNS-anchored keys, Web PKI, marketplace attestation. Pick by relationship stakes.
• The principal-on-behalf-of (POBO) pattern, derived from OAuth 2.0 Token Exchange (RFC 8693), is the canonical mechanism for propagating a human user's identity across A2A hops. Subject + actor + audience + scope + short expiry.
• Native-A2A framework wrappers (ADK, LangGraph, CrewAI, LlamaIndex, Semantic Kernel, AutoGen) ship POBO support out of the box. Token exchange is automatic; you pass the principal.
• POBO is not the right pattern for service-to-service operations without a human in the loop. Use service identity; do not misrepresent the authority model.
• Agent Card poisoning, stale-card consumption, and skill manifest drift are real attack surfaces. Defenses: DNS-anchored keys, short TTLs, JWKS-style key sets, schema versioning, regression tests.
• Six-step build routine: inventory relationships, pick posture per relationship, stand up IdP token-exchange support, sign your cards, wire POBO through agent stacks, add observability and revocation paths.
• The 2026 norm: principal token TTLs of 5-15 minutes, refresh via IdP, full actor chain logged for audit, revocation path tested before you need it.