Skip to content

Limitations

cA2A is a pre-release profile in active design. This document states plainly what is built, what is stubbed, and what is out of scope, so no claim in the documentation runs ahead of the code. This is a deliberate discipline: proof, not promises.

What is built

  • The delegation credential model and the offline chain verifier skeleton: signature checks, scope attenuation (a child grant must be a provable subset of its parent), depth limits, and cross-chain replay rejection. The hardest of these semantics is reused from agent-manifest, where it is implemented and tested.
  • Configuration, error registry, and the CLI surface.
  • A reference HTTP transport and the attestation handshake, in software mode. ca2a_runtime.transport.server and ca2a_runtime.transport.client (standard library only) run a live inbound A2A-profile call end to end: the caller fetches the callee's attested channel key, seals a payload to it, and sends a delegated task; the callee parses the A2A metadata with the adapter, runs verify + policy + enforce + open-sealed + provenance, and replies. ca2a_runtime.attestation gates the seal on a verified channel key. This is a reference transport, not part of the profile: the profile mandates no wire protocol (see Out of scope), and in software mode the peer key is accepted at assurance="none".

What is stubbed or not yet implemented

  • Hardware-attested live binding. The verifier seam in ca2a_runtime.attestation has now been driven off a real SEV-SNP quote on an Azure confidential VM: verify_offer returned assurance="hardware", a payload was sealed to a channel key a hardware-verified measurement vouches for, and both a measurement mismatch and a stale nonce were rejected. See docs/hardware-validation.md. Two gaps remain. First, the reference server/client still run in software mode by default (assurance="none"); the hardware path is a validated capability, not the default configuration, and there is no CLI listener (ca2a start) since serving is via ca2a_runtime.transport.server.serve. Second, attestation on that run was one-directional: a follow-on cross-operator run (an Azure SEV-SNP peer calling a GCP Intel TDX peer, recorded in the same document) had the caller appraise the callee's real TDX quote before sealing, but the callee did not appraise the caller in return. Mutual simultaneous attestation is the remaining step, and both peers were driven by one operator's harness.
  • Sealed peer channel (hardware property). The channel is implemented: a payload is sealed to the peer's attested X25519 key (X25519 ECDH, HKDF-SHA256, ChaCha20-Poly1305), and only the holder of the peer's private key can open it. On a live call the handshake now gates the seal on a channel key the caller has appraised, but in software mode that appraisal is assurance="none". Until the seal is bound to a hardware-verified measurement (above), do not assume a payload is confined to a specific attested measurement. Adapter-decoded sealed_payload bytes are opaque ciphertext only.
  • Real hardware attestation. The SEV-SNP and Intel TDX verifiers now appraise genuine hardware evidence end to end: a real Azure CVM SEV-SNP report (VCEK chain to the AMD ARK-Milan root, ECDSA-P384 report signature, measurement binding) and a real GCP C3 DCAP v4 TDX quote (PCK chain to the Intel SGX Root CA, QE binding, quote signature, MRTD binding), both fail-closed and both rejecting a tampered copy. Runs are recorded in docs/hardware-validation.md. The TPM 2.0 verifier (AK chain to a caller-supplied vendor root, AK signature, magic/type, and the key-and-nonce binding) is implemented, and its cryptography is delegated to agent_manifest.verify_tpm_quote rather than being a third copy. Quote generation still requires the respective hardware for SEV-SNP and TDX. This validates those verifiers, not a running attested peer: until the verifier seam in ca2a_runtime.attestation is driven off a live quote on a confidential VM, cA2A must not be described as attested across trust domains.
  • TPM collection works on hardware; chained verification does not, on every host. Measured on a real Azure Trusted Launch vTPM (Standard_D2s_v7, eastus2, 2026-08-01). What passed: TpmProvider.attest produced a genuine quote signed by the platform attestation key (RSASSA/SHA-256), the shipped certificate certifies the quoting key, parse_tpmt_signature unwrapped the real TPMT_SIGNATURE and the bare signature verified against the shipped key, a tampered attest blob was rejected, and the quote's extraData equalled the derived key-and-nonce binding. Collector and verifier also ran in one process, which the previous caveat here said was untested: building tpm2-pytss from source inside a venv resolves the conflict with agent-manifest's cryptography, so that tooling limitation is retired.

What failed, and it is the important half: verify_tpm_report could not chain to a pinned root, reporting "AK chain root is not among the supplied trusted TPM roots". On that host the AK certificate at NV 0x01C101D0 is 994 bytes, is issued by CN=Global Virtual TPM CA - 03, and carries no AIA extension at all, so there are no intermediates to fetch and none stored elsewhere in NV. A different Azure host (Standard_D2s_v5, eastus, 2026-07-31) presented a 1596-byte certificate under Azure Cloud Virtual TPM CA - 11 with a walkable AIA chain reaching the root pinned in ca2a_verify/tpm_roots.py. Both observations are real: Azure runs more than one vTPM CA generation, so the shipped Azure root is not sufficient fleet-wide and a deployment must pin the hierarchy its own hosts actually present. Until then, treat the TPM tier as: evidence is genuine and its signature and binding are verifiable, but key provenance is host-dependent. - TPM evidence proves key provenance only where a chain reaches a pinnable root. A quote signed by the transient fallback key is a verifiable signature but carries no certificate chain, so it proves nothing about where the key lives, and verify_tpm_report rejects it. As above, a platform-provisioned certified attestation key is necessary but not sufficient: the chain must also be assemblable, which fails when the AK certificate carries no AIA. A GCP Shielded VM is weaker still (probed 2026-07-31: no EK certificate, no persistent handles, and get-shielded-identity returns a bare ekPub with no certificate). Client firmware TPM vendor roots are not yet published in a pinnable form. Separately, the TCG event log is 0 bytes on both Azure and GCP, so PCR values cannot be attributed to specific boot events on either cloud.

Out of scope

  • A normative or production A2A transport. cA2A is a profile on A2A, not a replacement for it, and mandates no wire protocol. A reference HTTP transport ships (ca2a_runtime.transport.server/client) so the peer path is runnable on ordinary compute, but it is a convenience, not part of the profile: any A2A server can drive the adapter and a PeerNode instead, and cA2A makes no claim about the reference transport's production hardening.
  • Agent identity issuance beyond delegation.
  • AI model governance beyond delegation and provenance.
  • Hardware TEE platform SDKs and firmware.

Dependencies on sibling projects

cA2A composes primitives from agent-manifest, cmcp, and trace-spec. Version skew across those repos can change cA2A behavior; pin compatible versions before relying on cross-repo guarantees.