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

[imran-siddique]

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 [Extension proposal] : Hardware based Remote Attestation for A2A: Mutual Runtime Trust #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 [Extension proposal] : Hardware based Remote Attestation for A2A: Mutual Runtime Trust #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

[giskard09]

For the cross-org, no-shared-authority case (which #1713 raises too): delegation-chain-ref-v1 (argentum-core, JCS+SHA-256 over declared fields, no hardware dependency) already enforces per-hop attenuation (monotonic_scope_narrowing, rejects scope_widening) and chain continuity. Until today its only conformance fixture was single-operator, so I was not going to cite it here as answering what cA2A verifies.

As of f1259d7 (pushed, CI green) it also has hop_signature — Ed25519 by the delegator over its own delegation_ref, verified against a per-agent pubkey — and a replay guard rejecting a resubmitted chain_id/delegation_ref. The new cross-org fixture uses three independent signers with no shared authority, plus an adversarial vector (signature_substitution) confirming chain-continuity alone does not catch a forged hop.

What it does not do, by design: no peer runtime attestation, no payload sealing to hardware — it is the attenuation/provenance layer without the TEE requirement. That is a real gap against the confidentiality property cA2A is after, and I would read it as complementary to #2078's handshake rather than competing: an org with SEV-SNP/TDX gets cA2A's full guarantee, an org without one still gets offline-verifiable per-hop attenuation and provenance.

Separately — the same admission you made about the harness ("software-attested against synthetic vectors, because genuine evidence embeds per-CPU identifiers and cannot ship as a fixture") is the same shape of gap we flagged in #2887's AXES envelope (anchoring_method: "write_once_store (SIMULATED)", still true as of today) and have been running a permissionless on-chain anchor against in production since #2332 (7+ weeks, third-party cross-verification — aeoess merged action-ref-v1 recomputation fixtures into argentum-core via #12, and separately recast our decision_ref/screen_ref set into APS's own shape in aeoess/aps-conformance-suite#9). Not claiming that solves the hardware-evidence problem — different mechanism, different property — just flagging the pattern in case the provenance layer ends up needing an existence-proof independent of the enclave.

Fixture: examples/conformance/delegation-chain-ref/{vectors,cross-org-vectors,replay-vectors}.json, commit f1259d7.