With the rise of the Agentic Economy, there is a critical need for a deterministic mechanism to verify actions between independent AI systems. Existing protocols (e.g., MCP) provide Connectivity but lack cryptographic Non-repudiation.
The A2A Accountability Protocol (v0.5) defines a standardized method for bilateral cryptographic handshakes, strict Intent Binding with tool context, and a streaming immutable DAG ledger for machine-to-machine interactions.
New in v0.5: The protocol is extended with a Content Provenance Layer — a cryptographic attribution mechanism for AI-generated artifacts (text, code, images, audio, video). This directly addresses the emerging regulatory gap in which the liability for harmful AI-generated content is undefined. By recording a cryptographically signed provenance receipt at the moment of generation, the protocol creates an immutable chain of custody from model to artifact to downstream action — enabling auditors, regulators, courts, and insurers to establish accountability without compromising user privacy.
// 02
Terminology
Agent A (Initiator)
The AI system initiating a request to execute a high-value action.
Agent B (Executor / Tool)
The AI system or MCP tool receiving the request.
Trust Proxy
A middleware component implementing the protocol and acting as a trusted Signer on behalf of the agent.
VC (Verifiable Credential)
A cryptographically signed mandate (Policy) defining the risk budget of the agent.
Content Producer NEW v0.5
The AI platform, model, or agent responsible for generating an artifact. Identified by a DID and model version hash.
Provenance Receipt NEW v0.5
A signed envelope recording the cryptographic binding between a generation request (prompt hash), the model that processed it, and the resulting artifact (content hash). Stored in the DAG ledger as event type PROVENANCE_RECORD.
Session DID NEW v0.5
An ephemeral, privacy-preserving identifier for a user session. Not linked to personal identity by default. Linkage to real identity occurs only under court order or regulatory disclosure process.
// 03
Transaction Lifecycle
The protocol consists of three mandatory phases and one optional phase (Ack) for bilateral Non-repudiation:
1
Proposal (Intent Envelope)
Proxy A intercepts the call, canonicalizes the arguments, adds a binding to the MCP schema and expiration time (TTL), signs the payload (Proxy-only or Dual-Sign), and sends it to Proxy B.
2
Acceptance Receipt
Proxy B evaluates the policies. If the validation passes, it generates a policy_eval_hash, signs the agreement to execute, and returns the receipt.
3
Execution Envelope & Ack
After completing the task, Proxy B hashes the result (output_hash), records the status, and signs the final envelope. Optionally: Proxy A returns a Receipt Acknowledgement to finalize the proof cycle.
4
Provenance Receipt NEW v0.5
When the action produces an AI-generated artifact (text, code, image, audio, video), the Content Producer MUST emit a Provenance Receipt binding the session, model, prompt hash, and content hash. This receipt is appended to the same DAG trace, creating an unbroken chain from authorization to output.
// 04
Data Formats
Hash Target Rule (Critical)
Artifact hashes (e.g., intent_hash) MUST be computed strictly as SHA-256( JCS(Envelope WITHOUT "signatures" field) ), where JCS is the JSON Canonicalization Scheme (RFC 8785). This allows adding multiple signatures without breaking the base envelope hash.
Emitted by the Content Producer immediately after generating an AI artifact. Links the session, model, prompt, and output into a single signed record.
{
"envelope_type": "ContentProvenanceReceipt",
"spec_version": "0.5",
"trace_id": "urn:uuid:a7f2...", // shared with parent transaction if applicable"timestamp": "2026-04-01T10:15:31.500Z",
"producer": {
"did": "did:workload:content-platform-01", // AI platform DID"model_id": "claude-3-5-sonnet-20241022", // model name + version"model_version_hash": "sha256:e9f1...bc4", // hash of model weights/checkpoint if available"system_prompt_hash": "sha256:3a2d...f81"// hash of system instructions
},
"request": {
"session_did": "did:session:anon:8f42d9a1b2c3", // ephemeral, not linked to PII"prompt_hash": "sha256:b7c4...19e", // SHA-256(JCS(prompt)). Raw prompt off-chain."nonce": "f91a3d72",
"request_context": {
"ip_region": "US-TX", // jurisdiction (no IP address)"platform_product": "api_v1"// surface (API / web / mobile)
}
},
"artifact": {
"content_hash": "sha256:9f86...d46", // SHA-256(raw output bytes)"media_type": "text/plain", // MIME type of artifact"byte_length": 4096,
"c2pa_manifest_hash": "sha256:2b1e...a93", // optional: C2PA compatibility"downstream_intent_hash": "c4d3...e21"// links to A2A transaction if artifact is used in one
},
"classification_hints": { // non-binding signals, not determinations"safety_filter_passed": true,
"policy_version": "usage-policy-2026-Q1",
"content_categories": ["financial-analysis"] // platform-defined taxonomy
},
"signatures": [{
"role": "producer",
"kid": "did:workload:content-platform-01#key-1",
"alg": "EdDSA",
"signed_digest": "7a2b...c31",
"value": "eyJhbGciOiJFZERTQSJ9..."
}]
}
// 05
Validation Rules
Time Management and Clock Skew
→Time Model:expires_at MUST be strictly greater than timestamp. The TTL window is expires_at − timestamp.
→Clock Skew Rule: Verifier MUST reject if current_time > expires_at + skew_tolerance. RECOMMENDED skew_tolerance is 5 seconds.
Anti-Replay
→ Proxy A MUST ensure nonce uniqueness per (initiator.did, nonce) before signing.
→ Proxy B MUST enforce nonce uniqueness per (initiator.did, nonce) until expires_at + skew_tolerance.
Dual-Signature Policy
→ For High-Value actions (fund management, IAM), the protocol SHOULD require Dual-Signature. In Low-Trust environments, Proxy-only signatures are acceptable only if agent_attestation_ref is provided.
Provenance Receipt Validation
NEW v0.5
→Producer identity:producer.did MUST resolve to a valid DID document with a public key matching the signature kid.
→Content hash integrity: Verifier MUST be able to re-compute artifact.content_hash from the raw artifact bytes off-chain.
→Prompt hash off-chain: Raw prompts MUST NOT appear in the receipt. Only prompt_hash is on-chain. Off-chain disclosure occurs under regulatory or judicial process only.
→classification_hints are non-deterministic: Verifiers MUST NOT treat classification_hints as factual determinations of legality or harm. They are platform signals only.
→Downstream linkage: If a provenance receipt references a downstream_intent_hash, the corresponding A2A transaction MUST exist in the same DAG trace.
// 06
Streaming Ledger (DAG Architecture)
To support logic branching and multi-agent delegations, the protocol utilizes a Directed Acyclic Graph (DAG).
Merkle Leaf Definition
The base nodes (Leaves) for constructing the Merkle tree are the entry_hash values, computed as: SHA-256( JCS(LedgerEntry WITHOUT "entry_hash") )
A ContentProvenanceReceipt is appended as a PROVENANCE_RECORD entry in the same DAG trace. Its prev_entry_hashes SHOULD reference the EXECUTION_RECORD that triggered the artifact generation, creating an unbroken causal chain: INTENT → ACCEPTANCE → EXECUTION → PROVENANCE.
// 07
Privacy Guidance
The Execution Ledger publicly records the existence of a transaction, but it must never leak trade secrets, PII, or API keys.
The protocol forbids storing plaintext JSON arguments inside Intent and Execution envelopes. Only args_hash and output_hash are permitted on-chain. In the event of a dispute, parties provide the original JSON off-chain, which the arbitrator verifies via SHA-256 against the on-chain hash.
v0.5: Privacy Model for Content Provenance NEW
→Session DID vs Identity: The on-chain record contains only a session_did — a one-way hash of the session token. It cannot be reverse-mapped to a real user without the platform's session key.
→Prompt privacy: Raw prompts are never on-chain. Only prompt_hash is stored. Disclosure of the raw prompt occurs exclusively under judicial order or regulatory subpoena to the Content Producer.
→Artifact privacy: Raw artifact content is never on-chain. Only content_hash is stored. This allows hash-matching against a suspected artifact without publishing the artifact itself.
→GDPR / right to erasure: Because no PII is on-chain, erasure requests apply to the platform's off-chain session store, not the immutable ledger. The on-chain hash remains but is irrelinkable after session key deletion.
// 08
Dispute Resolution (Dispute Pack)
A standard Dispute Pack provides independent cryptographic evidence of origin, sufficient for legal arbitration.
→ A linked DAG of JSON artifacts (Intent, Acceptance, Execution, Ack, Provenance).
→inclusion_proof: A Merkle Path proof connecting the entry to the root.
→anchor_ref: The L2 blockchain receipt (transaction hash).
Subject to agreed-upon Key Custody governance, this pack supports strong Non-repudiation claims. If the Merkle Proof matches the blockchain record, it mathematically guarantees that neither party could have altered the logs retroactively.
// 09
Content Provenance Layer
NEW v0.5
9.1. Problem Statement
The rapid proliferation of AI-generated content — including synthetic media, autonomous code, and AI-assisted communications — has created a systemic accountability gap. When AI systems generate harmful artifacts (deepfakes, malware, disinformation, copyright violations), the chain of responsibility is legally ambiguous:
The User says:
"I only submitted a prompt. The AI produced the output."
The Platform says:
"We cannot review every generation in real-time."
The Regulator says:
"There is no technical record linking the artifact to its origin."
The Content Provenance Layer resolves this by creating an immutable, cryptographically verifiable record at the moment of generation — without storing the content itself on-chain.
9.2. Chain of Custody Model
The provenance chain connects four elements cryptographically:
Session DID → prompt_hash → model_id + model_version_hash → content_hash
↓
ContentProvenanceReceipt (signed by Producer)
↓
PROVENANCE_RECORD in DAG → Merkle batch → L2 anchor
↓
Dispute Pack (available to regulators / courts)
9.3. Use Cases
🔍
Deepfake Attribution
A synthetic video is identified as harmful. The investigator computes SHA-256(video_bytes) and queries the Provenance Ledger. If a matching content_hash exists, the receipt reveals which platform and model generated it, and under which session — without revealing user identity unless legally compelled.
🦠
Malware / Exploit Code
A CSIRT identifies malicious code in the wild. The content_hash of the binary is matched against the Provenance Ledger. The receipt establishes when and by which model the code was generated, enabling law enforcement to subpoena the session records from the platform.
A rights-holder identifies AI-generated content that reproduces protected material. The provenance receipt proves the artifact was AI-generated (not human-created) and identifies the generation platform, shifting the liability analysis toward the platform's usage policies.
📰
Disinformation / Election Interference
A regulator investigates AI-generated disinformation campaigns. Provenance receipts establish which AI platforms contributed to the content graph, enabling platform-level enforcement without requiring identification of individual users in bulk.
9.4. C2PA Interoperability
The Content Provenance Layer is designed to be complementary to C2PA (Coalition for Content Provenance and Authenticity), not a replacement. The relationship is:
Layer
C2PA
TrustAgentAI v0.5
What is attributed
The artifact file (embedded manifest)
The generation event (on-chain receipt)
Where stored
Inside the file metadata
Immutable DAG ledger + L2 anchor
Tamper resistance
File can be stripped of manifest
On-chain record survives file manipulation
Agent context
Not included
Full A2A transaction chain included
Legal grade
Industry standard
Dispute Pack with Merkle proof + L2
When both are present, the c2pa_manifest_hash field in the Provenance Receipt links the on-chain record to the C2PA manifest embedded in the file — providing defense-in-depth attribution.
// 10
Regulatory Alignment
NEW v0.5
The v0.5 Content Provenance Layer is designed to satisfy emerging regulatory requirements across multiple jurisdictions. The following table maps protocol capabilities to regulatory obligations:
EU AI ACT
Article 52 — Transparency for AI-generated content
Requires AI systems to label generated content. The ContentProvenanceReceipt provides a machine-readable, cryptographically signed label at the generation layer — satisfying the technical requirement for AI content disclosure.
EU AI ACT
Article 13 — Logging obligations for high-risk AI
Requires logging of AI system operations. The DAG ledger with Merkle anchoring provides a tamper-evident audit trail that satisfies this requirement while protecting privacy via hash-only on-chain storage.
DSA
EU Digital Services Act — Systemic Risk Assessment
VLOPs (Very Large Online Platforms) must assess and mitigate systemic risks from AI-generated content. Provenance receipts enable platforms to demonstrate content attribution capability to regulators without mass surveillance.
US
Executive Order on AI Safety (Oct 2023) — Content Authentication
Directs NIST to develop standards for AI content authentication. The TrustAgentAI v0.5 provenance model aligns with NIST's draft AI RMF Playbook and the emerging NIST watermarking guidance for generative AI.
US CA
California AB 2602 / AB 3211 — AI-generated content disclosure
Requires disclosure of AI-generated content in specific contexts. Provenance receipts provide the technical infrastructure for automated disclosure compliance, with the platform as the accountable party rather than end users.
Liability Shift Mechanism
A core regulatory objective of v0.5 is enabling a structured liability framework for AI-generated harm. Under current law, liability is diffuse. The Provenance Layer creates the technical predicate for a clearer model:
Platform liability
When the provenance receipt shows the generation occurred, which model was used, and which safety filters were applied — the platform bears primary accountability for policy violations.
User accountability
When a court or regulator establishes that a user deliberately bypassed safety controls (evidenced by prompt_hash disclosure), user liability can be established without implicating all users of the platform.
Model developer responsibility
The model_version_hash enables attribution to a specific model checkpoint — relevant when a vulnerability or capability of a specific version is implicated in systemic harm.
// 11
Changelog
v0.5
→ Added §4.4 ContentProvenanceReceipt envelope format
→ Added §5 Provenance Receipt Validation rules
→ Added PROVENANCE_RECORD event type to DAG Ledger (§6)
→ Added §7 v0.5 Privacy Model for Content Provenance