Asqav

Portugal joaoagm90@gmail.com

General AI Agents Audit Trail Compliance EU AI Act DORA NIST AI RMF Colorado AI Act HIPAA NYDFS CIRCIA This document defines a multi-jurisdiction 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 two regulatory surfaces: the European Union obligations of Articles 12 and 26 of Regulation (EU) 2024/1689 (the EU AI Act) and Article 17 of Regulation (EU) 2022/2554 (DORA), and the United States obligations of the NIST Artificial Intelligence Risk Management Framework, the Colorado Artificial Intelligence Act (SB 24-205), the Texas Responsible AI Governance Act (HB 149), the New York Department of Financial Services Cybersecurity Regulation (23 NYCRR Part 500), the HIPAA Security Rule (45 CFR Part 164, Subpart C), SEC Rule 17a-4 (17 CFR 240.17a-4), and the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA). 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 on two surfaces. Section 5 binds the receipt to European Union obligations: Article 12 (record-keeping) and Article 26 (deployer obligations) of the EU AI Act, and Article 17 (ICT-related incident management) of DORA. Section 6 binds the receipt to United States obligations: the voluntary functions of the NIST AI Risk Management Framework, the deployer obligations of the Colorado AI Act and the Texas Responsible AI Governance Act, the audit-trail and incident-reporting obligations of NYDFS Part 500, the audit controls and documentation retention of the HIPAA Security Rule, the broker-dealer recordkeeping requirements of SEC Rule 17a-4, and the covered-incident reporting requirements of CIRCIA. The bindings are written from the Deployer's perspective, where Deployer is used in the regime-specific sense (Article 3(4) of for EU bindings; Section 6-1-1701(6) of the Colorado Revised Statutes for Colorado bindings). Where another statute uses a different term (Provider, Financial Entity, Covered Entity for HIPAA, Covered Entity for NYDFS, Broker-Dealer for SEC, Covered Entity for CIRCIA), the binding section names the term as the source statute uses it. 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 (EU AI Act):

As defined in Article 3(4) of .

Deployer (Colorado AI Act):

As defined in Section 6-1-1701(6) of the Colorado Revised Statutes, as enacted by .

High-Risk AI System (EU AI Act):

As defined in Article 6 of .

High-Risk AI System (Colorado AI Act):

As defined in Section 6-1-1701(9) of the Colorado Revised Statutes, as enacted by .

Financial Entity:

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

Covered Entity (HIPAA):

As defined in 45 CFR 160.103, namely a health plan, a health care clearinghouse, or a health care provider that transmits health information in electronic form in connection with a covered transaction.

Covered Entity (NYDFS):

As defined in 23 NYCRR 500.1(e), namely any person operating under or required to operate under a license, registration, charter, certificate, permit, accreditation or similar authorization under the Banking Law, the Insurance Law or the Financial Services Law, regardless of whether the covered entity is also regulated by other government agencies.

Broker-Dealer:

As defined in section 3(a)(4) and 3(a)(5) of the Securities Exchange Act of 1934, subject to recordkeeping under .

Covered Entity (CIRCIA):

