Asqav

Portugal joaoagm90@gmail.com

General AI Agents Audit Trail Compliance EU AI Act DORA This document defines a compliance profile of the signed action receipt format used by AI agents to record machine-readable evidence of access-control decisions. The profile binds receipt fields to the operational record-keeping obligations of Articles 12 and 26 of Regulation (EU) 2024/1689 (the EU AI Act) and to the ICT-related incident management process required by Article 17 of Regulation (EU) 2022/2554 (DORA). It does not redefine the wire format, the canonicalization rule, or the signing algorithms of the underlying receipt format. It tightens a subset of the OPTIONAL fields to REQUIRED, imposes a retention floor, requires at least one timestamping anchor (RFC 3161 or OpenTimestamps; both RECOMMENDED), and adds two extension fields.

Introduction

Profile, Not Fork specifies a generic, signed receipt envelope for recording machine-to-machine access control decisions made by AI agents. Section 2.2 of defines a common payload field set in which all fields except type, issued_at, and issuer_id are OPTIONAL. Section 5.7 of introduces hash chaining (previousReceiptHash) inside an optional Commitment Mode extension. does not define receipt retention, does not require timestamping anchors, and does not bind to any regulatory regime. This document is an additive overlay on : it constrains fields the upstream draft leaves OPTIONAL, fixes their values where regulation requires, and adds two extension fields with reserved names. A Compliance Receipt remains a conformant receipt. Field references use upstream field names rather than section numbers, to reduce maintenance hazard if upstream re-numbers in a future revision.

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. The bindings are written from the Deployer's perspective. Providers of high-risk AI systems are subject to a parallel log-retention obligation under Article 19(1) of the EU AI Act; where a Provider operates the producing system, the same retention rules apply . A verifier that implements only can cryptographically validate a profile receipt but cannot attest the additional compliance bindings of this document.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are used in this document.

Action:

An operation performed by an AI agent that is subject to a policy evaluation. Examples include a tool invocation, an external API call, a write to durable storage, and the issuance of an irreversible instruction to another system.

Action Receipt:

A signed envelope conforming to that records the policy evaluation result for a single Action.

Compliance Receipt:

An Action Receipt that additionally satisfies the requirements of this profile.

Deployer:

As defined in Article 3(4) of .

High-Risk AI System:

As defined in Article 6 of .

Financial Entity:

As defined in Article 2(2) of , for entities listed in Article 2(1).

Audit Pack:

A bundle of Compliance Receipts, the chain commitments that link them, the public verification keys, the trust anchor metadata, and the regime mapping required by Sections 5 through 7 of this document, packaged for delivery to a regulator or auditor.

Relationship to ACTA-RECEIPTS This profile is an additive overlay on . It does not modify the envelope, the canonicalization rule, the signature object, or the algorithm registry of . The following normative statements apply.

• Implementations of this profile MUST produce receipts that are cryptographically verifiable by a conformant verifier under the canonicalization rules (JCS, ) and the signature scope of Section 5.6.
• Implementations of this profile MUST NOT introduce new top-level fields in the signed payload that conflict with names reserved by .
• Implementations of this profile MAY use any signature algorithm permitted by : EdDSA (Ed25519, mandatory-to-implement, ), ES256 (ECDSA using P-256 and SHA-256, ), and ML-DSA-65 ().
• Where marks a field OPTIONAL and this profile marks the same field REQUIRED, the stricter requirement applies to Compliance Receipts.

A receipt that fails any MUST clause of this profile is not a Compliance Receipt. It MAY still be a valid receipt. This profile differentiates from on three axes: mandatory hash-chain linkage (upstream Commitment Mode is OPTIONAL), mandatory anchoring with RFC 3161 or OpenTimestamps (both RECOMMENDED; upstream lists Sigstore Rekor in its Implementation Status appendix as an OPTIONAL temporal anchor), and a retention floor tied to specific regulatory articles (upstream is silent on retention).

