Compliance Profile of Signed Action Receipts for AI Agents

1.1. Profile, Not Fork

[ACTA-RECEIPTS] specifies a generic, signed receipt envelope for recording machine-to-machine access control decisions made by AI agents. Section 2.2 of [ACTA-RECEIPTS] defines a common payload field set in which all fields except type, issued_at, and issuer_id are OPTIONAL. Section 5.7 of [ACTA-RECEIPTS] introduces hash chaining (previousReceiptHash) inside an optional Commitment Mode extension. [ACTA-RECEIPTS] does not define receipt retention, does not require timestamping anchors, and does not bind to any regulatory regime.¶

The author considered three options for this document.¶

• Option A, regulation-mapping informational doc only. Rejected because regulators do not, in practice, accept log records whose semantics are negotiated bilaterally; field-level constraints are needed.¶
• Option B, fork-and-extend with a new wire format. Rejected because the [ACTA-RECEIPTS] envelope is sufficient for the bindings in this document; a fork would fragment the small ecosystem.¶
• Option C, additive profile. Adopted. This document constrains fields that [ACTA-RECEIPTS] leaves OPTIONAL, fixes their values where regulation requires, and adds two extension fields with reserved names. The profile remains an additive overlay: a Compliance Receipt is also a conformant [ACTA-RECEIPTS] receipt.¶

This document tracks [ACTA-RECEIPTS] revisions. Field references in this profile use upstream field names rather than upstream section numbers wherever possible, to reduce the maintenance hazard if upstream re-numbers sections in a future revision.¶

1.2. Scope

This document fills the regulatory binding gap for three obligations: Article 12 (record-keeping) and Article 26 (deployer obligations) of the EU AI Act, and Article 17 (ICT-related incident management) of DORA.¶

A receipt that conforms to this profile is also a conformant [ACTA-RECEIPTS] receipt. A verifier that implements only [ACTA-RECEIPTS] can still cryptographically validate a profile receipt but cannot attest the additional compliance bindings.¶

1.3. Why a Profile is Required

Regulators and auditors do not accept log records whose semantics are negotiated bilaterally between provider and deployer. The records must be machine-checkable, with field-level constraints that a third party can verify without access to the provider's internal documentation. [ACTA-RECEIPTS] provides the wire format. This profile provides the field-level constraints, the retention floor, the anchoring requirement, and the regime mapping.¶

4.1. Common Payload Fields

4.2. Decision Receipt Fields (type protectmcp:decision)

4.3. Hash-Chain Linkage (OPTIONAL upstream, REQUIRED in this profile)

Upstream Commitment Mode introduces previousReceiptHash as part of an optional extension. This profile makes the linkage REQUIRED. Implementations MUST emit a previousReceiptHash field, populated as specified by [ACTA-RECEIPTS] (lowercase hex SHA-256 of the JSON Canonicalization Scheme [RFC8785] encoding of the predecessor receipt). The first receipt in a chain MUST set this field to the all-zero SHA-256 value.¶

Implementations of [ACTA-RECEIPTS] that do not implement Commitment Mode produce receipts that are not Compliance Receipts under this profile.¶

4.4. Anchoring (No Upstream Equivalent)

[ACTA-RECEIPTS] mentions Sigstore Rekor only as an informational example. This profile imposes a normative dual-anchor requirement.¶

Compliance Receipts MUST be anchored. An anchor is an [RFC3161] timestamp token covering the signed envelope, an OpenTimestamps commitment covering the envelope, or both. Implementations SHOULD emit both forms. The anchor evidence MUST be retained alongside the receipt for the applicable retention window. Verifiers MUST reject Compliance Receipts that lack at least one valid anchor.¶

The anchor MAY cover an aggregate of receipts (for example, a Merkle root over a batch) rather than each receipt individually, provided that the inclusion proof linking the receipt to the aggregate is retained alongside the receipt and the aggregate anchor.¶

Where the anchor type is [RFC3161], the timestamping authority's certificate chain MUST be retained alongside the token for the applicable retention window. Where the anchor type is [OPENTIMESTAMPS], the upgrade path from the initial calendar attestation to the Bitcoin block attestation MUST be performed within seven days of issuance, and the upgraded proof MUST be retained alongside the receipt.¶

