]> 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 requirements of 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, mandates two-anchor timestamping, 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. 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 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 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 receipt.

This document tracks 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.

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 receipt. A verifier that implements only can still cryptographically validate a profile receipt but cannot attest the additional compliance bindings.

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. provides the wire format. This profile provides the field-level constraints, the retention floor, the anchoring requirement, and the regime mapping.

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(1) of .

Anchor:

An attestation by an independent timestamping or transparency log that a given receipt or batch of receipts existed at a point in time. Anchors covered by this profile are RFC 3161 timestamp tokens and OpenTimestamps commitments.

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 6 through 8 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 byte-for-byte verifiable by a conformant verifier.
• 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 , namely Ed25519 (mandatory-to-implement), ES256, 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 dual-anchoring with RFC 3161 and OpenTimestamps (upstream mentions Sigstore Rekor only as informational), 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.

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.

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.

payload_digest (OPTIONAL upstream, REQUIRED in this profile) REQUIRED for Compliance Receipts. The associated payload that this digest covers MUST be retained for the period mandated by the most restrictive applicable regime in Sections 6 through 8 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. This profile constrains the value to one of enabled, disabled, or unavailable. 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, which is an opaque transport-layer session identifier. A Compliance Receipt MAY carry both: session_id for transport-level correlation and iteration_id for logical-task correlation.

Decision Receipt Fields (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 (lowercase hex SHA-256 of the JSON Canonicalization Scheme encoding of the predecessor receipt). The first receipt in a chain MUST set this field to the all-zero SHA-256 value. Implementations of that do not implement Commitment Mode produce receipts that are not Compliance Receipts under this profile.

Anchoring (No Upstream Equivalent) 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 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 , the timestamping authority's certificate chain MUST be retained alongside the token for the applicable retention window. Where the anchor type is , 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.

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 under the implementing technical standards adopted under .

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

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.

Article 12(2)(b), facilitate the post-market monitoring 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), 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.

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

EU AI Act Article 26 Binding

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.

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.

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 six months unless Union or national law sets a longer period.

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), 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.

Article 17(3), records of all ICT-related incidents The hash chain required by 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.

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 . 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 forces the longer period to propagate backwards.

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.
• The vocabularies referenced by risk_class, incident_class, policy_digest, and any extension fields.
• 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 SHOULD itself be signed using the same algorithm registry as .

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 trust anchor mechanisms required by . 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.
• Verify the issued_at skew bound stated in .
• 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.

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.

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 five-year retention floor in exceeds the typical lifetime of an Ed25519 or ECDSA signing key. Implementations SHOULD use ML-DSA-65 (per ) 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.

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

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. 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 per DORA implementing technical standards - This document - DORA implementing technical standards.

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 T. 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 OpenTimestamps Informative References 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 above receipt satisfies the Article 26 binding because:

• issuer_id resolves to a named Deployer in the Audit Pack;
• policy_digest resolves to a retained policy artefact;
• sandbox_state is enabled, the High-Risk system constraint;
• previousReceiptHash links the receipt into the chain;
• both an anchor and an anchor are present.

A Compliance Verifier processing this receipt under the DORA Article 17 binding would additionally check that the receipt is retained for the five-year window and that the incident_class field, where applicable, is drawn from the implementing technical standards vocabulary.

Change Log

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.