[Extension Proposal]: cA2A, confidential delegation (attenuated authority, peer attestation, sealed payloads, provenance)

## Abstract

cA2A adds a verifiable trust envelope to a **delegated, multi-hop** A2A task: an attenuated delegation credential proving the caller's authority is a subset of what it was granted, appraisal of the peer's runtime attestation before the task is handed over, sealing of the task payload to the appraised peer key, and a per-hop provenance record forming an offline-verifiable DAG.

It defines no transport and no new endpoint. Removing every cA2A field from a message leaves a valid A2A task.

## Relationship to the proposals already open

This space is active, and cA2A overlaps parts of it. Stating that up front rather than restating solved problems:

| Existing | Overlap | How cA2A relates |
|---|---|---|
| #2078 hardware remote attestation | Substantial: peer attestation, channel binding, HPKE-sealing to an attested key | **#2078 is ahead of us on the handshake**, and does mutual attestation, which our implementation does not yet. We would rather compose with it than duplicate it. cA2A's contribution is what happens to *delegated authority* across hops once a peer is attested |
| #2028 actor-chain | On-behalf-of chain shape | Overlaps our `delegation_chain` payload shape. Worth reconciling; we do not need a second shape if that one carries attenuation and per-hop signatures |
| #1937 context-binding for delegated authority | Binding delegated authority to context | Adjacent. Ours binds authority to an *attested runtime* and a sealed payload, not only to context |
| #1713 cross-org accountability, no shared AS | The cross-organization first-contact case | Same problem framing. Ours answers it with offline-verifiable provenance records rather than a shared authorization server |
| #1786 CTEF cryptographic agent identity | Identity claims | Complementary: identity of the party, not attenuation of what it may re-delegate |

If the consensus is that these should converge into one extension rather than five, we would rather help do that than add a sixth.

## Motivation

A2A delegates authentication to standard web mechanisms, and its payloads carry no identity: authentication binds the connection, authorization is per-skill access control. That is sufficient for a single hop inside one organization.

It does not cover the multi-hop, cross-organization case. When A delegates to B and B to C across trust boundaries, four questions have no answer in the core protocol, and mTLS plus OAuth cannot answer them either, because they secure the connection rather than the delegated authority:

1. **Is B's authority a provable subset of A's, across hops?** Scopes gate skills; they do not attenuate delegated authority hop to hop.
2. **Is the peer running attested code before it is trusted with the task?** A Signed Agent Card proves card integrity and domain-owner origin. A detached signature over static metadata cannot attest live runtime state. (This is #2078's question, and we agree with its framing.)
3. **Is the payload readable only inside the peer's verified enclave?** TLS secures the pipe; the plaintext lands in the peer's ordinary memory.
4. **Can a third party reconstruct who delegated what to whom, offline, later?** Connection logs are operator-held and not linked across hops.

OWASP's agentic taxonomy names these as T14 (delegation abuse, cross-agent privilege escalation) and T16 (insecure inter-agent protocol abuse, naming A2A explicitly).

Attenuated delegation on its own is well-trodden: UCAN v1.0, OAuth Token Exchange (RFC 8693), and `draft-rampalli-pedigree` all cover per-hop scope narrowing, and cA2A claims no novelty there. What none of them bind is peer runtime attestation, payload sealing to a hardware measurement, and confidential cross-operator provenance. **The combination is what this extension is for.**

## Technical approach

Four things in A2A `metadata` under a namespaced URI, with the client opting in via `A2A-Extensions`:

| Key suffix | Type | Meaning |
|---|---|---|
| `delegation_chain` | array | Root-to-leaf signed delegation credentials |
| `requested_capability` | string | The capability the callee must grant |
| `record_id` | string | Provenance record id for this hop |
| `parent_record_hash` | string or null | Parent record hash; null at the root |
| `sealed_payload` | base64url or absent | Opaque sealed ciphertext |

A conforming callee verifies the chain (signature, continuity, attenuation, depth, replay), computes the effective scope as the delegated leaf scope **intersected with its own local policy**, refuses anything outside it, opens the sealed payload with its enclave-bound key, and emits a provenance record linked to its parent. A refusal emits a record too, so a denial is evidence rather than a gap, and a refused hop is terminal.

Ignore-versus-enforce is explicit: a peer that does not implement the extension ignores the fields; a peer that does treats a message with no cA2A keys as ordinary A2A, and fails closed on partial or malformed cA2A metadata.

## Status of the reference implementation

Stated plainly, because the extension is about verifiable claims and it would be poor form to overstate its own.

- **Working and offline-verifiable today**: attenuated delegation chains, the scope-intersect-policy decision, provenance DAGs including denial records, the A2A extension adapter, and a reference HTTP transport.
- **Verified against real hardware**: the SEV-SNP and TDX verifiers appraise genuine Azure CVM and GCP C3 evidence end to end. On 2026-07-27 the handshake ran off a live SEV-SNP quote and returned `assurance="hardware"`, sealing a payload to a key vouched for by a hardware-verified measurement. A cross-operator, cross-TEE run followed: an Azure SEV-SNP peer calling a GCP Intel TDX peer.
- **Not yet true**: that run was **one-directional**. The caller appraised the callee, not the reverse, so mutual simultaneous attestation, which #2078 specifies, is outstanding. The committed example harness also remains software-attested against synthetic vectors, because genuine evidence embeds per-CPU identifiers and cannot ship as a fixture.

Apache 2.0 and A2A-website documentation are graduation-tier requirements we would meet before proposing official status. The implementation is MIT today, uses DCO with no CLA, and relicensing needs contributor consent, which is in progress.

## Ask

Feedback on the approach, and specifically on whether the delegation-and-provenance layer belongs with #2078's attestation handshake in one extension or alongside it as a separate one. If a Maintainer sees a fit, we would welcome sponsorship of an `experimental-ext-ca2a` repository so the specification and reference implementation can iterate in the open under A2A governance.

Reference implementation: https://github.com/agentrust-io/ca2a