Receipt Field Profile This section enumerates fields defined by and states the additional requirements that this profile places on them. Field names follow exactly. Compliance Receipts MUST use the upstream wire field name signature for the signature object, exactly as defined in Sections 2.1 and 2.1.1 of . The keys inside that object are alg, kid, sig. Implementations whose internal storage uses a different field name MUST translate to signature on emission and on canonicalization for verification; receipts that appear on the wire under any other top-level field name are non-conformant to and to this profile. Anchors MUST be projected into a top-level anchors array with a type discriminator and a value field carrying the anchor bytes (base64-encoded for binary payloads). Flat-column implementations MUST project on emission and Audit Pack export.

Common Payload Fields

type Compliance Receipts MUST set type to a value drawn from the namespace protectmcp:decision, protectmcp:restraint, or protectmcp:lifecycle, or to an extension namespace registered for use with this profile.

issued_at REQUIRED upstream and in this profile. The value MUST be an ISO 8601 timestamp with an explicit timezone. The producing system MUST source the value from a clock synchronized to a recognized time authority and MUST NOT backdate the value. Verifiers MUST reject receipts whose issued_at is more than 300 seconds ahead of the verifier's own clock. Verifiers MUST NOT reject a receipt solely because issued_at lies in the past; past skew is bounded by retention (, ), not freshness. Historical receipts within retention MUST verify on the same path as fresh ones.

issuer_id REQUIRED upstream and in this profile. The value MUST identify a legal entity, not a natural person. Where the producing system is operated by a Deployer, the issuer_id MUST resolve, through the trust anchor metadata in the Audit Pack, to a record naming the Deployer. To preserve the upstream Section 2.2 invariant that issuer_id MUST match the kid field of the signature object, Compliance Receipts MUST place the same value in both issuer_id and kid; the verifier resolves that value to a public key through the Audit Pack trust-anchor metadata rather than through the well-known JWK Set endpoint or the RECOMMENDED sb:issuer:<base58-fingerprint> form of Section 2.1.1. This profile thereby supersedes the upstream RECOMMENDED kid format for Compliance Receipts; the upstream RECOMMENDED format remains valid for non-Compliance receipts. Where the Deployer is an EU-regulated entity, implementations SHOULD use the Legal Entity Identifier (LEI) as defined by . Examples and test fixtures MUST use a placeholder whose four-character LOU prefix (positions 1-4) is not allocated in the GLEIF Local Operating Unit code list, whose positions 5-6 are the ISO 17442 reserved value 00, and whose two trailing characters (positions 19-20) are the ISO 7064 mod 97-10 check digits computed over positions 1-18 (for example 00000000000000000098, where the all-zero 18-character base produces the check digits 98 per the ISO 17442-1:2020 Annex A check-digit algorithm, which converts any letters in positions 1-18 to digits A=10 ... Z=35 before the mod 97-10 computation; for an all-zero base the conversion is a no-op); implementations MUST NOT use a real third-party LEI in documentation or test data. Decentralized Identifiers () MAY be used otherwise. Implementations MUST treat the value as opaque on verification; identifier resolution is out of scope for this profile.

payload_digest (OPTIONAL upstream, REQUIRED in this profile) REQUIRED for Compliance Receipts. The value MUST follow the upstream object form (hash, size, optional preview) defined in Section 2.2 of ; this profile does not redefine the wire shape. The associated payload that this digest covers MUST be retained for the period mandated by the most restrictive applicable regime in Sections 5 through 7 of this document. Implementations MUST NOT discard the underlying payload while a receipt that references it is still within its retention window.

action_ref (OPTIONAL upstream, REQUIRED in this profile) REQUIRED for Compliance Receipts. The value is a SHA-256 hash of the canonical Action representation as defined in . This profile uses action_ref as the primary join key for cross-engine reconstruction during an audit.

sandbox_state (OPTIONAL upstream, REQUIRED for High-Risk in this profile) REQUIRED for receipts produced by High-Risk AI Systems. Upstream defines sandbox_state as an OS-level containment status and restricts the value to one of enabled, disabled, or unavailable; this profile inherits that enumeration unchanged. A Deployer that operates a High-Risk AI System and produces a stream of receipts in which sandbox_state is consistently disabled SHOULD treat that stream as a finding under Article 26 and document the rationale in the Audit Pack metadata.