4.5. Extension Fields

This profile defines two extension fields that MAY appear in the signed payload alongside the fields defined by [ACTA-RECEIPTS]. Neither field is defined upstream.¶

risk_class:

A vocabulary term identifying the risk classification of the Action under the Deployer's risk management documentation. The vocabulary MUST be referenced in the Audit Pack metadata.¶

incident_class:

A vocabulary term identifying the ICT-related incident classification of the Action under the implementing technical standards adopted under [DORA].¶

Both fields MUST be encoded as JSON strings. Both fields MUST be covered by the signature in the same canonicalization regime as the remainder of the payload. Both fields are OPTIONAL at the syntactic level but MAY be REQUIRED by the regime bindings in Sections 6 through 8 of this document.¶

Implementations MAY define additional extension fields. Such fields MUST NOT collide with names defined by [ACTA-RECEIPTS] or by this document. Implementations defining extension fields SHOULD register them in the registry described in Section 11.¶

5.1. Article 12(1), automatic recording of events

A Compliance Receipt MUST be produced for every Action that the High-Risk AI System performs against an external resource. Receipt generation MAY be disabled only through a configuration change recorded as a protectmcp:lifecycle Compliance Receipt.¶

5.2. Article 12(2)(a), identify situations that may present a risk

The combination of type, decision, reason, and policy_digest MUST be sufficient for an auditor to identify, by query alone, receipts that correspond to risk situations enumerated in the Deployer's risk management documentation. Where the Deployer classifies an Action as risk-bearing, the receipt MUST carry a risk_class extension field.¶

5.3. Article 12(2)(b), facilitate the post-market monitoring

The hash-chain linkage required by Section 4.3 satisfies post-market monitoring traceability. The chain head MUST be made available to the Provider and to the competent authority on request.¶

5.4. Article 12(2)(c), monitor the operation

Any change to the policy artefact referenced by policy_digest SHALL produce a new digest. A change in policy_digest between two otherwise-comparable Actions MAY be examined by the Deployer or by a regulator as a candidate substantial-modification event under Article 43, and MUST be retained at least as long as the longest receipt in the chain that references either digest.¶

5.5. Retention

Article 12 retention follows the Article 26(6) floor of six months unless national law sets a longer period. Where the Deployer is also a Financial Entity, the DORA floor in Section 7 applies.¶

6.1. Article 26(1), in accordance with the instructions for use

policy_digest MUST resolve to a policy artefact that the Deployer can show, on request, to be consistent with the Provider's instructions for use. An auditor MAY treat inability to resolve policy_digest as evidence of non-compliance for the Action that the receipt records.¶

6.2. Article 26(2), ensure human oversight

For any Action whose decision is allow and whose agent_tier is unknown or absent, the Deployer MUST ensure that the receipt is either reviewed by a designated natural person within the period required by national law, or that a follow-on protectmcp:lifecycle Compliance Receipt records the absence of such review with reason. Both records MUST themselves be Compliance Receipts.¶

6.3. Article 26(5), monitor the operation

A Deployer MUST be able to produce an Audit Pack covering any contiguous time window since the High-Risk AI System became operational.¶

6.4. Article 26(6), keep the logs for at least six months

Compliance Receipts under this binding MUST be retained for at least six months unless Union or national law sets a longer period.¶

7.1. Article 17(1), ICT-related incident management process

A Compliance Receipt produced inside a Financial Entity's ICT environment MAY serve as the canonical record of an Action that triggered an ICT-related incident. action_ref MUST be carried into the Financial Entity's incident workflow as the primary correlation key.¶

7.2. Article 17(2), classify ICT-related incidents

For Actions classified as part of an ICT-related incident, the producing system MUST emit incident_class whose value is drawn from the classification vocabulary in the DORA implementing technical standards.¶

7.3. Article 17(3), records of all ICT-related incidents

The hash chain required by Section 4.3 satisfies tamper-evident logging. The Financial Entity MUST be able to produce, on request, the chain segment covering the period of an incident, together with the anchor evidence that fixes the chain to wall-clock time.¶

7.4. Retention

