A2A Extension
Confidential A2A (cA2A) v0.1
This page is what the cA2A v0.1 extension URI resolves to. The URI is an identifier, not an endpoint: A2A agents put it in their Agent Card to advertise the profile, and clients echo it in the A2A-Extensions header to opt in.
example.com deliberately.
What the extension adds
A2A's Signed Agent Card answers one question: did the domain owner issue this card. cA2A adds a trust envelope around a delegated task, carried entirely in A2A extension metadata. It defines no new wire format and no new endpoint. Removing every cA2A key from a message leaves a valid A2A task, which is what lets a cA2A deployment interoperate with peers that have never heard of the profile.
| A2A element | cA2A addition |
|---|---|
| Agent Card | An attestation measurement expectation for the peer, checked before a task is accepted |
| Task message | A delegation credential naming issuer, subject, scope, depth, and parent link |
| Task payload | Sealing to the peer's attested measurement |
| (none) | A per-hop provenance record linking to its parent, forming the delegation DAG |
Declaring support
An agent supporting the profile advertises the URI under capabilities.extensions in its Agent Card:
{
"capabilities": {
"extensions": [
{
"uri": "https://agentrust-io.com/extensions/ca2a/v0.1",
"description": "Confidential A2A v0.1",
"required": false
}
]
}
}
required is false because the profile is an overlay. A cA2A peer must treat a message carrying no cA2A keys as ordinary A2A input rather than synthesise a partial trust state from their absence, so a card that advertises cA2A still serves plain A2A clients.
A complete reference card, valid against the A2A v1.0 AgentCard definition, is at /examples/ca2a-agent-card.json.
Status
cA2A v0.1 is a developer preview and will change shape before v1. The delegation chain is verified and the payload is sealed, but binding that seal to a hardware-verified peer measurement is not yet wired: the reference transport runs in software mode with assurance="none". Running the peer path end to end off hardware is not evidence that cA2A is attested across trust domains.
Normative sources
This page is orientation. The binding is specified in the cA2A documentation, and that is the text to implement against:
- Transport binding, including the namespaced metadata keys and what ships today versus what does not
- Profile, the normative requirements P-1 onward
- Threat model
- Source and reference implementation