Specification Overview

v0.4.0 Draft

The Agent Receipt Protocol defines a standard format for cryptographically signed records of AI agent actions. This page covers the design principles and core concepts. For the full specification, see the spec source on GitHub.

What's new in v0.4.0

• credentialSubject.action.idempotency_key — optional stable identifier for the logical operation an action represents (e.g. a request ID). When an agent retries a tool call, the SDK or MCP proxy stamps the same key on every receipt for that operation, so verifiers can tell a legitimate retry from a duplicated emission. The MCP proxy populates it automatically from the wrapped JSON-RPC request id.
• Verifier rule (spec §7.3.6): two or more receipts in a chain sharing a non-empty idempotency_key are surfaced as a warning, never a verification failure — retries are legitimate.
• version field now accepts "0.1.0", "0.2.0", "0.2.1", "0.3.0", or "0.4.0". Verifiers MUST accept all five; new receipts SHOULD use "0.4.0". See the full changelog.

Design principles

1. Privacy-preserving by default. Parameters are hashed, not stored in plaintext. The operator controls what is disclosed. Sensitive data never appears in receipts — only hashes and operator-controlled disclosures.

2. Built on existing standards. W3C Verifiable Credentials Data Model 2.0 for structure. Ed25519 for signing. SHA-256 for hashing. RFC 3161 for trusted timestamps. No novel cryptographic primitives.

3. Hash-chained for integrity. Each receipt includes the hash of the previous receipt, forming a tamper-evident chain. Breaking the chain is detectable.

4. Agent-agnostic. The spec does not assume MCP, OpenAI function calling, or any specific agent framework. Any agent that can produce JSON and sign it can emit receipts.

5. Human-readable and machine-verifiable. Receipts can be displayed as a timeline to end users and cryptographically verified by auditors and compliance tools.

6. Reversibility-aware. Every receipt declares whether the action can be undone, and if so, how. This enables downstream tooling to offer "undo" capabilities.

7. Minimal by default, extensible by design. The core schema is small. Domain-specific extensions (financial actions, healthcare, etc.) can be layered on via additional @context URIs.

Core concepts

This field map also appears in How It Works and Agent Receipt Schema. The Schema page is the authoritative field reference.

Agent Receipt

A cryptographically signed record of a single action taken by an AI agent on behalf of a human principal. Modeled as a W3C Verifiable Credential with type AgentReceipt.

Receipt Chain

An ordered sequence of Agent Receipts linked by hash references. Each receipt contains the hash of the previous receipt in the chain, creating a tamper-evident log. The first receipt in a chain has a null previous hash.

Action Taxonomy

A standardized vocabulary of action types, organized by domain and risk level. The taxonomy enables cross-agent comparison and risk classification. See Action Taxonomy.

Principal

The human (or organization) on whose behalf the agent acted. Identified by a DID or URI. The principal is the entity who authorized the action, not the entity that built or operates the agent.

Issuer

The agent (or agent platform) that performed the action and produced the receipt. The receipt is signed using the issuer's key — in the reference implementation the agent-receipts daemon holds that key and performs the signing; the issuer process sends the event fields and never touches the key directly.

Relationship to existing work

Agent Receipts builds on established standards and sits alongside a growing set of agent-audit and provenance projects. The tables below separate the normative ancestry the protocol is built on from the adjacent projects working the same problem. For the always-current view of the wider space, see the agent security tooling landscape.

Normative ancestry

Standard	Relationship
W3C Verifiable Credentials Data Model 2.0	The envelope Agent Receipts is built on — this protocol is a profile of W3C VC for the agent-action use case.
RFC 8785 (JSON Canonicalization Scheme)	Used to derive the canonical form that is hashed and signed; chosen specifically so the protocol relies on no novel cryptographic primitives.
W3C Decentralized Identifiers (DIDs)	The identifier scheme for agent and principal identities; receipts express the issuer and principal as DIDs or URIs.

Adjacent projects

Project	Relationship
IETF draft-sharif-agent-audit-trail	Independent IETF Internet-Draft that converged on RFC 8785 + SHA-256 hash chaining. Agent Receipts differs by using a W3C VC envelope rather than a bespoke signed-JSON format, and by specifying an out-of-agent signing model rather than in-agent self-signing.
W3C AIVS Community Group	Early-stage W3C Community Group also working on agent audit primitives, session-grained rather than action-grained.
Pipelock EvidenceReceipt	Hash-chained JSONL evidence log produced by the Pipelock agent firewall; the same envelope-as-infrastructure thesis at a different layer (egress firewall vs. audit issuer).
Microsoft Agent Governance Toolkit (AGT)	Application-middleware governance framework with in-process Merkle-chained audit; it audits inside the same trust boundary as the agent, where Agent Receipts audits from outside it.
Asqav	The closest functional analog; uses ML-DSA-65 (quantum-safe) signing rather than Ed25519, and in-SDK signing rather than daemon-separated.
nono	Append-only Merkle tree the agent cannot reach; closest to Agent Receipts on the out-of-agent property, differing by anchoring records in a Sigstore/Rekor transparency log rather than a W3C VC envelope.
InALign	Hybrid local/cloud product with bundled risk analysis; product-shaped where Agent Receipts is protocol-shaped.