Compliance Receipts under this binding MUST be retained for the period required by applicable Union or national law, with five years from the date of the underlying Action serving as a common floor consistent with the related ICT record-keeping provisions of [DORA]. Anchor evidence MUST be retained for the same period. Verification keys whose lifetime expires within the retention window MUST have their public components retained so that historical signatures remain verifiable.¶

A Financial Entity SHOULD NOT operate parallel chains of differing retention periods, because the chain linkage required by Section 4.3 forces the longer period to propagate backwards.¶

9.1. Mandatory Checks

A Compliance Verifier MUST perform all of the following checks before treating a receipt as a Compliance Receipt.¶

• Verify the signature using the algorithm declared in signature.alg, in accordance with [ACTA-RECEIPTS].¶
• Resolve the verification key through one of the trust anchor mechanisms required by [ACTA-RECEIPTS]. The verifier MUST NOT trust a verification key embedded in the receipt envelope.¶
• Verify that all fields marked REQUIRED by Section 4 are present and well-formed.¶
• Verify the hash-chain linkage by recomputing the digest of the immediately preceding envelope and comparing it to previousReceiptHash.¶
• Verify at least one anchor: an [RFC3161] token, an [OPENTIMESTAMPS] commitment, or both. The anchor MUST cover the signed envelope as it appears in the receipt.¶
• Verify the issued_at skew bound stated in Section 4.1.2.¶
• Verify that policy_digest resolves in the supplied Audit Pack metadata.¶

A receipt that fails any of these checks MUST be reported as non-conformant.¶

9.2. Optional Checks

A Compliance Verifier MAY additionally perform any of the following.¶

• Cross-check the issuer_id against an external registry of Deployers or Financial Entities.¶
• Resolve the policy artefact referenced by policy_digest and compare it to a Provider-supplied reference policy.¶
• Recompute the chain head and compare it to a Deployer-published value.¶
• Validate incident_class and risk_class extension values against the vocabularies referenced in the Audit Pack.¶

9.3. Reporting

A Compliance Verifier SHOULD produce a structured report that identifies, for each receipt verified, which regime bindings (Article 12, Article 26, DORA Article 17) it satisfies. The report SHOULD itself be signed using the same algorithm registry as [ACTA-RECEIPTS].¶

10.1. Tamper Resistance

The hash-chain linkage required by Section 4.3 provides tamper-evidence at the chain level. An adversary who removes a receipt from the middle of the chain MUST recompute and re-sign every subsequent envelope. The anchor evidence required by Section 4.4 binds segments of the chain to wall-clock time, raising the cost of a re-signing attack.¶

Implementations SHOULD anchor at intervals no longer than 24 hours. Implementations operating under DORA Article 17 SHOULD anchor at intervals no longer than one hour.¶

A deployment that uses only the signature, without chain linkage and anchoring, can be rolled back by an insider with control of the signing key for the period between the deletion and the next anchor. The MUST clauses of Section 4.3 and Section 4.4 close that window.¶

10.2. Key Compromise

A Compliance Receipt is only as trustworthy as the key that signed it. On suspected compromise of an issuer key, the Deployer MUST publish a revocation notice that names the key, the time of suspected compromise, and the chain head at that time. Receipts signed by the compromised key after the named time MUST NOT be treated as Compliance Receipts.¶

Verifiers MUST consult revocation metadata supplied with the Audit Pack and MUST reject Compliance Receipts whose signing key was revoked at or before issued_at.¶

10.3. Retention and Long-Term Verifiability

The five-year retention floor in Section 7 exceeds the typical lifetime of an Ed25519 or ECDSA signing key. Implementations SHOULD use ML-DSA-65 (per [ACTA-RECEIPTS]) for receipts that are expected to be verified after the cryptographic lifetime of classical signature schemes ends. Implementations MUST retain public key material for the entire retention window.¶

10.4. Privacy

[ACTA-RECEIPTS] prohibits the inclusion of raw prompts, tool arguments, and credentials in the signed payload. This profile extends that prohibition to the extension fields defined in this document. The risk_class and incident_class values MUST be drawn from controlled vocabularies and MUST NOT carry free-text personal data.¶