As to be defined in the final rule promulgated under the Cyber Incident Reporting for Critical Infrastructure Act of 2022. Pending publication of the final rule, the term is interpreted in accordance with the statutory definition at 6 U.S.C. 681 and CISA's notice of proposed rulemaking.

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 and 6 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 the applicable retention floor in Sections 5 and 6, not by 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. Implementations SHOULD use a Legal Entity Identifier (LEI) as defined by where one is allocated to the Deployer. 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. Where no LEI is allocated and the Deployer is a US entity, an Employer Identification Number (EIN) issued by the United States Internal Revenue Service or a Central Index Key (CIK) issued by the United States Securities and Exchange Commission MAY be used, expressed as the bare numeric string. 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 and 6 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 under either or . 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 the applicable risk-management documentation requirement (Article 9 of for the Provider's risk management system, with which a Deployer operating per Article 26(1) is required to be consistent; Section 6-1-1703(2) of the Colorado Revised Statutes) 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. Where the Deployer operates under , the documentation is the Provider's Article 9 risk management system as referenced via the instructions for use under Article 26(1); where the Deployer operates under , the documentation is the Section 6-1-1703(2) risk management policy and program.

incident_class:

A vocabulary term identifying the incident classification of the Action under the applicable regime: an ICT-related incident under , with classification criteria in and the canonical six-value reporting enumeration in Annex II data glossary, field 3.23 (Type of the incident) of (Cybersecurity-related, Process failure, System failure, External event, Payment-related, Other (please specify)); a Cybersecurity Event under 23 NYCRR 500.1(f) (or, where the §500.17(a) reporting threshold is met, a Cybersecurity Incident under 23 NYCRR 500.1(g)) for Covered Entities of ; a Covered Cyber Incident under once the final rule takes effect; or a security incident under 45 CFR 164.304 for Covered Entities of . Implementations MAY refine the set, provided the flattened mapping in the Audit Pack manifest () projects each refinement to the applicable canonical category for each in-scope regime.

risk_class MUST be encoded as a JSON string. incident_class MUST be encoded as a JSON string drawn from the canonical vocabulary referenced in the Audit Pack, OR as a JSON array of such strings to preserve cross-regime classification (for example, a single Action that is both a DORA ICT-related incident and a CIRCIA Covered Cyber Incident, or both a NYDFS Cybersecurity Incident and a CIRCIA Covered Cyber Incident). 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 and 6 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 .

European Union Bindings

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.

United States Bindings

NIST AI RMF Binding is a voluntary framework. Adoption of this profile, on its own, does not establish conformity with the AI RMF; it provides a tamper-evident receipt substrate that an AI RMF program can use as evidence under the MEASURE function and as a structured input to the GOVERN, MAP, and MANAGE functions. applies the AI RMF functions to generative AI; the profile bindings below apply to generative and non-generative AI agent deployments alike unless explicitly noted.

GOVERN function The GOVERN function requires that organizations document AI policies and procedures. The combination of policy_digest and the Audit Pack manifest provides a machine-readable binding between every Action and the policy artefact in force at the time of the Action. A change to the policy artefact MUST produce a new policy_digest value (per ); the Audit Pack therefore records every policy change in a tamper-evident manner.

MAP function The MAP function requires that the context, capabilities, and risks of an AI system be characterised. The combination of type, tool_name, action_ref, and iteration_id SHOULD be sufficient for an auditor to reconstruct the operational context of any Action without dereferencing the underlying payload.

MEASURE function The MEASURE function requires that AI risks and impacts be analysed and tracked over time. The hash-chain linkage required by provides tamper-evident continuity of the receipt stream over the AI system's operational lifetime, satisfying the traceability prerequisite of MEASURE.

MANAGE function The MANAGE function requires that AI risks be prioritised and acted upon based on projected impact. The risk_class extension field carries the Deployer's risk classification of the Action; together with decision, reason, and policy_digest, it supports prioritisation and incident response without requiring the verifier to re-derive risk from the underlying payload.

Colorado AI Act (SB 24-205) Binding imposes deployer obligations effective June 30, 2026 (per Senate Bill 25B-004, which postponed the original February 1, 2026 effective date). The Act regulates the deployment of High-Risk AI Systems and the prevention of algorithmic discrimination.

Section 6-1-1703(2), risk management policy and program Section 6-1-1703(2) requires deployers to implement a risk management policy and program for the High-Risk AI System. policy_digest MUST resolve through to the deployer's risk management policy artefact in force at the time of the Action. Where the Deployer classifies an Action as risk-bearing under that policy, the receipt MUST carry a risk_class extension field.

Section 6-1-1703(3), impact assessment Section 6-1-1703(3) requires deployers to complete an impact assessment annually and within 90 days after any intentional and substantial modification of the High-Risk AI System. The combination of type, policy_digest, and previousReceiptHash MUST be sufficient for an auditor to identify, by query alone, the receipts that span the period covered by an impact assessment, including any policy changes within that period.

Section 6-1-1703(7), notice of algorithmic discrimination Where a Deployer determines that a High-Risk AI System has caused or is reasonably likely to have caused algorithmic discrimination, the producing system SHOULD record that determination as a protectmcp:lifecycle Compliance Receipt naming the determination, the affected receipts by action_ref, and the policy or risk-management response with a reason code.

Texas Responsible AI Governance Act (HB 149) Binding takes effect January 1, 2026. The Act adopts an intent-based liability framework for the development and deployment of AI systems and provides a safe harbor at Section 552.105(e)(2)(D) of the Texas Business and Commerce Code for organisations that substantially comply with the most recent version of , or another nationally or internationally recognized risk management framework for AI systems, and operate an internal review process.

Safe-harbor evidentiary support Where a Deployer relies on the safe-harbor provision of HB 149 by substantially complying with , the Audit Pack MAY be presented as evidence of that compliance. The bindings of apply, with the additional Generative AI Profile bindings of .

Prohibited-use detection Receipts whose decision is deny with a reason code drawn from a vocabulary documenting the Act's prohibited-use categories under Section 552.052 of the Texas Business and Commerce Code added by HB 149 (incitement or encouragement of physical self-harm including suicide, harm to another person, or engagement in criminal activity) MUST be retained for the period stated in or the longer period required by Texas law, whichever is greater.

HIPAA Security Rule Binding (45 CFR Part 164, Subpart C) applies to Covered Entities (HIPAA) that handle electronic protected health information. The bindings below apply only to receipts whose underlying Actions reference electronic protected health information.

45 CFR 164.312(b), audit controls 45 CFR 164.312(b) requires implementation of "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information". The combination of type, action_ref, tool_name, and the hash-chain linkage required by satisfies the recording requirement; the verification rules of satisfy the examination requirement.

45 CFR 164.316(b)(2)(i), six-year retention 45 CFR 164.316(b)(2)(i) requires that the documentation required by 45 CFR 164.316(b)(1) be retained "for 6 years from the date of its creation or the date when it last was in effect, whichever is later". This profile expresses that floor as 2192 days from the later of (a) the date of the Action and (b) the date the policy artefact referenced by policy_digest ceased to be in effect: 2192 is the maximum number of days in any rolling six-calendar-year window (worst case spans two leap days, e.g. 2024-2030 contains February 29 of 2024 and 2028, yielding 6*365+2 = 2192 days). Verification keys whose lifetime expires within the retention window MUST have their public components retained so that historical signatures remain verifiable.

NYDFS Cybersecurity Regulation Binding (23 NYCRR Part 500) applies to Covered Entities (NYDFS) operating under New York Banking, Insurance, or Financial Services Law. The bindings below apply only to receipts produced by such Covered Entities.

23 NYCRR 500.6, audit trail 23 NYCRR 500.6(a) requires Covered Entities to securely maintain systems that, to the extent applicable and based on its risk assessment, (1) are designed to reconstruct material financial transactions, and (2) include audit trails designed to detect and respond to cybersecurity events that have a reasonable likelihood of materially harming any material part of the normal operations of the Covered Entity. The hash chain required by together with the anchor evidence required by satisfies the tamper-evidence prerequisite of the audit-trail obligation.

23 NYCRR 500.17, notices to superintendent 23 NYCRR 500.17(a)(1) requires that "Each covered entity shall notify the superintendent electronically in the form set forth on the department's website as promptly as possible but in no event later than 72 hours after determining that a cybersecurity incident has occurred at the covered entity, its affiliates, or a third-party service provider." The reporting trigger is a Cybersecurity Incident under 23 NYCRR 500.1(g), not any Cybersecurity Event under 500.1(f). For Actions identified as part of such an Incident, the producing system MUST emit incident_class with a value indicating Cybersecurity Incident under 23 NYCRR 500.1(g), and the Covered Entity MUST be able to produce, on request, the chain segment covering the period of the Incident together with the anchor evidence that fixes the chain to wall-clock time.

23 NYCRR 500.6 retention 23 NYCRR 500.6(b) requires that "Each Covered Entity shall maintain records required by this section for not fewer than five years." The five-year floor applies uniformly to records required by paragraph (a)(1) (designed to reconstruct material financial transactions) and to records required by paragraph (a)(2) (audit trails designed to detect and respond to cybersecurity events that have a reasonable likelihood of materially harming any material part of the normal operations of the Covered Entity). Compliance Receipts produced under this binding MUST be retained for at least 1827 days from the date of the Action (the worst-case rolling five-calendar-year window contains two leap days).

SEC Broker-Dealer Recordkeeping Binding (17 CFR 240.17a-4) applies to Broker-Dealers, Security-Based Swap Dealers, and Major Security-Based Swap Participants. The bindings below apply only to receipts produced inside such entities.

17 CFR 240.17a-4(f), electronic recordkeeping system The November 3, 2022 amendments to 17 CFR 240.17a-4 (compliance date May 3, 2023) added an audit-trail alternative to the prior write-once-read-many (WORM) electronic recordkeeping requirement. The audit-trail alternative requires that the electronic recordkeeping system permit the recreation of an original record if it is modified or deleted. The hash-chain linkage required by together with the retention rule in and the anchor evidence required by satisfies the audit-trail alternative when the Compliance Receipt is the system-of-record for a regulated record.

17 CFR 240.17a-4(a) and (b) retention 17 CFR 240.17a-4(a) requires preservation of certain records for not less than 6 years, the first two years in an easily accessible place. 17 CFR 240.17a-4(b) requires preservation of a different list of records for not less than three years, the first two years in an easily accessible place. Compliance Receipts that constitute or support a record listed in 17 CFR 240.17a-4(a) MUST be retained for at least 2192 days from the date of the Action, applying the same six-year worst-case methodology as ; receipts that constitute or support a record listed only in 17 CFR 240.17a-4(b) MUST be retained for at least 1096 days from the date of the Action (the worst-case rolling three-calendar-year window contains one leap day). Where both apply, the longer period applies.

CIRCIA Binding (Cyber Incident Reporting for Critical Infrastructure Act of 2022) requires Covered Entities (CIRCIA) to report Covered Cyber Incidents to the Cybersecurity and Infrastructure Security Agency within 72 hours of reasonable belief that the incident has occurred, and to report ransom payments within 24 hours. The reporting obligations take effect upon publication of the final rule. Pending publication, the bindings below apply on a voluntary basis.

Covered Cyber Incident reporting support For Actions identified as part of a Covered Cyber Incident, the producing system MUST emit incident_class with a value indicating Covered Cyber Incident under . The Covered Entity MUST be able to produce, on request, the chain segment covering the period of the incident together with the anchor evidence that fixes the chain to wall-clock time.

Records related to a Covered Cyber Incident report Section 2242(a)(4) of the Homeland Security Act of 2002, as enacted by and codified at 6 U.S.C. 681b(a)(4), requires Covered Entities to preserve data relevant to a Covered Cyber Incident or ransom payment in accordance with procedures established in the final rule. CISA's notice of proposed rulemaking at 89 FR 23644 (April 4, 2024) proposes a preservation period of not less than two years; this profile uses that proposed floor pending publication of the final rule. Compliance Receipts that are referenced in a CIRCIA report or that the Covered Entity reasonably anticipates will be so referenced MUST be retained for the longer of the period established by the final rule and 731 days from the date of the Action (2*365+1 leap day worst case).

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 other regulated 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 any of the regimes addressed by Sections 5 and 6 of this document (EU AI Act Article 12, EU AI Act Article 26, DORA Article 17, NIST AI RMF, Colorado AI Act, Texas Responsible AI Governance Act, NYDFS Part 500, HIPAA Security Rule, SEC Rule 17a-4, CIRCIA).
• The chain heads valid at the start and end of the time window, signed by the Deployer or other regulated 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 (LEI, EIN, CIK, NPI, GLEIF, or a Deployer-published list).
• Resolve the policy artefact referenced by policy_digest and compare it to a Provider-supplied or Deployer-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 it satisfies, drawn from the regimes listed in . 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, 23 NYCRR 500.17, or SHOULD anchor at intervals no longer than one hour, given the 72-hour reporting deadlines of those regimes. 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 longest retention floor in this profile is 2192 days (six calendar years), set by and ; the EU side has a parallel five-year (1827-day) floor under . Both exceed 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 (including but not limited to the General Data Protection Regulation for EU data subjects, the California Consumer Privacy Act and Virginia Consumer Data Protection Act for the corresponding US states, and the HIPAA Privacy Rule where electronic protected health information is involved). 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 - Incident classification term spanning DORA Article 18(1) (with further specification in and the canonical six-value enumeration in Annex II field 3.23 of ), 23 NYCRR 500.1 Cybersecurity Event/Incident, Covered Cyber Incident, and HIPAA security incident under 45 CFR 164.304 - 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 National Institute of Standards and Technology National Institute of Standards and Technology State of Colorado, Seventy-Fourth General Assembly State of Texas, 89th Legislature, Regular Session United States Department of Health and Human Services New York State Department of Financial Services United States Securities and Exchange Commission Effective date January 3, 2023; compliance date for amendments to 17 CFR 240.17a-4 May 3, 2023. United States Cybersecurity and Infrastructure Security Agency

Worked Example (Informative) This appendix illustrates a Compliance Receipt that satisfies the EU AI Act Article 26 binding for a tool invocation by a High-Risk AI System deployed by a Financial Entity. The wire shape applies identically to United States bindings; the only differences are the values placed in issuer_id (LEI, EIN, or CIK depending on the regime) and in the risk_class and incident_class vocabularies referenced in the Audit Pack manifest. 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 . Under the United States bindings of Section 6 the same verifier additionally checks the longest applicable retention floor (2192 days as the default for receipts under or ) and, where the Deployer is a NYDFS Covered Entity, a HIPAA Covered Entity, or a CIRCIA Covered Entity, that incident_class resolves to the applicable canonical category for each in-scope regime.

Change Log

draft-marques-asqav-compliance-receipts-03 Multi-jurisdiction consolidation. The European Union profile (formerly the only profile in -02) and the United States profile (formerly the separate draft draft-marques-asqav-us-compliance-receipts-00) are merged into a single document with two regional bindings sections: Section 5 (European Union) and Section 6 (United States). Sections 1 through 4 (Introduction, Conventions, Relationship to upstream, Receipt Field Profile) and Sections 7 through 11 (Audit Pack, Verifier, Security, IANA, Acknowledgements) are shared across both regimes. Conventions terms that differ across regimes are now disambiguated with regime suffixes (Deployer (EU AI Act) vs Deployer (Colorado AI Act); High-Risk AI System (EU AI Act) vs High-Risk AI System (Colorado AI Act)). The incident_class extension field now lists every applicable canonical category in one place: ICT-related incident under with the Annex II reporting enumeration, Cybersecurity Event/Incident under , Covered Cyber Incident under , and security incident under . The issuer_id rule now permits EIN or CIK as alternatives to LEI for US Deployers without an allocated LEI. The Tamper Resistance security consideration extends the one-hour anchoring SHOULD to NYDFS 500.17 and CIRCIA in addition to DORA Article 17. The Privacy security consideration extends to GDPR for EU data subjects and CCPA / VCDPA / HIPAA Privacy Rule for US data subjects. The Worked Example notes that the wire shape applies identically to US bindings, with only the issuer_id identifier and the vocabularies differing. IANA registries are unchanged; the Initial registry contents for incident_class now describe the multi-regime category set. No changes to the wire format, the field profile, the hash chain, the anchoring rules, the Audit Pack contents, or the Verifier checks. Section 4.1.6 (sandbox_state) and Section 4.5 (risk_class) corrected to attribute the EU risk-management documentation requirement to Article 9 of (Provider's risk management system) rather than Article 26, with Article 26(1) cited as the deployer's instructions-for-use obligation that links to the Provider's Article 9 documentation. Section 6.5.3 (nydfs-retention) corrected to a single-tier five-year floor under 23 NYCRR 500.6(b) (verified verbatim against LII Cornell); the prior tiered 5-year/3-year split (claimed against the DFS Second Amendment) was incorrect because the Second Amendment does not amend §500.6, leaving the 2017 single-tier text in force. The 1096-day three-year audit-trail floor previously stated for NYDFS is removed.

draft-marques-asqav-compliance-receipts-02 Submission-ready EU-only profile. Wire-shape alignment with upstream (payload/signature/anchors envelope; payload_digest object form; tool_name REQUIRED for protectmcp:decision; issuer_id equals kid). EU AI Act and DORA bindings authored against Official Journal text. Anchor MUST (at least one of RFC 3161 or OpenTimestamps); both RECOMMENDED; 7-day OpenTimestamps upgrade deadline profile-imposed. Six-month AI Act floor expressed as 184 days; DORA-bound default expressed as 1827 days. IANA registries created.

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.