iteration_id (OPTIONAL upstream, REQUIRED for multi-step in this profile) REQUIRED for multi-step agent workflows. The value MUST be stable across all receipts emitted within the same logical task or session so that a regulator can reconstruct the full chain of Actions. iteration_id is distinct from the upstream session_id field defined in Section 3.1.1, which is an opaque MCP session identifier. A Compliance Receipt MAY carry both: session_id for MCP-session correlation and iteration_id for logical-task correlation.

Decision Receipt Fields (type protectmcp:decision) The decision field value MUST be allow, deny, or rate_limit. Implementations using a different internal vocabulary (e.g. permit for allow) MUST normalise on emission and on Audit Pack export. The upstream tool_name field (REQUIRED in Section 3.1.1) is REQUIRED for Compliance Receipts of type protectmcp:decision.

reason (OPTIONAL upstream, REQUIRED for deny/rate_limit in this profile) REQUIRED for Compliance Receipts where decision is deny or rate_limit. The value MUST be a machine-readable reason code drawn from a vocabulary documented in the Deployer's Audit Pack metadata.

policy_digest (OPTIONAL upstream, REQUIRED in this profile) REQUIRED for Compliance Receipts. The value MUST be of the form sha256:<hex> and MUST reference a policy artefact that the Deployer retains for the applicable retention window. Verifiers MUST reject Compliance Receipts whose policy_digest does not resolve in the Audit Pack.

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 Section 5.7 of : the lowercase hex encoding of SHA-256(JCS(receipt)) per , where the receipt covered by the digest is the entire signed receipt object including the signature field. The first receipt in a chain MUST set this field to the all-zero SHA-256 value (this profile's stipulation; Section 5.7 specifies only the digest scope of subsequent links). JSON key is the literal previousReceiptHash (camelCase, case-sensitive); snake_case aliases MUST NOT appear on the wire.

Anchoring (No Upstream Equivalent) lists Sigstore Rekor in its Implementation Status appendix as an OPTIONAL temporal anchor. This profile imposes a normative anchoring requirement. Compliance Receipts MUST be anchored. An anchor is an timestamp token covering the signed envelope, an commitment covering the envelope, or both; implementations SHOULD emit both forms. For both anchor types, the bytes committed are SHA-256(JCS(envelope_minus_anchors)), where envelope_minus_anchors is the wire envelope object with the anchors top-level key removed prior to canonicalization, leaving the two-key object {payload, signature}. The anchors key MUST be removed from the object, not set to null or to an empty array; these produce different JCS output and break interoperability (mirroring the upstream Section 5.6 stripping rule). The anchor thereby binds payload and signature without being self-referential. 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. An anchor MAY be attached after issuance if the receipt is persisted with an unambiguous pending marker and the anchor lands within a documented bound. For , this profile imposes a 7-day deadline; this is a profile-imposed bound, not a property of the OpenTimestamps protocol, whose calendar-to-block upgrade time depends on the calendar operator's publication interval. tokens MUST be obtained synchronously. A verifier MUST treat a pending receipt as non-conformant once the bound elapses. 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 , the full TimeStampResp DER bytes MUST be retained, sufficient for offline verification by a holder with access to the TSA's published public key. Time-stamp tokens carrying ESSCertIDv2 per MUST be accepted by Compliance Verifiers. Where the anchor type is , the upgrade from the initial calendar attestation to the Bitcoin block attestation MUST be completed within the 7-day profile-imposed bound, and the upgraded proof MUST be retained for the applicable retention window per the second paragraph of this section.

Extension Fields This profile defines two extension fields that MAY appear in the signed payload alongside the fields defined by . 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. Binding classification criteria are drawn from . The reporting templates are bound by , whose Annex II data glossary, field 3.23 (Type of the incident) defines the canonical six-value enumeration: Cybersecurity-related, Process failure, System failure, External event, Payment-related, Other (please specify). Implementations MAY refine the set, provided the flattened mapping in the Audit Pack manifest () projects each refinement to one of the six canonical values.

risk_class MUST be encoded as a JSON string. incident_class MUST be encoded as a JSON string drawn from the canonical six-value enumeration defined above, OR as a JSON array of such strings to preserve the "Choice (multiple)" semantics of Annex II field 3.23 of . Both extension fields appear inside the signed payload object and are therefore covered by the upstream Section 5.6 signature scope. Both fields are OPTIONAL at the syntactic level but MAY be REQUIRED by the regime bindings in Sections 5 through 7 of this document. Implementations MAY define additional extension fields. Such fields MUST NOT collide with names defined by or by this document. Implementations defining extension fields SHOULD register them in the registry described in .

EU AI Act Article 12 Binding Each subsection cites the operative phrase of Article 12 and binds it to the receipt field that satisfies it.

Article 12(1), automatic recording of events Article 12(1) requires High-Risk AI Systems to technically allow for the automatic recording of events (logs) over the lifetime of the system. The signed-receipt format provides one mechanism that satisfies that logging capability; alternative mechanisms remain valid. Where this profile is chosen, a Compliance Receipt SHOULD be produced for every Action against an external resource, and a configuration change that disables receipt generation SHOULD be recorded as a protectmcp:lifecycle Compliance Receipt. Implementations MAY emit at finer or coarser granularity so long as the log set, taken together, satisfies Article 12(2)(a) through (c).

Article 12(2)(a), identifying situations that may result in the high-risk AI system presenting a risk within the meaning of Article 79(1) or in a substantial modification 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.

Article 12(2)(b), facilitating the post-market monitoring referred to in Article 72 The hash-chain linkage required by satisfies post-market monitoring traceability. The chain head MUST be made available to the Provider and to the competent authority on request.

Article 12(2)(c), monitoring the operation of high-risk AI systems referred to in Article 26(5) Any change to the policy artefact referenced by policy_digest MUST 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.

Retention Article 12 itself sets no retention period; the operative deployer floor is Article 26(6) ("at least six months"), with the parallel provider floor in Article 19(1). Unless Union or national law sets a longer period, this profile expresses that floor as 184 days from the date of the Action: 184 is the maximum number of days in any rolling six-calendar-month window (worst case Aug-Jan, 31+30+31+30+31+31), so retention of 184 days satisfies "at least six months" regardless of the calendar months over which the window falls. Implementations that prefer the more common 183-day pick MAY use 183 days and remain conformant with Article 26(6) so long as per-receipt retention is at least six months from the Action date. Where the Deployer is also a Financial Entity, the sectoral floor in applies.

EU AI Act Article 26 Binding

Article 26(1), in accordance with the instructions for use policy_digest MUST resolve through to a retained artefact (machine check). The Deployer SHOULD demonstrate consistency with the Provider's instructions for use (process check). Inability to perform the machine check is presumed non-compliance.

Article 26(2), assign human oversight For any Action whose decision is allow and which the Deployer's risk management documentation marks as requiring human oversight, 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 a reason code. Both records MUST themselves be Compliance Receipts. This profile addresses the trigger and record of oversight; the competence, training, authority, and necessary support of the reviewer required by Article 26(2) remain the Deployer's separate responsibility.

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.

Article 26(6), keep the logs for at least six months Compliance Receipts under this binding MUST be retained for at least the period stated in . Where the Deployer is also a Financial Entity, the longer sectoral floor in applies.

DORA Article 17 Binding

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.

Article 17(2), record all ICT-related incidents and significant cyber threats The hash chain required by supports the recording obligation of Article 17(2) by making after-the-fact alteration of recorded incidents detectable. 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.

Article 17(3)(b), establish procedures to identify, track, log, categorise and classify ICT-related incidents For Actions identified as part of an ICT-related incident, the producing system MUST emit incident_class. The classification criteria are those set out in Article 18(1) of , with further specification in . The canonical reporting enumeration to which incident_class flattens is bound by Annex II field 3.23 of (see ). Implementations MUST publish a flattened mapping in the Audit Pack manifest as required by .

Retention Article 17 of does not itself set a uniform numeric retention floor. The five-year (1827-day) figure used by this profile derives from sectoral instruments that overlap DORA-scoped Financial Entities. Investment firms keep records of all services, activities and transactions under Article 16(6) of , with Article 72 and Annex I of fixing the form and content of those records. The explicit five-year retention period in is set by Article 16(7) for records of telephone conversations and electronic communications, kept for a period of five years and, where requested by the competent authority, for a period of up to seven years. Records of customer due diligence and of transactions under Article 40 of are kept for five years after the end of the business relationship. The AMLD record-keeping regime is superseded, in respect of record retention, by Article 77 of from 10 July 2027, which preserves the five-year floor and adds a case-by-case extension up to a further five years where the competent authority so requires. Implementations operating across the AMLD-to-AMLR transition MUST satisfy whichever instrument is in force on the date of the Action. Compliance Receipts MUST be retained for the period required by applicable Union or national law; where a sectoral floor applies, retention MUST equal or exceed the longest applicable floor. Absent a more specific rule, this profile RECOMMENDS 1827 days from the date of the Action (the worst-case rolling five-calendar-year window contains two leap days, so 1827 days satisfies "five years" regardless of the calendar years over which the window falls). 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.

Audit Pack Composition This section is informative. It describes the contents of an Audit Pack as introduced in . An Audit Pack contains the following items.

• The set of Compliance Receipts covered by the requested time window, in the canonical envelope form defined by .
• The chain commitments that link the receipts: for each receipt, the value of previousReceiptHash and the recomputed digest of the predecessor envelope.
• The anchor evidence: tokens, OpenTimestamps proofs, or both. Each anchor item MUST be associated, by hash, with the receipt or aggregate it covers.
• The trust anchor metadata that identifies the Deployer or Financial Entity associated with each issuer_id value.
• The verification key material for every kid value present, in a form that does not require online retrieval.
• Vocabularies referenced by reason, risk_class, incident_class, and extension fields, embedded as JSON arrays with a stable identifier. The Audit Pack MUST expose a digest-resolution facility that, given a policy_digest, returns the retained artefact.
• A regime mapping document that names which receipts the producer asserts as evidence under Article 12, Article 26, or DORA Article 17.
• The chain heads valid at the start and end of the time window, signed by the Deployer or Financial Entity.

An Audit Pack MUST itself be signed per the algorithm registry. The manifest MUST include bundle_digest, bundle_signature, bundle_public_key, and algorithm_registry_version.

Verifier Behaviour A verifier conformant to this profile is referred to as a Compliance Verifier.

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 .
• Resolve the verification key through one of the key-distribution mechanisms described in Section 4.3 of (well-known JWK Set or out-of-band distribution), or through Audit Pack trust-anchor metadata. The verifier MUST NOT trust a verification key embedded in the receipt envelope.
• Verify that all fields marked REQUIRED by 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 token, an commitment, or both. The anchor MUST cover the signed envelope as it appears in the receipt. The verifier MUST cryptographically re-verify the anchor against the signed envelope; presence of anchor metadata without a successful cryptographic check MUST NOT yield "valid".
• Verify the future-skew bound on issued_at per . Past skew MUST NOT cause non-conformance when the receipt is within retention.
• Verify that policy_digest resolves through . A digest computed over a nonced or otherwise mixed-input form (for example, SHA-256(nonce || JCS(artefact))) MUST NOT be treated as policy_digest; the digest scope is the canonical form of the artefact alone. The verifier MUST recompute SHA-256 over the canonical form of the resolved artefact as documented in the Audit Pack manifest, and compare; for JSON artefacts the canonical form is JCS per .

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

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 (each element if encoded as an array) and risk_class extension values against the vocabularies referenced in the Audit Pack.

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 .

Security Considerations This profile inherits all of the security considerations of . The following considerations are specific to the compliance binding.

Tamper Resistance The hash-chain linkage required by 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 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 and close that window.

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.

Retention and Long-Term Verifiability The 1827-day retention floor in exceeds the typical operational crypto-period of a signing key under recommended key-management practice. Implementations SHOULD use ML-DSA-65 from the algorithm registry () for receipts expected to be verified after the cryptographic lifetime of classical signature schemes ends. Implementations MUST retain public key material for the entire retention window.

Privacy 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.

Anchor Trust The trust assumptions of an anchor depend on the anchor type. 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.

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 limits the window in which a freshly-replayed receipt can be presented as recent. Where the verifier supports it, two receipts sharing action_ref and issuer_id SHOULD be flagged as a candidate duplicate-emission event for human review. This profile does not require verifiers to maintain a cross-receipt index; deployers needing duplicate-emission detection should arrange it at the Audit Pack production layer.

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.

Algorithm Agility This profile inherits its algorithm registry from . 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.

IANA Considerations This document requests two new IANA registries to support stable, machine-checkable extensions to the Compliance Receipt format.

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. This registry covers both signed-payload fields and envelope-level fields (siblings of payload and signature); each entry's Description identifies which. 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 . The Designated Expert(s) SHOULD verify that the field name does not collide with any field defined by , 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, criteria per Article 18(1) of with further specification in , canonical six-value enumeration per Annex II field 3.23 of - This document - Audit Pack metadata.
• anchors - Envelope-level array of timestamp / transparency-log anchors covering the signed envelope; entries carry a type discriminator (rfc3161 or opentimestamps) and a value field - This document - Anchor type vocabulary: rfc3161 per , opentimestamps per .

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 . The Designated Expert(s) SHOULD verify that the namespace does not collide with any namespace already registered or any namespace reserved by , 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.

Acknowledgements The author thanks Tom Farley for , on which this profile is built. This profile would not exist without the field catalogue and envelope structure that the upstream draft defines. The author also thanks the Asqav community for review of early drafts.

Normative References National Institute of Standards and Technology OpenTimestamps ISO W3C Informative References European Parliament and Council European Parliament and Council European Commission European Commission European Parliament and Council European Commission European Parliament and Council European Parliament and Council

Worked Example (Informative) This appendix illustrates a Compliance Receipt that satisfies the Article 26 binding for a tool invocation by a High-Risk AI System deployed by a Financial Entity. Field values are abbreviated for readability and are not cryptographically valid. The example shows a mid-chain receipt; a chain-genesis receipt would carry a previousReceiptHash of 64 zero hex characters per . The above receipt satisfies the Article 26 binding because:

• issuer_id is a 20-character ISO 17442 Legal Entity Identifier (LEI) that resolves through the trust anchor metadata in the Audit Pack to the named Deployer;
• policy_digest resolves to a retained policy artefact;
• sandbox_state is enabled, satisfying the High-Risk system constraint of ;
• previousReceiptHash links the receipt into the chain per ;
• both an anchor and an anchor are present per .

Under the DORA Article 17 binding a Compliance Verifier additionally checks the longest applicable sectoral retention floor (1827 days as the default, per ) and, where present, that incident_class flattens to the canonical six-value vocabulary referenced in .

Change Log

draft-marques-asqav-compliance-receipts-02 Wire-shape alignment with upstream : receipt content wrapped in a payload object with signature and anchors as top-level siblings per Section 2.1; payload_digest object form per Section 2.2; action_ref as bare hex per Section 2.2; tool_name REQUIRED for protectmcp:decision per Section 3.1.1; issuer_id equal to kid per Section 2.2; chain hash scope is the entire signed receipt per Section 5.7. EU AI Act bindings use Official Journal wording: Article 12(1) framed as a logging capability obligation; Article 12(2)(a), (b), (c) headings match the OJ; Article 26(6) "at least six months" expressed as 184 days (with 183-day pick permitted as conformant). Article 19(1) provider parallel noted in scope. DORA Article 17 bindings: 17(2) recording obligation supported by hash chain; 17(3)(b) classification criteria sourced to Article 18(1) of with further specification in ; incident_class canonical six-value enumeration sourced to Annex II field 3.23 of . Sectoral retention: Article 16(7) of (five-year floor on telephone and electronic communications records); Article 16(6) supplemented by Article 72 of (form and content of general records); Article 40 of superseded by Article 77 of from 10 July 2027. Anchoring: anchor MUST (at least one of an RFC 3161 token or an OpenTimestamps commitment); both RECOMMENDED; the 7-day deadline for OpenTimestamps upgrade is profile-imposed. LEI placeholder rules require an unallocated GLEIF LOU prefix at positions 1-4, the ISO 17442 reserved value 00 at positions 5-6, and ISO 7064 mod 97-10 check digits at positions 19-20. Algorithm references added: (EdDSA), (ES256), (ML-DSA-65). Added (ESSCertIDv2) as a normative reference; Compliance Verifiers MUST accept ESSCertIDv2-carrying time-stamp tokens. Reference block uses Official Journal verbatim titles (including "(recast)" for and "(Text with EEA relevance)" where the OJ carries it) and OJ publication dates throughout. Definition of "Financial Entity" cites Article 2(2) of , the paragraph that establishes the collective term, with cross-reference to Article 2(1) for the entity list. Article 12(2)(a)/(b)/(c) headings now use the OJ participle form. and moved to Normative References, since the issuer-id rule invokes them through SHOULD/MAY clauses governing wire-level identifier shape. IANA Extension Fields registry now includes anchors with the rfc3161 / opentimestamps anchor-type vocabulary. DORA-bound retention default is 1827 days (worst-case five-calendar-year window with two leap days), aligning the methodology with the 184-day six-month figure used in . Section 4.1.7 describes upstream session_id as an MCP session identifier (not transport-layer), matching Section 3.1.1. Section 4.2 names the decision field explicitly. Section 7.4 notes that AMLD supersession by Article 77 of is in respect of record retention. Section 4.1.4 states that payload_digest follows the upstream object form (hash, size, optional preview) defined in Section 2.2 of . Section 9.1 policy_digest recomputation rule generalised: SHA-256 over the canonical form of the resolved artefact as documented in the Audit Pack manifest, with JCS specified for JSON artefacts. Section 9.2 optional check on incident_class validates each element when the field is encoded as an array. DORA Article 17(3)(b) section heading expanded to include "establish procedures to" per the OJ wording. EU AI Act Article 26(2) prose no longer cites Article 14 (the competence/training/authority phrase comes from Article 26(2) directly). Worked example notes that the receipt shown is mid-chain. "Decentralized" spelling aligned with the W3C reference title. Anchor concept defined inline in Section 4.4 rather than as a Conventions term, removing capitalisation drift. Section 9.1 verification step on the verification key now references Section 4.3 of directly (well-known JWK Set or out-of-band) rather than the looser "trust anchor mechanisms required by upstream" wording. Section 4.1.3 names the upstream kid mechanisms (well-known JWK Set or sb:issuer:<base58-fingerprint>) being superseded for Compliance Receipts. Section 6.2 Article 26(2) prose includes "necessary support" alongside competence, training, and authority, matching OJ wording. Section 4.5 anchoring rule names the bytes committed (SHA-256 of the JCS-canonicalized envelope excluding the anchors array). Section 6.4 cross-refs the longer DORA sectoral floor when the Deployer is a Financial Entity. Section 4.1.3 LEI placeholder rule references the ISO 17442-1:2020 Annex A letter-to-digit conversion that precedes mod 97-10. Upstream draft author full name corrected to "Tom Farley".

draft-marques-asqav-compliance-receipts-01 Initial wire-shape alignment with upstream and addition of dual-anchor, hash-chain, retention, and DORA classification bindings. Subsequent revisions superseded the specific values introduced here.

draft-marques-asqav-compliance-receipts-00 Initial version. Defines a profile of that binds receipt fields to EU AI Act Article 12, EU AI Act Article 26, and DORA Article 17.