Where the underlying Action references a data subject, the payload_digest field MUST cover the data; the data itself MUST be held in a separate store that respects the data subject's rights under applicable law. A request for erasure that is granted under applicable data protection law MUST be reflected by deletion of the referenced payload, not by deletion of the receipt; the receipt remains as evidence that an Action occurred and was governed by a named policy at a named time.¶

10.5. Anchor Trust

The trust assumptions of an anchor depend on the anchor type. [RFC3161] timestamp tokens depend on the trust placed in the named Time Stamping Authority. OpenTimestamps commitments depend on the inclusion of the commitment in a public Bitcoin block. A Compliance Verifier SHOULD treat the simultaneous presence of both anchor types as stronger evidence than the presence of only one.¶

10.6. Replay

A Compliance Receipt is bound to a single Action via action_ref. Replay of a Compliance Receipt against a different Action is detectable by action_ref mismatch. The 300-second issued_at skew bound stated in Section 4.1.2 limits the window in which a freshly-replayed receipt can be presented as recent.¶

A Compliance Verifier MUST treat two receipts that share the same action_ref and the same issuer_id as a duplicate-emission event and SHOULD investigate.¶

10.7. Cross-Regime Conflict

Where the same Action is in scope of more than one regime addressed by this document, the producing system MUST satisfy the union of the applicable requirements. Where a SHOULD clause in one regime conflicts with a MUST clause in another, the MUST clause prevails. Where two MUST clauses conflict, the producing system MUST refuse to issue the receipt and MUST log the refusal as a protectmcp:lifecycle Compliance Receipt.¶

10.8. Algorithm Agility

This profile inherits its algorithm registry from [ACTA-RECEIPTS]. Implementations MUST treat the verification of a historical receipt according to the algorithm registry that was in force at issued_at, not the registry in force at the time of verification, provided that the signing key was not revoked.¶

11.1. Compliance Receipt Extension Fields Registry

IANA is requested to create a new registry titled "Compliance Receipt Extension Fields" under a new "Compliance Receipts" registry group.¶

Each entry contains:¶

• Field Name: a JSON object key, lowercase ASCII letters, digits, and underscore.¶
• Description: a one-line summary of the field's purpose.¶
• Reference: the document that defines the field's semantics.¶
• Vocabulary: a URL or registry pointer for the controlled vocabulary that field values are drawn from, or "free-form" if none.¶

The registration policy is Specification Required, per [RFC8126]. The Designated Expert(s) SHOULD verify that the field name does not collide with any field defined by [ACTA-RECEIPTS], that the Reference is a stable, dereferenceable specification, and that the Vocabulary is documented sufficiently for an independent verifier to validate values.¶

Initial registry contents:¶

• risk_class - Risk classification term under the Deployer's risk management documentation - This document - Vocabulary referenced in Audit Pack metadata.¶
• incident_class - ICT-related incident classification term per DORA implementing technical standards - This document - DORA implementing technical standards.¶

11.2. Compliance Receipt Type Namespaces Registry

IANA is requested to create a new registry titled "Compliance Receipt Type Namespaces" under the same "Compliance Receipts" registry group.¶

Each entry contains:¶

• Namespace: a colon-separated identifier prefix used as a value of the type field, lowercase ASCII letters, digits, hyphen, underscore, and colon.¶
• Description: a one-line summary of the receipt category.¶
• Reference: the document that defines the namespace.¶

The registration policy is Specification Required, per [RFC8126]. The Designated Expert(s) SHOULD verify that the namespace does not collide with any namespace already registered or any namespace reserved by [ACTA-RECEIPTS], and that the Reference is a stable specification.¶

Initial registry contents:¶

• protectmcp:decision - A receipt recording a policy evaluation outcome (allow, deny, rate_limit) for an MCP-mediated tool call - This document.¶
• protectmcp:restraint - A receipt recording the application or release of a restraint on an agent (e.g., quota, rate limit, sandbox tightening) - This document.¶
• protectmcp:lifecycle - A receipt recording an agent or system lifecycle event (e.g., configuration change, key rotation, oversight review) - This document.¶

draft-marques-asqav-compliance-receipts-00

Initial version. Defines a profile of [ACTA-RECEIPTS] that binds receipt fields to EU AI Act Article 12, EU AI Act Article 26, and DORA Article 17.¶