Compliance Profile of Signed Action Receipts for AI Agents

1.1. Profile, Not Fork

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

This document is an additive overlay on [ACTA-RECEIPTS]: it constrains fields the upstream draft leaves OPTIONAL, fixes their values where regulation requires, and registers a set of extension fields with reserved names spanning regulatory classification, cross-agent envelope binding, per-action freshness and integrity, build provenance, threat-framework taxonomy, and server-built enforcement-control records. The full extension-field set is defined in Section 5.6 and the sections that follow it. A Compliance Receipt remains a conformant [ACTA-RECEIPTS] receipt. Field references use upstream field names rather than section numbers, to reduce maintenance hazard if upstream re-numbers in a future revision.¶

1.2. Scope

This document fills the regulatory binding gap on two surfaces. Section 6 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 7 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 [EU-AI-ACT] 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 [ACTA-RECEIPTS] can cryptographically validate a profile receipt but cannot attest the additional compliance bindings of this document.¶

5.1. Common Payload Fields

5.2. Decision Receipt Fields (type protectmcp:decision)

The decision field value MUST be allow, deny, rate_limit, or observation. Implementations using a different internal vocabulary (e.g. permit for allow) MUST normalise on emission and on Audit Pack export. The observation value records that an Action was observed and the receipt was signed without any policy evaluation having taken place; it is the regulator-honest alternative to emitting allow when no policy matched, and MUST NOT appear in a receipt of type protectmcp:decision. A producing system that has not evaluated a policy for an Action MUST either refuse to issue a Compliance Receipt for that Action or MUST emit the receipt with decision observation under type protectmcp:lifecycle or any registered namespace of the observation path listed in Section 12.2 (including protectmcp:observation and its sub-namespaces); in the latter case the upstream policy_decision internal field, if present in the producing system's internal vocabulary, takes the literal value none, which the emitter MUST map to observation on the wire. Verifiers MUST reject a Compliance Receipt that carries decision observation together with type protectmcp:decision; conversely, a Compliance Receipt of type protectmcp:lifecycle MAY carry decision observation in addition to the other three vocabulary values. The policy_digest requirement of Section 5.2.2 applies to observation receipts in the form of a digest of the producing system's "no policy matched" sentinel policy artefact, which the Deployer MUST retain alongside its other policy artefacts for the applicable retention window.¶

The upstream tool_name field (REQUIRED in [ACTA-RECEIPTS] Section 3.1.1) is REQUIRED for Compliance Receipts of type protectmcp:decision.¶

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

Upstream Commitment Mode introduces previousReceiptHash as part of an optional extension. This profile makes the linkage REQUIRED. Receipts in this profile have the envelope shape {payload, signature, anchors}: every signed field lives inside the payload member, and the signature and anchors members sit beside it, outside the signed content. Implementations MUST emit a previousReceiptHash field, populated with the lowercase hex encoding of SHA-256(JCS(R)), where R is the payload member of the immediately prior receipt emitted by the same issuer_id and JCS denotes the canonicalization of [RFC8785]: the digest covers R, NOT the envelope object that additionally includes the signature or anchors top-level keys. This digest scope is a deliberate override of upstream's "Chain Hash Scope" section (Section 5.7 of [ACTA-RECEIPTS]), which requires the digest of the entire signed receipt object including the signature field; this profile digests the predecessor's payload member instead. The signature scope follows from the envelope shape: in the JSON framing (mandatory-to-implement per Section 5.7.1), the signature in the signature member verifies over the JCS-canonical serialization of the payload member and nothing else; COSE-framed and JWS-framed receipts inherit their signature scope from [RFC9052] and [RFC7515] respectively, with the payload member carried as the COSE payload or the JWS payload. Upstream's "Signature Scope" section (Section 5.6 of [ACTA-RECEIPTS]) is internally inconsistent on this point - it first requires the signature to cover the canonical JCS bytes of the payload directly, then redefines the payload as the receipt object with the signature field removed - and this profile follows the first sentence, as upstream Section 4.1 does. The [SCOPEBLIND] corpus documents both readings in the wild (Section 9). The first receipt in a chain MUST set this field to the all-zero SHA-256 value (this profile's stipulation; upstream's "Chain Hash Scope" section (Section 5.7 of [ACTA-RECEIPTS]) 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.¶

Rationale for digesting R rather than the envelope-including-signature object: the chain layer's purpose is to make after-the-fact alteration of the predecessor's signed content detectable, and the predecessor's signed content is exactly R, the bytes its signature covers. Digesting R binds the chain to what A actually attested to and is recomputable offline from the predecessor's payload alone. The chain does not need to bind the predecessor's signature value directly because the predecessor's signature is verified independently under Section 10.2, and cross-agent envelope integrity (where binding the peer's signature value matters) is the role of counterparty_binding per Section 5.7, which digests at the envelope-including-signature scope precisely because the peer signature is the load-bearing artefact in the cross-agent case. Because this section deliberately overrides the upstream digest scope, implementations that previously digested the envelope-including-signature object MUST migrate to SHA-256(JCS(R)) before emitting chained receipts under this profile; verifiers MUST recompute SHA-256(JCS(R)) when checking previousReceiptHash.¶

Each issuer MUST maintain a single linear per-agent chain. When one agent identity emits receipts from multiple concurrent execution paths (for example parallel tool calls dispatched within a single agent loop, or fan-out work performed by a thread pool inside one issuer), the issuer MUST serialize emission through a single predecessor pointer at a time: each newly emitted receipt's previousReceiptHash MUST resolve to SHA-256(JCS(R)) for the immediately prior receipt emitted by that same issuer_id (R as defined at the start of this section), taken in emission order, regardless of which concurrent execution path produced it. Parallel sub-chains within one agent identity (for example, a per-receipt chain_id discriminator that would partition one issuer's stream into multiple independently advancing chains) are NOT defined by this profile. An issuer that requires parallel sub-chains MUST express each parallel path as a distinct agent identity, with its own issuer_id value, its own signing key, and its own per-agent chain rooted at the all-zero SHA-256 genesis value. Rationale: deterministic verification of the chain segment covering an audit window, as required by the regime bindings of Sections 6 and 7 (in particular Section 6.3.2, Section 7.5.1, and Section 7.6.1), depends on a single linear total order over the receipts emitted under each agent identity. A verifier reconstructing the chain from a regulator-supplied issuer_id needs that ordering to be well-defined without out-of-band metadata.¶

Interoperability note: receipts of this profile chain over the payload member R, whereas receipts of the bare [ACTA-RECEIPTS] format chain over the whole-receipt object that includes the signature; the two wire formats are distinguished by the Asqav-only anchors key. The normative scope rule is the one defined in this section. The published conformance vectors asqav-03-chain-link (payload scope) and acta-02-chain-link (whole-receipt scope) corroborate it byte-for-byte and are published in the asqav-sdk repository ([ASQAV-SDK], maintained by this draft's author and commit-pinned in the reference below), so an implementer or independent verifier choosing between the two scopes need not maintain one fixture set per candidate scope.¶

5.4. Anchoring (No Upstream Equivalent)

[ACTA-RECEIPTS] 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 [RFC3161] timestamp token, an [OPENTIMESTAMPS] commitment, or both, and in every case commits the same bytes, defined in this paragraph; 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 (the remove-don't-null rule of upstream's "Signature Scope" section, Section 5.6 of [ACTA-RECEIPTS], applied here at the anchor layer). 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 [OPENTIMESTAMPS], 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. [RFC3161] 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 [RFC3161], 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 [RFC5816] MUST be accepted by Compliance Verifiers. An rfc3161 anchor MAY be obtained from a Time-Stamping Authority operated independently of the issuer (for example a public RFC 3161 TSA under a distinct trust root) in addition to, or instead of, an issuer-operated TSA. The independently operated TSA is the genuinely independent witness referenced in Section 11.7, and is one of the N witnesses of witness_policy rather than ever the sole anchor. Where the anchor type is [OPENTIMESTAMPS], 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.¶

Each entry in the top-level anchors array is an object with the following members.¶

type:

REQUIRED string discriminator. MUST be one of rfc3161 or opentimestamps.¶

value:

REQUIRED on every anchor entry. The anchor token bytes, base64-encoded. For rfc3161 the value is the base64 encoding of the full TimeStampResp DER bytes (sufficient for offline cryptographic re-verification by a holder with access to the TSA's published public key). For opentimestamps the value is the base64 encoding of the OpenTimestamps proof blob (the .ots serialization). A verifier MUST cryptographically re-verify the anchor against the signed envelope using these bytes per Section 10.2; anchor entries served without value MUST NOT be reported as anchor_valid_*=true.¶

status:

OPTIONAL informational string. When present, MUST be one of anchored (the anchor has reached its final attestation state: an [RFC3161] token has been obtained, or an [OPENTIMESTAMPS] commitment has upgraded to its Bitcoin block attestation), pending (the anchor has been requested but the final attestation state has not yet been reached, e.g. an OpenTimestamps commitment that has been submitted to a calendar but has not yet upgraded to a Bitcoin block within the 7-day bound of this section), or failed (the anchor submission was attempted and did not produce a usable attestation, e.g. a TSA returned an error response or an OpenTimestamps calendar refused the commitment). status is operational metadata; a verifier MUST NOT derive cryptographic validity from status alone, and MUST always re-verify the value bytes per Section 10.2.¶

anchor_block_hash:

OPTIONAL informational string. The Bitcoin block hash at which an [OPENTIMESTAMPS] commitment was anchored. Present only on entries with type=opentimestamps and status=anchored; absent on rfc3161 entries and on pending or failed OpenTimestamps entries. anchor_block_hash is operational metadata; a verifier MUST NOT derive cryptographic validity from anchor_block_hash alone, and MUST always re-verify the value bytes against the OpenTimestamps proof per Section 10.2.¶

witness_policy is an OPTIONAL signing-time declaration the producer gives the issuing platform with the signing request; it is NOT a wire member of the receipt, and the envelope has exactly the three top-level keys of Section 5.3. It declares an N-of-M durable-anchoring quorum over the receipt's anchors array. Because the declaration is not carried in the receipt, there is no policy member an intermediary can lower, rewrite, or strip after signing: the receipt's only anchoring record is the anchors array itself, covered by the signature scope and committed by every anchor. witness_policy is an object with two members: required, a REQUIRED integer in the closed range [1, length of witnesses]; and witnesses, a REQUIRED non-empty JSON array whose values are a subset of the anchor type vocabulary {rfc3161, opentimestamps}. The witnesses array MUST NOT contain duplicate values and MUST NOT contain any value outside that vocabulary; in particular a transparency-log pointer such as Rekor is NOT a witness type and MUST be rejected if it appears in witnesses. The policy declares that the receipt's durable anchoring is satisfied only when at least required distinct witness types named in witnesses each hold a verifiable inclusion proof, that is, an anchor entry of that type whose value bytes re-verify against SHA-256(JCS(envelope_minus_anchors)) per Section 10.2 and, for opentimestamps, has upgraded to its Bitcoin block attestation within the 7-day bound of this section.¶

A receipt reaches the quorum-met state (the reference implementation reports this as witness_quorum_met) only when the count of distinct witness types satisfying the preceding paragraph is greater than or equal to required. A Compliance Receipt MUST NOT assert that durable anchoring has been achieved, and a producer MUST NOT set or report witness_quorum_met, unless required witnesses each hold a real, verifiable inclusion proof; an anchors entry with status=pending or status=failed, or with absent or non-verifying value bytes, does NOT count toward the quorum. This is the same false-attestation principle that governs the rest of this profile: a receipt MUST NOT claim a cryptographic property it cannot prove from retained bytes, and a verifier MUST recompute the quorum from the re-verified anchors entries rather than trust any producer-asserted quorum flag. The reference cloud implementation enforces the quorum honesty rule at signing time and publishes it as the witness_policy_required_exceeds_confirmed guard in its /.well-known/governance.json wire-vocabulary surface. witness_policy places no constraint on receipts signed without such a declaration; the baseline single-anchor requirement of this section continues to apply to every Compliance Receipt regardless of whether witness_policy was declared at signing time.¶

5.5. Signer-Outage Evidence (unsigned_gap)

This section is normative. The hash chain of Section 5.3 links the receipts that exist and is silent about Actions for which no receipt could be minted, so a chain verifies perfectly across a signer outage. An issuing platform that fails to mint a receipt for an Action because its signer was unavailable MUST tally that failure and MUST carry the tally in the unsigned_gap member of the signed payload of the next receipt it successfully mints for that issuer. The member is an object with three REQUIRED members. count is a JSON integer greater than or equal to 1. from and to are ISO 8601 timestamps with explicit timezone bounding the outage, where from is not later than to. The member is absent when no outage precedes the receipt, so receipts minted in normal operation are unchanged.¶

The tally MUST be cleared only when a receipt carrying it has been signed. A signing attempt refused for an authorization reason (a revoked or suspended agent identity, or a failed policy gate) is NOT a signer outage and MUST NOT be tallied. Such refusals are decisions, evidenced under Section 5.2. The member is server-built in the sense of Section 5.10: a caller-supplied value MUST be dropped before signing. A verifier MUST NOT read it as evidence that the unsigned Actions were policy-evaluated.¶

5.6. Extension Fields

This profile registers extension fields across seven groupings that MAY appear in the signed payload object alongside the fields defined by [ACTA-RECEIPTS]: (a) regulatory classification fields (risk_class, incident_class) defined in this section; (b) the cross-agent envelope-binding field counterparty_binding defined in Section 5.7; (c) per-action validity-window and integrity fields (result_digest, expires_at, nonce, tool_fingerprint, config_manifest_digest, cve_inventory_digest) and build-provenance fields (executable_hash, sbom_digest, slsa_provenance_pointer, supply_chain_pointer) defined in Section 5.8 and Section 5.9; (d) server-built enforcement-control record fields (authorized_under_mandate, controls_evaluated) defined in Section 5.10; (e) producer-asserted risk-acceptance fields (approver_id, initiator_id, acceptance_reason, accepted_at, supersedes, sarif_digest, finding_ref, approval_ref, risk_snapshot) defined in Section 5.11; (f) producer-asserted code-authorship fields (repo_ref, commit_sha, base_sha, change_digest, change_ref, change_approval_ref, change_class, authored_by) defined in Section 5.12; and (g) self-declared threat-framework taxonomy fields (mitre_techniques, mitre_atlas, owasp_llm_top10, nist_ai_rmf, iso_42001, eu_ai_act_articles), the opaque caller-supplied rfc3161_timestamp token, and the platform-set guard framework_mappings_self_declared defined in Section 5.13. All extension fields appear inside the signed payload object and are therefore covered by the signature scope defined in Section 5.3.¶

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 [EU-AI-ACT], 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 [COLORADO-AI-ACT], 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 [DORA], with classification criteria in [REG-2024-1772] and the canonical reporting enumeration of Annex II data glossary, field 3.23 (Type of the incident) of [REG-2025-302] (verifiers MUST resolve the canonical values from the regulation directly); a Cybersecurity Event under 23 NYCRR 500.1(f) (or, where the Section 500.17(a) reporting threshold is met, a Cybersecurity Incident under 23 NYCRR 500.1(g)) for Covered Entities of [NYDFS-500]; a Covered Cyber Incident under [CIRCIA] once the final rule takes effect; or a security incident under 45 CFR 164.304 for Covered Entities of [HIPAA-SECURITY]. Implementations MAY refine the set, provided the flattened mapping in the Audit Pack manifest (Section 9) 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 fields are OPTIONAL at the syntactic level but MAY be REQUIRED by the regime bindings in Sections 6 and 7 of this document.¶

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

5.7. Counterparty Binding

This section is normative. counterparty_binding is an in-payload object an acknowledging agent ("B") emits to carry a cryptographic digest of the full signed envelope of an originating agent ("A"). It provides cross-agent byte-equality evidence when a shared intermediary sits between two honest agents and the per-agent hash chains of Section 5.3 validate independently regardless of whether B's observed bytes equal A's signed bytes. action_ref is a correlation anchor, not a cryptographic binding ([ACTA-RECEIPTS] Section 2.2); counterparty_binding moves the evidence onto B's own COSE or JWS signature, which the verifier already trusts.¶

"counterparty_binding": {
  "envelope_hash": "bDqg...5PE=",
  "receipt_ref": "asqav-receipt://org/123/agent_A/seq/4811",
  "expect_ack_from": "00000000000000000098",
  "transport_label": "mcp"
}

5.8. Result-Bound and Validity-Window Extensions

This section is normative. It defines six OPTIONAL extension fields that may appear inside the signed payload object to bind the receipt to the byte-equality of a downstream result, to bound the validity window of a decision, to declare the tool and configuration that produced the action, and to record the supply-chain Common Vulnerabilities and Exposures (CVE) inventory in effect at signing time. The fields are independently OPTIONAL; an implementation MAY emit any subset. All six are covered by the signature scope defined in Section 5.3.¶

result_digest:

OPTIONAL object of the same shape as payload_digest defined in Section 2.2 of [ACTA-RECEIPTS]: REQUIRED string hash formatted sha256:<64 lowercase hex chars>, REQUIRED integer size in bytes, OPTIONAL string preview. The digest covers the canonicalized bytes of the downstream Action's result body (response payload, tool output, model completion). The field is emitted on a follow-up protectmcp:observation:result_bound receipt that references the originating protectmcp:decision via action_ref; a verifier processing a result-bound observation MUST treat a digest mismatch between result_digest and the verifier's local recomputation over retained result bytes as a non-conformance condition. Result bytes covered by result_digest are subject to the same retention floor as the originating decision receipt under Sections 6 and 7.¶

expires_at:

OPTIONAL ISO 8601 timestamp with explicit timezone, encoded as a JSON string. Declares the wall-clock time after which the producing system considers the decision result stale and not safe to replay. The field provides the upper bound of the decision's validity window, additive to the 300-second forward-skew bound on issued_at of Section 5.1.2; expires_at bounds replay safety from above, the forward-skew rule bounds emission honesty from above. The window is declared, not enforced, by this field: enforcement against a replaying action is the verifier's and the Deployer's obligation under the next paragraph, and the receipt record itself never expires. A verifier MUST reject a downstream action that replays a decision whose expires_at lies in the past relative to the replay's wall clock; verifiers MUST NOT reject the originating receipt itself solely because expires_at has elapsed (the receipt remains valid as a record of the decision at issued_at).¶

nonce:

OPTIONAL JSON string carrying a producer-generated value that is unique across the producer's emission stream for the lifetime of the cryptographic key identified by kid. The field SHOULD be the lowercase hexadecimal encoding of 12 random bytes (24 hexadecimal characters). Verifiers SHOULD reject a second receipt that carries the same nonce under the same issuer_id as a replay candidate; the rejection is informational where the bound action is idempotent and load-bearing where the bound action is not. The field is OPTIONAL at the syntactic level but is a SHOULD-emit for any producer whose downstream actions are not idempotent. The nonce is NOT a challenge-response freshness proof: it is generated by the producer, not an unpredictable challenge generated and retained by the party appraising the evidence, so it proves uniqueness of emission and supports replay-candidate flagging, nothing more.¶

tool_fingerprint:

OPTIONAL JSON string of 32 lowercase hexadecimal characters carrying the first 32 hexadecimal characters (128 bits) of the SHA-256 digest over the JCS canonicalization ([RFC8785]) of the JSON object {"tool_name": <tool name>, "schema": <declared input schema>}, where schema is the JSON object form of the tool's declared input schema (an empty object when the tool declares none). The field binds a receipt to a specific tool identity; a verifier or auditor reproducing the Action can detect tool drift (the same tool name with a different declared schema) by comparing fingerprints across receipts in the same chain, and a fingerprint change under an unchanged tool name surfaces naming collisions and registry shadowing. The field is OPTIONAL and complementary to action_ref: action_ref identifies the call, tool_fingerprint identifies the callee.¶

config_manifest_digest:

OPTIONAL JSON string formatted sha256:<64 lowercase hex chars> over the canonical bytes of the producer's configuration manifest in effect at the time the Action was signed. The manifest content is operator-defined and SHOULD include the producer's policy bundle reference, model identifiers and versions, prompt template digests, retrieval index identifiers, and any other inputs whose change would constitute a substantial modification of the producing system under Article 43 of [EU-AI-ACT] or under Section 6-1-1701 of [COLORADO-AI-ACT]. Because the manifest content is operator-defined, an operator's manifest MAY include an attestation or appraisal digest among its inputs; this profile registers no dedicated field for one. The field is OPTIONAL but, when emitted, SHOULD resolve through the Audit Pack to retained manifest bytes for the duration of the longest applicable retention floor in Sections 6 and 7.¶

cve_inventory_digest:

OPTIONAL JSON string formatted sha256:<64 lowercase hex chars> over the canonical bytes of the producer's CVE inventory at the time the Action was signed. The inventory content SHOULD list the CVE identifiers known to apply to the producer's executing image and its declared runtime dependencies, plus the producer's accepted-residual rationale per [EU-AI-ACT] Article 15 robustness obligations or the equivalent obligations under Sections 6 and 7. The field binds a snapshot of the producer's known-vulnerability surface to the receipt; a regulator examining the receipt can resolve the digest through the Audit Pack to the canonical inventory bytes that were in effect when the Action was signed, rather than relying on a later-time inventory that may have been updated after the Action was performed.¶

Implementations emitting result_digest SHOULD use the dedicated protectmcp:observation:result_bound type registered in Section 12.2 for the follow-up receipt that carries the bound digest. Implementations MAY emit expires_at, nonce, tool_fingerprint, config_manifest_digest, and cve_inventory_digest on any receipt type defined by this profile; the fields are type-agnostic.¶

Two type-bound presence rules attach to the fields of this section. The reference cloud implementation rejects at signing time, as the configuration_change_missing_config_manifest_digest guard, a receipt of type protectmcp:lifecycle:configuration_change (registered in Section 12.2) that lacks a well-formed config_manifest_digest; and it rejects at signing time, as the result_bound_missing_result_digest guard, a receipt of type protectmcp:observation:result_bound that lacks a well-formed result_digest.¶

Layering note on the validity window: this profile places the validity-window bounds in the receipt itself. nonce and expires_at ride inside the signed payload, and the conformant verifier enforces them: the expires_at replay rejection is a mandatory check of Section 10.2, and a verifier that maintains a seen-nonce index flags duplicate emissions on the duplicate_emission_candidate axis of Section 10.4. Enforcement of the nonce uniqueness bound requires that seen-nonce state and is therefore conditional; enforcement against replay of an expired decision is an application decision point the verifier's rejection feeds. Section 14.1 of [DRAFT-SOKOLOV-AEP-COMPOSITION] reports that in that composition the freshness check was enforced outside the conformant Verifier, in the application's own appraisal step; a producer composing that pattern with this profile SHOULD emit nonce and expires_at so the receipt layer carries the bounds.¶

5.9. Build-Provenance Extensions

This section is normative. It defines four OPTIONAL extension fields that bind the receipt to the supply-chain provenance of the executable that produced the Action. The four fields form a layered subsumption set: executable_hash binds the running binary, sbom_digest binds the dependency manifest the binary was built from, slsa_provenance_pointer resolves to the SLSA attestation envelope for that build, and supply_chain_pointer resolves to a transparency-log entry (in-toto, Sigstore, or Rekor) covering the build. An implementation MAY emit any subset. All four are covered by the signature scope defined in Section 5.3.¶

executable_hash:

OPTIONAL JSON string formatted sha256:<64 lowercase hex chars> over the canonical bytes of the executable that invoked the Action. For container-based producers the canonical bytes are the immutable image manifest digest of the running image (the value an OCI registry returns under the same name plus tag, computed under the OCI Image Manifest Specification). For non-container executables the canonical bytes are the SHA-256 of the on-disk binary file at the path the producer's runtime resolved. The field binds build-side provenance into the signed receipt: a regulator examining the receipt can recover the exact executable identity that produced the Action without trusting any side-channel attestation. A verifier MAY cross-check executable_hash against the executable identity declared in the SLSA attestation resolved through slsa_provenance_pointer; mismatch SHOULD be reported as an axis flag rather than as non-conformance because the two fields may identify the same artefact under different addressing schemes.¶

sbom_digest:

OPTIONAL JSON string formatted sha256:<64 lowercase hex chars> over the canonical bytes of the Software Bill of Materials (SBOM) document covering the executing image. The canonical form MUST be either CycloneDX (any 1.x specification version, JSON form, with the canonicalization rule defined by CycloneDX itself) or SPDX (version 2.x or later, JSON form, with the canonicalization rule defined by SPDX itself); the producer SHOULD record the chosen format and version in the Audit Pack manifest entry for the receipt so a verifier can recompute the digest. The field complements executable_hash: executable_hash identifies the artefact, sbom_digest identifies the dependency closure of that artefact.¶

slsa_provenance_pointer:

OPTIONAL JSON string carrying an https URL that resolves to the Supply-chain Levels for Software Artifacts (SLSA) provenance attestation envelope for the build that produced the executable identified by executable_hash. The pointer target SHOULD be the SLSA Provenance v1.0 in-toto statement form; producers MAY emit earlier SLSA versions where toolchain support is incomplete, and verifiers SHOULD accept any SLSA version they implement. The field shifts the trust root for build-side provenance off the producer's self-attestation and onto the build platform's attestation; the verifier's confidence in the resolved attestation is bounded by the verifier's trust in the build platform's signing root.¶

supply_chain_pointer:

OPTIONAL JSON string carrying an https URL that resolves to a transparency-log entry covering the build that produced the executable identified by executable_hash. The pointer target SHOULD be an in-toto attestation, a Sigstore entry, or a Rekor entry, in that preference order where the producer can choose; verifiers SHOULD accept any of the three. The field provides a transparency-log-backed audit path for the build, independent of the SLSA attestation envelope referenced by slsa_provenance_pointer; the two fields are complementary because a transparency-log entry attests inclusion under a public log, while a SLSA attestation attests build-platform output bytes.¶

The four fields are type-agnostic and MAY appear on any receipt type defined by this profile. Where a Deployer operates under a regulatory regime that requires build-side traceability (Article 12 of [EU-AI-ACT] read together with Article 17 of [DORA]; the audit-controls obligation of 45 CFR 164.312(b) of [HIPAA-SECURITY]; the recordkeeping rule of [SEC-17A-4] read with [NYDFS-500] 23 NYCRR 500.6), the Deployer SHOULD emit at least executable_hash on every protectmcp:decision receipt and SHOULD retain the SBOM, the SLSA attestation, and the transparency-log entry through the longest applicable retention floor in Sections 6 and 7.¶

5.10. Enforcement-Control Record Extensions

This section is normative. It defines two OPTIONAL extension fields that record, inside the signed payload object, which authorization and enforcement controls the issuing platform genuinely evaluated when it signed the receipt. Both fields are server-built: they are populated by the issuing platform at signing time, never carried in the producer's signing request, and a caller-supplied value for either field MUST be dropped by the issuing platform before signing. Both fields are covered by the signature scope defined in Section 5.3. The design rule for both fields is omission-over-false attestation: a control that did not run is represented by the absence of its key, never by a present key asserting a result the control did not produce. The same omission discipline extends to freshness (informatively): a deployment that cannot perform an external freshness check inside the party that appraises evidence records that limitation by the absence of any freshness assertion, never by treating an affirming result as fresh. The two fields each carry a false-attestation guard that rejects a present-but-malformed attestation, in the same spirit as the framework_mappings_self_declared guard of Section 5.13 and the witness_policy quorum guard of Section 5.4. The key set of this section is closed: both fields are server-built, unknown keys MUST be rejected, and this section does not convey remote attestation results.¶

authorized_under_mandate:

OPTIONAL object recording that the Action was signed under a self-declared authorizing mandate. The object carries four members: mandate_id (REQUIRED string, the issuer-scoped identifier of the mandate the Action was authorized under), issuer_id (REQUIRED string, the identifier of the party that issued the mandate, in the bare-identifier form required by Section 5.1.3), scope_digest (REQUIRED string formatted sha256:<64 lowercase hex chars> over the canonical bytes of the mandate's authorized-action-types scope), and verified (REQUIRED boolean). The trust semantics are deliberately narrow: verified=true asserts self-declared issuer authority, the same trust level as framework_mappings_self_declared of Section 5.13, and is NEVER an issuing-platform attestation of verified third-party authorization. The mandate binding is self-declared by the issuer, is evaluated against the issuing platform's own clock at signing time, and scopes the Action to a set of authorized action types; this profile does NOT define a value cap, a counterparty restriction, or any other constraint on the mandate, and a verifier MUST NOT infer one from the presence of this field. A verifier resolves scope_digest by retrieving the mandate identified by mandate_id through the Audit Pack or a Deployer-published mandate index and recomputing the digest over the canonical scope bytes; a mismatch MUST be reported as a non-conformance condition. The false-attestation guard for this field, published as false_mandate_attestation_guard in the issuing platform's wire vocabulary, rejects an authorized_under_mandate object that is present but does not carry all of mandate_id, issuer_id, verified=true, and a well-formed scope_digest: a present-but-malformed attestation is rejected at signing time rather than signed and surfaced as truth.¶

controls_evaluated:

OPTIONAL object enumerating the enforcement controls that genuinely fired when the issuing platform signed the Action, plus the allow result. The member keys are drawn from a closed set: emergency_halt, delegation_scope, quorum, mandate, policy, content_scan, and result; an unknown key MUST be rejected. Each control key is present ONLY when its control actually ran on this sign; an absent key means the control never ran on this sign, and a verifier MUST NOT infer from an absent key that the control ran and passed silently. The quorum member, when present, MUST carry fired=true together with a 64-lowercase-hex attestation_hash proving the quorum evaluation; the policy member, when present and asserting a policy was evaluated, MUST carry matched_count greater than or equal to 1. The false-attestation guard for this field, published as false_control_attestation_guard in the issuing platform's wire vocabulary, rejects a present-but-malformed controls_evaluated object: an unknown control key, a quorum member lacking fired=true plus a 64-hex attestation_hash, or a policy member asserting evaluation without matched_count greater than or equal to 1, is rejected at signing time. Because the field is server-built and a caller-supplied controls_evaluated is dropped before signing, a verifier MAY treat the enumerated keys as the issuing platform's own record of which controls it ran.¶

Both fields are type-agnostic and MAY appear on any receipt type defined by this profile, though they are most commonly emitted on protectmcp:decision receipts where an authorization or enforcement evaluation produced the recorded decision. Neither field replaces the policy-evaluation honesty rule that an issuing platform MUST NOT assert a control ran when it did not (the design note carried under Section 11): controls_evaluated records which controls ran, not that any control blocked, and an absent control key is the conformant representation of a control that did not run.¶

5.11. Risk-Acceptance Extensions

This section is normative. It defines OPTIONAL extension fields that appear inside the signed payload object of a receipt of type protectmcp:lifecycle:risk_acceptance (registered in Section 12.2), which records a producer's decision to accept a known risk, security finding, or policy exception. A risk-acceptance receipt is a lifecycle record, not a policy-evaluation outcome: it is emitted through the no-policy lifecycle path of Section 5.2, carries decision observation, and asserts that no policy was evaluated for the acceptance. The fields are covered by the signature scope and the previousReceiptHash chain link of Section 5.3, and by the anchors timestamp of Section 5.4; taken together these prove only that the producer asserted these values, key-authored them, and chained them at the receipt's issued_at. The receipt does NOT make any accepted risk safe, any snapshot value true, reproducible, or verified, or any declared expiry enforced. The scope-honesty labels in the field definitions below are normative and mirror the labels published in the issuing platform's /.well-known/governance.json wire-vocabulary surface.¶

approver_id:

REQUIRED JSON string carrying the producer-asserted identity that authored the risk acceptance, in the bare-identifier form of Section 5.1.3 (a bare kid or issuer_id). The field is bound into the signed bytes only: the issuing platform performs NO authority check, NO authentication of the named identity, and NO identity resolution; the only comparison it makes is the compliance_mode string-equality refusal against initiator_id (the risk_acceptance_self_approval_guard of the initiator_id entry below). A risk-acceptance receipt that omits approver_id MUST be rejected at signing time by the false-attestation guard named in Section 12.1.¶

initiator_id:

OPTIONAL JSON string carrying the producer-asserted identity that requested the acceptance, in the same bare-identifier form. The field is bound into the signed bytes only. The reference cloud implementation refuses at signing time, as the risk_acceptance_self_approval_guard, a risk-acceptance receipt signed under compliance_mode whose initiator_id string-equals approver_id, because a receipt asserting an approval flow approved by its own initiator is incoherent on its face. The guard is a string-incoherence check (case-sensitive exact match), NOT identity resolution: it fires only when both fields are present, an absent field never fires it, and any real segregation-of-duties decision belongs to the Deployer's enforcement layer, not to this record format.¶

acceptance_reason:

REQUIRED JSON string carrying the free-text producer rationale for accepting the risk. The field proves that the rationale existed and was key-authored at issued_at; it is never parsed, scored, or validated by the issuing platform. A risk-acceptance receipt that omits acceptance_reason MUST be rejected at signing time by the same false-attestation guard as approver_id.¶

accepted_at:

OPTIONAL ISO 8601 timestamp with explicit timezone, encoded as a JSON string, carrying the producer-asserted wall-clock time at which the acceptance was authored. This value is self-declared by the producer; the only times the issuing platform attests are issued_at (Section 5.1.2) and the anchors evidence (Section 5.4). The field is distinct from issued_at so that an acceptance back-dated relative to emission is auditable.¶

supersedes:

OPTIONAL JSON string carrying a producer-asserted pointer to the prior risk-acceptance receipt this one replaces, encoded either as an opaque receipt locator or as a sha256:<64 lowercase hex chars> digest. The field proves that the supersession claim existed at issued_at; resolution is the verifier's job, and the issuing platform NEVER invalidates the prior receipt: the hash chain of Section 5.3 is immutable and supersedes is a forward pointer only.¶

sarif_digest:

OPTIONAL JSON string formatted sha256:<64 lowercase hex chars> over the producer-declared canonical bytes of the static-analysis (SARIF) scan artifact the acceptance rested on. The digest is a shape-only existence proof: it proves THAT the named SARIF artifact existed unaltered at issued_at and nothing more. The issuing platform NEVER parses, fetches, re-runs, or validates the scan; a verifier recomputes SHA-256 over the SARIF bytes retained in the Audit Pack and treats a mismatch as a tamper signal, in the same manner as config_manifest_digest of Section 5.8.¶

finding_ref:

OPTIONAL JSON string carrying a producer-asserted opaque pointer to the specific finding or rule identifier inside the SARIF artifact (for example a ruleId plus a location). The field is free-text; it proves the reference existed at issued_at and is never resolved or validated by the issuing platform.¶

approval_ref:

OPTIONAL JSON string carrying a producer-asserted opaque correlation pointer to a human-in-the-loop approval identifier or an external ticket. The field is free-text; it proves the correlation pointer existed at issued_at and is never resolved or validated by the issuing platform.¶

risk_snapshot:

OPTIONAL object carrying a point-in-time snapshot of THIRD-PARTY risk signals as the producer read them, with members: snapshot_at (REQUIRED ISO 8601 timestamp with explicit timezone, the producer-asserted read-time the snapshot is pinned to), snapshot_source (free-text string naming where the signals came from, for example a named EPSS feed, the CISA KEV catalog, or an NVD CVSS record; OPTIONAL when only snapshot_at and cve_ids are populated, REQUIRED whenever any of epss, cvss, cvss_vector, or kev_listed is populated), epss (OPTIONAL string), cvss (OPTIONAL string), cvss_vector (OPTIONAL string), kev_listed (OPTIONAL boolean), and cve_ids (OPTIONAL JSON array of CVE-identifier strings). The object is a producer-asserted snapshot, NOT a value the issuing platform computed, fetched, verified, queried, or vouched for; it proves only that the producer asserted these signals at snapshot_at, and is explicitly NOT reproducible from any input the issuing platform holds. A verifier MUST NOT read any member as an issuing-platform-derived or verified score. All numeric risk signals (epss, cvss) MUST be encoded as JSON strings, not as JSON numbers, consistent with the IEEE-754 float prohibition of Section 4; this string encoding is load-bearing for the snapshot-not-score semantics. Whenever any of epss, cvss, cvss_vector, or kev_listed is populated, snapshot_source MUST be present; a populated numeric or KEV signal without snapshot_source MUST be rejected at signing time by the false-attestation guard named in Section 12.1, so that a value can never be read as an issuing-platform-derived score.¶

A risk-acceptance receipt MAY additionally carry the type-agnostic expires_at field of Section 5.8 to declare the wall-clock time after which the Deployer considers the acceptance stale, and the server-built authorized_under_mandate field of Section 5.10. Consistent with Section 5.8, expires_at on a risk-acceptance receipt is declared, not enforced: the issuing platform records the declared expiry but NEVER auto-revokes an expired acceptance, and a verifier MUST NOT reject the originating risk-acceptance receipt itself solely because expires_at has elapsed. The named identities (approver_id, initiator_id) are bound fields; beyond the string-incoherence refusal of the risk_acceptance_self_approval_guard, NO separation-of-duties check is performed by this profile.¶

5.12. Code-Authorship Extensions

This section is normative. It defines extension fields, two of them REQUIRED on the type and the rest OPTIONAL, that appear inside the signed payload object of a receipt of type protectmcp:lifecycle:code_authorship (registered in Section 12.2), which records a producer's assertion that an agent-authored change to a code repository existed at a point in time. A code-authorship receipt is a lifecycle record, not a policy-evaluation outcome: it is emitted through the no-policy lifecycle path of Section 5.2, carries decision observation, and asserts that no policy was evaluated for the change. The reference cloud implementation enforces the no-policy rule at signing time as the code_authorship_requires_no_policy_decision guard, signs the type only on its compliance signing path (the code_authorship_requires_compliance_mode guard), and rejects, as the code_authorship_fields_require_code_authorship_receipt guard, a receipt of any other type that carries the fields of this section. The fields are covered by the signature scope and the previousReceiptHash chain link of Section 5.3, and by the anchors timestamp of Section 5.4; taken together these prove only that the producer asserted these values, key-authored them, and chained them at the receipt's issued_at. The receipt proves only that the change existed, was key-authored, and was chained at time T. It does NOT make the change correct, safe, reviewed, or building: at the receipt layer the issuing platform NEVER clones the repository, never re-runs or re-diffs the change, never verifies that the named code exists or compiles, and never verifies the producing model. The authoritative attestation layer of Section 8.2 is a distinct artefact: there, and only there, the platform re-fetches and re-diffs the change to re-derive the subject digest. The scope-honesty labels in the field definitions below are normative and mirror the labels published in the issuing platform's /.well-known/governance.json wire-vocabulary surface.¶

repo_ref:

REQUIRED JSON string carrying a producer-asserted opaque pointer to the repository the change was authored against (for example a clone URL or an internal repository identifier). The field is free-text; it proves the reference existed at issued_at and is never resolved, cloned, or validated by the issuing platform. A code-authorship receipt that omits repo_ref MUST be rejected at signing time by the code_authorship_missing_required_field guard named in Section 12.1.¶

commit_sha:

REQUIRED JSON string carrying the producer-asserted commit identifier of the authored change (for example a Git object name). The field is bound into the signed bytes only: the issuing platform NEVER fetches the named commit, never verifies that it exists, and never verifies its contents. It proves only that the producer asserted this commit identifier at issued_at. A code-authorship receipt that omits commit_sha MUST be rejected at signing time by the same guard as repo_ref.¶

base_sha:

OPTIONAL JSON string carrying the producer-asserted base commit identifier the change was authored on top of. Like commit_sha, the field is bound into the signed bytes only and is NEVER fetched or verified by the issuing platform; it proves only that the producer asserted this base at issued_at.¶

change_digest:

OPTIONAL JSON string formatted sha256:<64 lowercase hex chars> over the producer-declared canonical bytes of the change (for example a unified diff). The digest is a shape-only existence proof: it proves THAT the named change existed unaltered at issued_at and nothing more. The issuing platform NEVER fetches, re-diffs, or re-computes the change; a verifier recomputes SHA-256 over the change bytes retained in the Audit Pack and treats a mismatch as a tamper signal, in the same manner as sarif_digest of Section 5.11 and config_manifest_digest of Section 5.8. A change_digest value outside the sha256:<64 lowercase hex chars> wire form MUST be rejected at signing time by the change_digest_not_sha256_wire_form guard.¶

change_ref:

OPTIONAL JSON string carrying a producer-asserted opaque pointer to the change as a unit (for example a pull-request or merge-request identifier). The field is free-text; it proves the reference existed at issued_at and is never resolved or validated by the issuing platform.¶

change_approval_ref:

OPTIONAL JSON string carrying a producer-asserted opaque correlation pointer to a human-in-the-loop approval identifier or an external review ticket for the change. The field is free-text; it proves the correlation pointer existed at issued_at and is never resolved or validated by the issuing platform, in the same manner as approval_ref of Section 5.11.¶

change_class:

OPTIONAL JSON string drawn from the closed vocabulary read, write, delete, execute, or deploy, declaring the producer-asserted class of the change. The value is self-declared; the issuing platform records it but does NOT verify that the change matches the declared class. A value outside the closed vocabulary MUST be rejected at signing time, the field being constrained to the closed vocabulary.¶

authored_by:

OPTIONAL object carrying a producer-asserted description of the authoring agent, with members: agent_id (OPTIONAL string identifying the authoring agent), model_id (OPTIONAL string naming the model), model_version (OPTIONAL string naming the model version), tool (OPTIONAL string naming the authoring tool), and attestation_source (OPTIONAL string naming where the authorship description came from). The object is producer-asserted, NOT a value the issuing platform computed, verified, queried, or vouched for; it proves only that the producer asserted these values at issued_at. The issuing platform NEVER verifies the named model. Whenever any of model_id or model_version is populated, attestation_source MUST be present; a populated model field without attestation_source MUST be rejected at signing time by the false-attestation guard named in Section 12.1, so that a model claim can never be read as an issuing-platform-verified attestation.¶

A code-authorship receipt MAY additionally carry the server-built authorized_under_mandate field of Section 5.10 to record the self-declared authorizing mandate the change was signed under; this profile reuses that field for code-authorship authorization and does not define a separate authorization field. Consistent with Section 5.10, authorized_under_mandate asserts self-declared issuer authority only and is NEVER an issuing-platform attestation of verified third-party authorization.¶

5.13. Threat-Framework Taxonomy Extensions

This section is normative. It defines six OPTIONAL caller-supplied taxonomy fields, one OPTIONAL caller-supplied opaque timestamp token, and one platform-set false-attestation guard boolean, all of which MAY appear inside the signed payload object. The six taxonomy fields record producer-asserted mappings of the Action into established threat-and-control catalogues; they are self-declared and are NOT verified by the issuing platform. The guard boolean exists so that a verifier can tell a self-declared classification apart from a platform-verified one. All eight fields are covered by the signature scope defined in Section 5.3, and an implementation MAY emit any subset.¶

mitre_techniques:

OPTIONAL JSON array of MITRE ATT&CK technique identifiers (for example T1059, T1078) self-declared by the producer. The values are referenced by identifier from the MITRE ATT&CK enterprise matrix. The field is not verifier-checked by the issuing platform; when the array is populated the issuing platform MUST set framework_mappings_self_declared to true.¶

mitre_atlas:

OPTIONAL JSON array of MITRE ATLAS identifiers (for example AML.T0051) covering AI-system-specific adversary techniques, self-declared by the producer and referenced by identifier from the MITRE ATLAS catalogue. When populated the issuing platform MUST set framework_mappings_self_declared to true.¶

owasp_llm_top10:

OPTIONAL JSON array of OWASP Top 10 for LLM Applications identifiers (for example LLM01, LLM02), self-declared by the producer and referenced by identifier from the OWASP Top 10 for LLM Applications publication. When populated the issuing platform MUST set framework_mappings_self_declared to true.¶

nist_ai_rmf:

OPTIONAL JSON array of NIST AI Risk Management Framework function identifiers and subcategories (for example GOVERN-1.1, MEASURE-2.7), self-declared by the producer and referenced from [NIST-AI-RMF]. When populated the issuing platform MUST set framework_mappings_self_declared to true.¶

iso_42001:

OPTIONAL JSON array of ISO/IEC 42001:2023 control identifiers (for example A.6.2.6), self-declared by the producer and referenced from ISO/IEC 42001:2023. When populated the issuing platform MUST set framework_mappings_self_declared to true.¶

eu_ai_act_articles:

OPTIONAL JSON array of EU AI Act article identifiers (for example Article-12, Article-15), self-declared by the producer and referenced from [EU-AI-ACT]. When populated the issuing platform MUST set framework_mappings_self_declared to true.¶

rfc3161_timestamp:

OPTIONAL JSON string carrying a base64-encoded [RFC3161] TimeStampResp (DER) supplied by the producer at signing time and preserved verbatim on the receipt for offline TSA chain verification independent of any platform-issued anchors. The payload entry is an opaque caller-supplied token, NOT the per-receipt anchor produced by the platform under Section 5.4; the base64 encoding is per [RFC4648]. It never counts toward the anchoring requirement of Section 5.4 or toward a witness_policy quorum, and a verifier MUST NOT read it as the receipt's timestamping evidence. This field does not flip framework_mappings_self_declared.¶

framework_mappings_self_declared:

OPTIONAL JSON boolean false-attestation guard set by the issuing platform. The platform MUST set it to true whenever any of mitre_techniques, mitre_atlas, owasp_llm_top10, nist_ai_rmf, iso_42001, or eu_ai_act_articles is populated. A producer-supplied value of false alongside a populated taxonomy field MUST be overridden by the issuing platform, in the same spirit as the false-attestation guards of Section 5.10 and the witness_policy quorum guard of Section 5.4. The guard does not assert that the self-declared mappings are correct; it asserts only that they are self-declared rather than platform-verified, and a verifier MUST NOT treat a populated taxonomy field as platform-verified.¶

The eight fields are type-agnostic and MAY appear on any receipt type defined by this profile.¶

5.14. Environment Attestation Extensions (Normative-Optional)

This section is normative-optional: it defines one extension field carrying pre-action world-state attestations into the receipt's evidence surface, in the spirit of the environment record family of [DRAFT-MSEBENZI-EVIDENCE-ACTION]. The field is OPTIONAL; a deployment that emits no environment attestations remains fully conformant, and this revision adopts the concept without mandating implementations.¶

environment_attestation:

OPTIONAL object carrying boolean world-state claims attested before the Action (for example sandbox liveness, egress state, secret-store lock state), signed by an environment key distinct from the receipt's signing key (separation of duty: the runtime asserts facts about itself under its own key, ideally a hardware or CI attestation key). Members: claims (REQUIRED object whose values are booleans), attester_kid (REQUIRED string identifying the environment key), attested_at (REQUIRED ISO 8601 timestamp with explicit timezone), and sig (REQUIRED base64 signature over the JCS canonicalization per [RFC8785] of the attestation object with the sig member removed, under the algorithm declared for the environment key). The object is covered by the receipt's own signature scope of Section 5.3 in addition to carrying its detached environment-key signature. A verifier that checks the field verifies sig against the resolved environment key and bounds the staleness of attested_at relative to the receipt's issued_at under the verifier's documented bound; a stale, unverifiable, or malformed attestation is reported on its own axis and never folds into the receipt-level verdict of Section 10.5.¶

Composition rule (hard): an environment attestation INFORMS the policy gate and appears in the Audit Pack evidence list; it NEVER replaces or short-circuits the policy gate. A receipt carrying a perfect environment attestation and a failed policy evaluation still verifies as policy-failed, and a receipt carrying no environment attestation is not thereby downgraded. The policy gate remains the sole authorization surface.¶

Scope honesty: the attestation is only as trustworthy as the environment key's custody. It raises the cost of lying about the execution environment; it does not make producer-asserted state third-party truth, and it conveys no remote-attestation result unless the environment key is itself a hardware attestation key, which this profile does not require (the role separation of Section 3 applies; no field defined by this section carries a remote attestation result per Section 11.14).¶

6.1. EU AI Act Article 12 Binding

Each subsection cites the operative phrase of Article 12 and binds it to the receipt field that provides evidence for it.¶

6.2. EU AI Act Article 26 Binding

6.3. DORA Article 17 Binding

7.1. NIST AI RMF Binding

[NIST-AI-RMF] 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. [NIST-GENAI-PROFILE] 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.¶

7.2. Colorado AI Act (SB 24-205) Binding

[COLORADO-AI-ACT] 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.¶

7.3. Texas Responsible AI Governance Act (HB 149) Binding

[TEXAS-TRAIGA] 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 [NIST-GENAI-PROFILE], or another nationally or internationally recognized risk management framework for AI systems, and operate an internal review process.¶

7.4. HIPAA Security Rule Binding (45 CFR Part 164, Subpart C)

[HIPAA-SECURITY] 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.¶

7.5. NYDFS Cybersecurity Regulation Binding (23 NYCRR Part 500)

[NYDFS-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.¶

7.6. SEC Broker-Dealer Recordkeeping Binding (17 CFR 240.17a-4)

[SEC-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.¶

7.7. CIRCIA Binding (Cyber Incident Reporting for Critical Infrastructure Act of 2022)

[CIRCIA] 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.¶

8.1. Attestation Statement Envelope

An attestation statement is a Dead Simple Signing Envelope (DSSE, [DSSE]) whose payload is an in-toto Statement v1 ([IN-TOTO-ATTESTATION]) and whose signature is computed over the DSSE Pre-Authentication Encoding (PAE) of that payload. The issuing platform MUST construct the DSSE envelope as the PAE over the declared payload type and the payload bytes, and MUST sign that PAE with ML-DSA-65 ([FIPS204]) under the service identity of Section 8.6; the signature MUST NOT be computed over any ad-hoc serialization of the statement. The in-toto Statement MUST set predicateType to a value under the asqav predicate namespace https://asqav.com/; the statement's subject array carries one or more subjects, each identified by a digest set. The DSSE envelope and the in-toto Statement it carries are JSON documents; their canonical form for signing is the DSSE PAE defined by [DSSE], which is independent of the JCS rule that governs the receipt envelope of Section 5.¶

Two tiers of attestation statement are defined. The tier is a property the issuing platform sets and a verifier reads from the statement; a caller MUST NOT select the tier.¶

Voluntary (observation) attestation:

The statement's subject digest is a caller-supplied digest. The issuing platform signs the digest the caller supplied without independently re-deriving it. This tier is a voluntary cryptographic attestation: it is non-repudiable for exactly what was attested (the platform did sign that digest at that time under its key), but it is explicitly NOT a capture and is NOT unbypassable. The producer-asserted receipts of Section 5.12 and Section 5.11 are the receipt-layer expression of this tier: the platform signs the producer's asserted values and never re-fetches, re-diffs, re-runs, or otherwise re-derives them. A verifier MUST NOT read a voluntary attestation as evidence that the attested content corresponds to any independently observed fact.¶

Authoritative attestation:

The statement's subject digest is server-re-derived by the issuing platform from independent evidence, per Section 8.2. The caller-supplied digest, if any, is advisory only and is never the signed subject. This tier is the only tier that supports the independent re-derivation check of Section 8.4.¶

8.2. Authoritative Code-Authorship Re-Derivation

This section is normative and is the principal addition of revision -08. For an authoritative attestation whose subject is a code change, the issuing platform (acting as verifier of the change) MUST re-derive the subject digest from the source host rather than trust any client-supplied digest. The canonical re-derivation rule is as follows.¶

The re-derivation input is a commit RANGE, not a single commit. A change authored as a pull request ordinarily carries more than one commit, so a digest computed over the named commit alone would cover only part of the authored change. The issuing platform MUST therefore resolve a base commit identifier for the range before fetching, in the following order, and MUST NOT silently guess one: (a) the base identifier supplied with the attestation request, where it is a full 40-character lowercase hexadecimal object name (this request parameter is distinct from the producer-asserted base_sha receipt field of Section 5.12, which is bound into the signed bytes and never fetched); (b) otherwise the base the source host records for the pull request associated with commit_sha, which is the merge-base anchor for the change and is therefore stable across merge and squash commits; (c) otherwise, where commit_sha names a parentless commit, the empty tree object name 4b825dc642cb6eb9a060e54bf8d69288fbee4904. Where none of (a) through (c) yields a base, the platform MUST refuse to emit an authoritative attestation rather than infer a base from the commit parents, which are ambiguous for merge and squash commits.¶

Given that resolved base identifier, the named commit identifier commit_sha (the field of Section 5.12) and the named repository repo_ref, the issuing platform MUST fetch the raw unified diff for the range from the source host (for a GitHub-hosted repository, the REST comparison endpoint /repos/{repo}/compare/{base}...{commit_sha}) with the HTTP Accept header set to application/vnd.github.diff, so that the response body is the raw unified diff of that range. The subject digest the platform signs is the SHA-256 digest computed over the exact response bytes returned by that fetch, with no re-encoding, re-serialization, whitespace normalization, or truncation applied before hashing. The digest MUST be expressed in the sha256:<64 lowercase hex chars> wire form used throughout this profile.¶

Scope of this rule: the canonical re-derivation rule is defined for GitHub-hosted repositories only. It depends on a proprietary, unregistered media type (application/vnd.github.diff) and on GitHub's diff rendering (rename detection, context lines, binary-file stubs), which is not a versioned specification; if that rendering changes, digests signed under the earlier rendering no longer re-derive, which the detection rule below surfaces rather than hides. Repositories hosted elsewhere require a host-specific rule defined on the same principle - fetch the host's raw diff rendering of the range and hash the exact response bytes - and this revision defines no such rule.¶

A client-supplied digest (for example a value the caller placed in change_digest of Section 5.12) is ADVISORY only under the authoritative tier. The issuing platform MAY compare the advisory digest to the re-derived digest and SHOULD flag a mismatch in the attestation predicate, but the signed subject digest MUST be the re-derived value; the advisory value MUST NOT be substituted for it, signed in its place, or treated as the subject under any mismatch handling. A mismatch is evidence that the client's view of the change diverges from the source host's view; it does not promote the client value to the signed subject.¶

The property reproducibility gives an authoritative attestation is unforgeability, not unbypassability: any third party holding repo_ref, commit_sha, and the base identifier recorded in the attestation predicate can re-fetch the same range from the source host under the same Accept: application/vnd.github.diff rule, recompute SHA-256 over the exact response bytes, and obtain the same digest the platform signed, without trusting the platform and without trusting the client. Reproducibility does NOT make the attestation unbypassable: a client that never requests an attestation bypasses it entirely, and unbypassability is a property of the deployment per Section 8.5, never of this digest rule. The canonical re-derivation rule above is therefore stated precisely so that the recomputation is byte-for-byte deterministic across independent verifiers. Where the source host returns different bytes for the same range at different times (for example after a force-push that rewrites the commit), the re-derived digest changes and the earlier attestation no longer re-derives; this is the intended detection behaviour, not a failure of the rule. The platform MUST record both the commit_sha and the resolved base identifier it re-fetched in the attestation predicate, so that the whole re-derivation input is named and no verifier has to infer the range. A verifier MUST re-derive over the range the predicate names and MUST NOT substitute a range of its own choosing. The signed subject digest is a claim about exactly that range, and it is not a claim that the range covers every change the producer authored.¶

8.3. Capture-Layer Integrity

This section is normative. The attestation predicate carries a server-derived capture_layer member that names the independent evidence the issuing platform relied on, and a server-enforced receipt_type member that encodes whether the statement is authoritative or an observation. Both members are set by the issuing platform at signing time; a caller-supplied value for either member MUST be dropped before signing, in the same manner as the server-built fields of Section 5.10.¶

The capture_layer member MUST be derived from independent evidence rather than asserted by the caller. The following values are defined.¶

github_sha_pull:

The platform re-fetched the raw unified diff for the named commit range from the source host per Section 8.2. This is independent evidence and supports an authoritative attestation.¶

network_proxy:

The platform observed the Action as routed HTTP egress through a proxy under the deployer's control (the topology catalogued as network_proxy in Appendix C). This is independent evidence for the routed egress the proxy actually saw and supports an authoritative attestation for that egress only.¶

in_process_sdk:

The evidence originates from an SDK linked into the application's own process (the topology catalogued as in_process_sdk in Appendix C). This is OBSERVATION only: the evidence is produced by the same process whose behaviour is being attested, so it is not independent. An in_process_sdk capture layer MUST NOT mint an authoritative decision attestation; it yields a voluntary observation attestation only.¶

passive_telemetry:

The evidence originates from a post-hoc telemetry ingestion pipeline (the topology catalogued as passive_telemetry in Appendix C). This is OBSERVATION only and MUST NOT mint an authoritative decision attestation.¶

The capture_layer vocabulary of this section and the capture_topology vocabulary of Appendix C are distinct vocabularies at distinct layers: capture_layer names the evidence class an attestation statement relied on (the four values above), while capture_topology names the emission topology of a receipt (six values). Emission topologies with no independent-evidence capture_layer counterpart (browser_extension, ebpf_observer, mcp_proxy) can never mint an authoritative attestation; conversely github_sha_pull is a re-derivation evidence class and has no emission-topology counterpart. A deployment mapping one vocabulary onto the other MUST do so per this paragraph and MUST NOT invent values in either.¶

The receipt_type member MUST be one of authoritative or observation, and the issuing platform MUST enforce the correspondence between receipt_type and capture_layer: a statement with receipt_type authoritative MUST carry a capture_layer drawn from the independent-evidence values (github_sha_pull, network_proxy), and a statement whose capture_layer is an observation-only value (in_process_sdk, passive_telemetry) MUST carry receipt_type observation. In particular, an in-process capture can never mint an authoritative decision receipt. The authoritative path MUST fail closed: if the independent evidence cannot be obtained (the source host is unreachable, the re-fetch returns an error, or the proxy did not observe the egress), the issuing platform MUST NOT emit an authoritative attestation and MUST instead emit an observation attestation or refuse to emit. A present-but-incoherent combination of receipt_type and capture_layer MUST be rejected at signing time, in the same spirit as the false-attestation guards of Section 5.10.¶

8.4. Independent Verification Protocol

This section is normative. A third party verifies any authoritative attestation statement independently of the issuing platform's cooperation, by performing all of the following steps. The protocol requires network access to independent surfaces - the issuing platform's published JWK Set, the source host, and, where applicable, the deployer's egress log - and requires no verification step to be performed on the verifier's behalf by the issuing platform; "independent" here never means "offline".¶

• Fetch the verification key from the issuing platform's published JWK Set at /.well-known/jwks.json (Section 8.6), selecting the key whose key identifier equals the signature's kid. The verifier MUST NOT trust a verification key embedded in the attestation statement itself, mirroring the rule of Section 10.2 for receipts.¶
• Verify the ML-DSA-65 signature ([FIPS204]) over the DSSE PAE of the in-toto Statement, per Section 8.1. A signature that does not verify under the resolved key MUST cause the attestation to be rejected.¶
• Re-derive the subject digest from independent evidence using the same canonical rule the platform used: for a code subject, re-fetch the raw unified diff for the range named in the predicate (its base identifier and commit_sha) from the source host under Accept: application/vnd.github.diff and recompute SHA-256 over the exact response bytes per Section 8.2; for a routed-egress subject, read the deployer's egress log for the observed flow. The verifier MUST require equality between the re-derived digest and the signed subject digest; a mismatch MUST cause the attestation to be rejected.¶

These steps compose with, and are additive to, the baseline receipt checks of Section 10.2 where the attestation statement accompanies a Compliance Receipt. The combined effect bounds a lying client: a client that controls only its own inputs can at best produce a non-gating observation attestation (which the receipt_type of Section 8.3 marks as such and which no verifier treats as authoritative), or an authoritative-shaped statement whose subject digest fails the re-derivation equality check and is therefore rejected. A client cannot produce a passing authoritative attestation for a change the source host does not corroborate, because the signed subject is the re-derived digest and the verifier recomputes it independently.¶

8.5. Honest Tiering of Capture Claims

This section is normative and states, precisely and without overclaim, what each deployment tier does and does not capture. The two product tiers and their honest guarantees are as follows.¶

SaaS-SDK tier:

This tier produces a voluntary cryptographic attestation per Section 8.1. The attestation is non-repudiable for exactly what was attested (the platform signed the caller-supplied digest under its key at the attested time), but it is NOT a capture and is NOT unbypassable: the platform signs what the client presents and does not independently observe the client's behaviour. A verifier or regulator MUST NOT read a SaaS-SDK-tier attestation as evidence that the attested action is the complete set of actions the client performed.¶

Enterprise-proxy tier:

This tier produces a real capture, but only for routed HTTP egress to public model APIs that actually traverses the deployer's proxy, and only when the deployer both firewalls egress so that the model-API traffic is forced through the proxy and configures the proxy and signer to fail closed. Under those deployer-controlled conditions the capture is authoritative for the egress the proxy observed, per the network_proxy capture layer of Section 8.3. The unbypassability of this tier is a property of the deployer's network policy (the firewalling and fail-closed configuration), NOT a property of the product: a deployer that does not firewall egress, or that configures fail-open, has not deployed an unbypassable capture, and the product MUST NOT be represented as providing one in that configuration. This profile does NOT claim, and the Enterprise-proxy tier does NOT provide, host-level capture of arbitrary process behaviour: it does not claim eBPF-based or shell-based capture of actions that do not traverse the routed HTTP egress. The eBPF-observer and passive-telemetry topologies catalogued in Appendix C remain observation-only evidence classes under Section 8.3 and do not mint authoritative attestations.¶

8.6. Service Identity, JWKS, and Revocation

This section is normative. Attestation statements are signed under a dedicated service identity operated by the issuing platform, distinct from any agent or deployer identity. The service identity's signature algorithm is ML-DSA-65 ([FIPS204]). The corresponding public key MUST be published in a JSON Web Key Set at the well-known location /.well-known/jwks.json of the issuing platform, and each attestation statement's signature MUST carry a kid that resolves to exactly one key in that set, mirroring the kid-resolution discipline of Section 10.2 and the issuer_id-equals-kid invariant of Section 5.1.3.¶

Revocation of a service-identity key MUST be checkable from the published JWK Set itself: under the revoked-key publication rule of Section 11.4 a revoked key remains published with a revocation time, and key status is determined from that publication. This profile uses no PKIX revocation path: the service identity is a bare JWK, not an X.509 certificate, and OCSP or CRL machinery does not apply to it. A verifier MUST fail closed on key status: a signature made by a key that is revoked at or before the attestation's issued time MUST be rejected, and a signature whose kid does not resolve to a known, currently valid key in the JWK Set (an unknown key) MUST be rejected. Under that publication a verifier passes an attestation issued before the revocation instant and fails one issued at or after it. A verifier MUST NOT accept an attestation statement whose signing key is revoked or unknown, regardless of whether the signature otherwise verifies.¶

10.1. Verifier Independence

This section is normative. Verification under this profile MUST be performable independently of the issuing platform: any third party holding the receipt, the chain commitments, and the verification key material named in Section 10.2 MUST be able to execute every check of this section without the issuing platform's cooperation, and no verification step MAY be conditioned on an account, an API credential, a fee, or any other authorization granted by the issuing platform or a party affiliated with it. A verification facility that reports a verdict only to registered callers, or that withholds key material behind an access control the issuer administers, is not a Compliance Verifier under this profile: its verdicts are issuer-gated attestations, not independent verification.¶

Independence is a property of the verification path, not of the verifier's operator. A Compliance Verifier MAY be operated by the issuing platform itself, by the Deployer, by the Counterparty, or by a neutral third party unaffiliated with any of them; what the profile requires is that the same receipt, chain, and published key material yield the same verdict for every operator, and that the neutral-third-party position is always achievable with no step performed on the verifier's behalf by the issuing platform. The Independent Verification Protocol of Section 8.4 states the same requirement for attestation statements and names the independent surfaces it fetches from.¶

10.2. Mandatory Checks

A Compliance Verifier MUST perform at minimum all of the following checks before treating a receipt as a Compliance Receipt, together with the conditional checks of Section 5.4 (pending-anchor bound and witness quorum), Section 5.7.3, Section 5.8, and Section 5.10.¶

• Verify the signature over the signed bytes defined in Section 5.3, using the algorithm declared in signature.alg per [ACTA-RECEIPTS].¶
• Resolve the verification key through one of the key-distribution mechanisms described in Section 4.3 of [ACTA-RECEIPTS] (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 Section 5 are present and well-formed.¶
• Verify the hash-chain linkage by recomputing the chain-link digest of the immediately preceding receipt per Section 5.3 and comparing the lowercase hex encoding to previousReceiptHash. An explicit JSON null, an empty string, or an absent member is a malformed chain link, not a genesis marker; the genesis value is the all-zero SHA-256 value of Section 5.3.¶
• Verify at least one anchor: an [RFC3161] token, an [OPENTIMESTAMPS] commitment, or both. The anchor MUST cover the committed bytes defined in Section 5.4. The verifier MUST cryptographically re-verify the anchor against those bytes; presence of anchor metadata without a successful cryptographic check MUST NOT yield "valid".¶
• Verify the future-skew bound on issued_at per Section 5.1.2. Past skew MUST NOT cause non-conformance when the receipt is within retention.¶
• Where the receipt carries expires_at, reject a downstream action that replays that decision after expires_at per Section 5.8; the receipt itself MUST NOT be rejected solely because expires_at has elapsed. Where the verifier maintains a seen-nonce index, a duplicate nonce under the same issuer_id MUST be flagged as a replay candidate on the reporting axis of Section 10.4.¶
• Verify that policy_digest resolves through Section 9. 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 [RFC8785].¶
• Where the receipt carries key_thumbprint per Section 5.1.8, recompute the RFC 7638 thumbprint of the resolved verification key per [RFC7638] and require equality. A mismatch is a key-substitution failure and MUST be reported as non-conformant, never downgraded to a warning or reported as verified. Absence of the field is the legacy case of Section 5.1.8 and is not itself a failure.¶

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

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

10.4. Reporting

A Compliance Verifier SHOULD produce a structured per-receipt report that names the regime bindings the receipt satisfies and the outcome of the per-axis checks the verifier performed. The following fields SHOULD be emitted; the axes are independent and consumers MUST NOT collapse them into a single boolean before display.¶

regimes_satisfied:

Array of short stable regime identifiers drawn from the regimes listed in Section 9 (for example eu_ai_act, dora, nist_ai_rmf, colorado_ai, texas_traiga, hipaa_security, nydfs_500, sec_17a4a, sec_17a4b, circia). The set is open-ended; consumers MUST treat unknown identifiers as informational. Where this field is inherited from a producer-side mapping in the bundle, the bundle-level regime_mapping_disclaimer of Section 9 applies.¶

anchor_valid_ots:

Boolean. true when an [OPENTIMESTAMPS] anchor is present, has upgraded to the Bitcoin block attestation within the 7-day bound of Section 5.4, and re-verifies cryptographically against the signed envelope; otherwise false (including the case where the only present anchor is RFC 3161).¶

anchor_valid_rfc3161:

Boolean. true when an [RFC3161] token is present, carries an ESSCertIDv2 per [RFC5816] where required, and re-verifies cryptographically against the signed envelope; otherwise false.¶

policy_digest_resolved:

Boolean. true when policy_digest resolved to a retained artefact whose JCS-canonical SHA-256 matches the receipt value, per Section 10.2; false on absence, resolution failure, or digest mismatch.¶

duplicate_emission_candidate:

Boolean. true when at least one other receipt sharing action_ref and issuer_id has been observed in the same Audit Pack or in a verifier-maintained index; otherwise false. The axis is informational; this profile does not require verifiers to maintain a cross-receipt index. An absent index MUST report false rather than omit the axis, so consumers learn "no duplicate" from the value and learn "axis unknown" only from the verifier's documented capability set.¶

A receipt may carry anchor_valid_ots=true and anchor_valid_rfc3161=false (or vice versa) and still satisfy the mandatory anchor check of Section 5.4, which requires only one valid anchor. Where a receipt carries counterparty_binding per Section 5.7, the verifier SHOULD additionally emit the outcome of the check of Section 5.7.3. This revision does not define a stable field identifier for that axis; a future revision may define one, following the duplicate_emission_candidate pattern in which a verifier that maintains no cross-receipt index reports false rather than omitting the axis.¶

10.5. Verification Verdict and Hash-Algorithm Vocabulary

This section defines the wire vocabulary a conforming verifier uses to summarize the outcome of its checks, and the hash-algorithm label that distinguishes keyed digests from unkeyed ones. The vocabulary is normative for verifier reporting under Section 10.4. The summary verdict complements the per-axis report of Section 10.4; it does not replace it, and the axes remain individually reportable under the no-collapse rule of that section.¶

The hash_algo member of the payload records how the receipt's context digest was produced, as registered in Section 12.1. The value sha256 denotes an unkeyed SHA-256 digest; the value hmac-sha256 denotes an HMAC-SHA256 keyed digest computed under a holder salt. The digest string keeps the sha256:<64 hex> wire form of the upstream payload_digest in both cases; hash_algo is the discriminator. The keyed form exists because a low-entropy context is dictionary-recoverable from an unkeyed digest, and the keyed digest resists that recovery.¶

A receipt whose context digest is keyed MUST carry hash_algo with the value hmac-sha256 in its signed payload. Absence of hash_algo means the unkeyed sha256 form, and a verifier reports absence as unkeyed. Because both forms share the sha256:<64 hex> digest wire form, hash_algo is the only signal that distinguishes them: an issuing platform that emits a keyed digest without the member causes every conforming verifier to report verified for a receipt that is not third-party re-derivable, which is exactly the over-claim verified_keyed exists to prevent. A verifier that cannot determine the form MUST NOT report verified.¶

Two terms carry the normative weight of this section. The context digest is the digest the receipt commits to as the record of the Action's context, carried in the payload_digest member in the sha256:<64 hex> wire form. The holder salt is a secret the Deployer generates and holds outside the receipt: it is the HMAC key of the hmac-sha256 form, it MUST NOT appear in any signed field, anchor, or Audit Pack export, and its destruction renders the keyed digest permanently unopenable, composing with the payload-deletion erasure rule of Section 11.6. The keyed digest is computed as HMAC-SHA-256 ([RFC2104]) over the same JCS-canonical context bytes the unkeyed form digests, and the result is carried in the same sha256:<64 hex> wire form with hash_algo as the discriminator.¶

The verdict vocabulary has exactly three values.¶

verified:

The signature, chain, and anchor checks of Section 10.2 pass, and the receipt's context digest is unkeyed (hash_algo = sha256) and re-derivable from evidence any third party can obtain.¶

verified_keyed:

The signature, chain, and anchor checks pass, and the receipt's context digest is keyed (hash_algo = hmac-sha256): the digest is internally consistent and authentic to holders of the salt, but a third party cannot re-derive it without the holder salt, so the receipt is not third-party re-derivable proof of the context. This is a passing verdict. A verifier MUST NOT collapse it into verified (that would claim a re-derivability the receipt does not provide) and MUST NOT collapse it into unverified (that would discard a valid, anchored receipt).¶

unverified:

Any non-passing outcome: a signature, chain, or anchor check failed, or an anchor has not yet produced a cryptographic proof. A receipt whose anchor is still pending reports unverified until the proof exists. Implementations MAY surface additional display states (anchor-pending, sealed-commitment) to their users, but the wire verdict MUST be one of these three values, and the three-value verdict is authoritative wherever it conflicts with a display refinement.¶

Non-passing verdicts are further classified by a failure_class axis with exactly two values, and implementations MUST NOT collapse the two. invalid means the check ran and a cryptographic or policy binding failed: a signature mismatch, a chain-link mismatch, an invalid anchor, a counterparty-binding mismatch, a signer key changed since issuance, an algorithm mismatch, or an issued_at beyond the future-skew bound of Section 5.1.2. unverifiable means the recomputation could not be completed: the signing key could not be resolved, the chain predecessor is missing, a member is malformed, canonicalization or parsing failed (including the duplicate-member rejection at ingest), the policy artefact could not be resolved, or the anchor is pending without a cryptographic proof. A verifier MUST NOT report a receipt as passing when the recomputation did not complete: unverifiable is not a weaker form of invalid and invalid is not a stronger form of unverifiable, and a failure that moves from one class to the other under retry is a genuine state change, not a relabelling. The reference platform carries the axis as failure_class in its verification detail alongside the boolean verified axis, and the reference SDK verifier emits it alongside the three-value verdict.¶

A receipt carrying a keyed digest MUST NOT be reported as plain verified: the absence of third-party re-derivability is exactly the property the verified_keyed value exists to surface. The reference cloud implementation historically rendered the non-passing verdict as failed; this profile's wire vocabulary is unverified, and conforming reports of this profile use unverified.¶

For interoperability with the deployed reference platform, this paragraph documents that platform's display vocabulary exactly. The reference cloud implementation surfaces five display states on its verification page: verified, verified_keyed, pending (signature valid, the anchor being committed but not yet proven), not_rederivable (signature valid and anchored, but the committed claim opens only for its key holder), and failed (a cryptographic check failed). It additionally carries a boolean verified axis in its JSON output, which stays true for both verified and verified_keyed. Under the three-value wire vocabulary of this section, verified and verified_keyed map to themselves; pending maps to unverified until the anchor commits; not_rederivable is a passing display state and maps to verified_keyed: it is the reference platform's display name for the keyed-digest case of this section, whose committed claim opens only for the salt holder; and failed maps to unverified. The three-value verdict is authoritative wherever a display refinement and the wire vocabulary disagree.¶

11.1. Tamper Resistance

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

Implementations SHOULD anchor at intervals no longer than 24 hours. Implementations operating under DORA Article 17, 23 NYCRR 500.17, or [CIRCIA] SHOULD anchor at intervals no longer than one hour, given the four-hour initial-notice deadline (with 72-hour intermediate-report and one-month final-report bounds) per DORA Article 17 and the RTS in [REG-2025-301], the 72-hour notification clock under 23 NYCRR 500.17, and the 72-hour CIRCIA covered-cyber-incident reporting deadline that will apply once the CIRCIA final rule takes effect.¶

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

11.2. Chain- and Signature-Scope Confusion

A verifier that processes more than one receipt format MUST determine the signature scope and the chain-digest scope from the receipt's format before it begins verification, and MUST NOT retry verification under a different scope when the first attempt fails. For Compliance Receipts both scopes are fixed by Section 5.3: the signature covers the JCS-canonical serialization of the payload member, and the chain link digests the predecessor's payload member R. Receipts of the bare [ACTA-RECEIPTS] format chain over the whole-receipt object including the signature, and other formats in the wild sign the receipt object minus the signature field (the APS gateway receipts in the [SCOPEBLIND] corpus, per Section 9); the top-level anchors key distinguishes this profile's receipts per the interoperability note of Section 5.3. A scope-derived verification failure MUST be reported distinctly from an integrity failure under the correct scope: retrying the alternate scope on failure converts a format mismatch into an apparent integrity result, concealing both the wrong-format case and the tampered case from the consumer of the verification report.¶

11.3. Chain Availability Under Single-Linear Per-Agent Serialization

This section is informative. The single-linear per-agent chain requirement of Section 5.3 serializes receipt emission for a given issuer_id through a single predecessor pointer. A denial-of-service against the predecessor pointer (database row lock contention, network partition between the emitter and the predecessor store, slow IO, or an adversary deliberately holding the chain-tail lock) therefore bounds the per-agent emission throughput, because every new receipt MUST resolve the digest of the immediately prior receipt before it can be linked. A partial-write failure between predecessor-pointer commit and signature commit can additionally produce chain-head ambiguity if not handled defensively.¶

Issuers SHOULD use a bounded predecessor-lookup timeout (operator-tuned, typically on the order of seconds rather than tens of seconds) and SHOULD emit a structured audit event with type protectmcp:lifecycle and a stable reason code (RECOMMENDED: chain_emission_blocked) when the timeout fires, rather than silently dropping the receipt or stalling caller threads. Issuers SHOULD additionally document a chain-head recovery procedure for crashed emitters: on restart, the issuer re-reads the predecessor row, verifies that no orphan signature exists for the next sequence position, and resumes emission. Operators that require parallel per-issuer throughput beyond what a single linear chain sustains MUST use distinct issuer_id values per parallel path, with separate signing keys and chains rooted at the all-zero genesis value, per the rule in Section 5.3.¶

The threat profile here is availability, not confidentiality or integrity: a successful chain-availability attack delays or drops emission, but it cannot tamper with already-emitted receipts (those are protected by Section 11.1) and it cannot forge receipts (those are protected by Section 11.4). The chain_emission_blocked lifecycle receipt is itself a Compliance Receipt and therefore links into the chain once emission resumes, so the gap is detectable rather than silent.¶

11.4. 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. Where the Deployer publishes its verification keys through a well-known JWK Set endpoint, a revoked key remains published and its entry carries a revoked_at timestamp, so that a verifier can pass a receipt issued before that instant and fail one issued at or after it.¶

11.5. Retention and Long-Term Verifiability

The longest fixed retention floor in this profile is 2192 days (six calendar years), set by Section 7.4 and Section 7.6; the EU side has a parallel five-year (1827-day) floor under Section 6.3. The CIRCIA preservation floor of Section 7.7.2 is not measured from the date of the underlying Action: it runs forward from the submission of the most recently required CIRCIA report, so the effective retention period of a receipt referenced in such a report can extend beyond the 2192-day fixed floor. These floors exceed the typical operational crypto-period of a signing key under recommended key-management practice. Implementations SHOULD use ML-DSA-65 from the [ACTA-RECEIPTS] algorithm registry ([FIPS204]) 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.¶

11.6. Privacy

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

Where the underlying Action references a data subject, the payload_digest field MUST cover the data; the data itself MUST be held in a separate store that respects the data subject's rights under applicable law (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.¶

No field defined or registered by this profile carries a network, hardware, or physical-location identifier. A signed payload or extension field MUST NOT include an IP address, a hostname, a hardware or machine identifier, or a geolocation value in cleartext. Where a deployment needs to bind a receipt to such environment facts, it conveys them as a keyed digest per Section 10.5 (hash_algo = hmac-sha256 under a holder salt) or through the boolean claims of Section 5.14, which by construction carry no identifier. The unkeyed sha256 form MUST NOT be used for such values: a low-entropy identifier (a region name, a hostname, an address block) is dictionary-recoverable from an unkeyed digest and linkable across every receipt that repeats it. Destruction of the holder salt renders a keyed digest permanently unopenable and composes with the payload-deletion rule of the preceding paragraph as the erasure mechanism for environment data.¶

11.7. Anchor Trust

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

11.8. 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 of Section 5.1.2 bounds only future skew: it rejects receipts dated ahead of the verifier's clock and places no lower bound on past skew, so it does not by itself bound the window in which a replayed receipt can be presented as recent. Clock-based replay bounding is available only through the OPTIONAL validity-window fields of Section 5.8: expires_at, which the verifier enforces against replayed decisions, and nonce, which flags duplicate emission where the verifier maintains a seen-nonce index. A receipt carrying neither is bounded only by retention: a replayed receipt whose issued_at lies within the applicable retention window passes the skew check of Section 5.1.2, and its replay is detectable only through action_ref, chain-link, or index evidence.¶

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

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

11.10. Algorithm Agility

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

11.11. Issuer-Misrepresentation Residual

Per-agent hash chains under Section 5.3 detect tampering inside a single issuer's stream but not the cross-agent attack in which a compromised intermediary silently swaps payload bytes between two honest agents. Both per-agent chains validate; action_ref is a correlation anchor, not a cryptographic binding ([ACTA-RECEIPTS] Section 2.2). Without a cross-agent binding primitive, a regulator obtains no cryptographic answer to "did the acknowledging agent acknowledge the bytes the originating agent actually sent". This profile defines counterparty_binding (Section 5.7) as the partial mitigation; the following residuals remain.¶

• Endpoint collusion. If both signing keys are compromised by the same attacker, the attacker produces a coordinated forgery; no signature scheme defends against this case.¶
• Intermediary holds the originating agent's key. In hosted-agent deployments where the intermediary possesses the originating agent's private key, it can sign anything as either party. Remote attestation of key origin is the appropriate countermeasure and is out of scope here.¶
• Originator offline at verification time. Section 5.7.3 requires the originating envelope to be retrievable; if unpublished, offline, or rate-limited, the binding becomes unverifiable (liveness loss, observable as failure).¶
• Fan-out witness gap. When an originator broadcasts to N acknowledgers, each emits an independent pairwise binding; none witnesses any other. Append-only log profiles (future SCITT-style transparency) are deferred to a later revision.¶
• Key rotation orphan. If the originating agent rotates keys after emission but before an acknowledger binds it, the storage obligation of Section 5.7.3 still requires the old envelope to remain retrievable; if retention discipline fails, the binding orphans.¶
• Privacy of envelope hashes. envelope_hash is computed over the full signed bytes including A's signature; an observer of B's receipt learns a stable identifier for A's exact action and therefore can correlate B's behaviour across receipts even when A's payload is otherwise confidential. Where this correlation is unacceptable, a commitment scheme (for example, HMAC over the envelope with a per-counterparty key disclosed only to the verifier) is appropriate; this profile does not specify one.¶
• Real-time prevention. counterparty_binding is detective, not preventive: B has already accepted the bytes by the time the binding is signed. Verifiers detect tampering only at audit time; the in-flight bytes were not blocked. Where prevention is required, transport-level integrity per Section 11.12 is the appropriate primitive in addition to (not instead of) this profile.¶
• Payload-content semantics. The binding proves byte equality, not semantic equality. An intermediary that re-encodes A's bytes into a different but JCS-equivalent canonical form is detected (the SHA-256 differs); an intermediary that swaps A's bytes for entirely different bytes that B's policy happens to interpret as semantically equivalent is detected too. But an intermediary that swaps A's bytes for an A-signed REPLAY of a prior valid envelope from A is not detected by this binding alone; replay protection requires that the verifier also check action_ref and previousReceiptHash uniqueness within the chain segment.¶

11.12. Cross-Agent Integrity Trust Boundary

This section is informative. It records operator guidance for cases where channel-level protection is the only available defence and counterparty_binding per Section 5.7 has not yet been adopted by both endpoints. For channels between named principals, implementers should secure the channel using mutually authenticated TLS 1.3 per [RFC9846]; may use the tls-exporter channel binding per [RFC9266] derived via [RFC5705] where higher channel uniqueness is required; and may layer HTTP Message Signatures per [RFC9421] where intermediaries perform legitimate transformations.¶

Operators must not interpret transport-layer security alone as evidence of cross-agent byte equality. Only counterparty_binding produces application-layer, signed, replay-after-the-fact evidence answering that question. Topologies where the intermediary terminates TLS (CDN edges, MCP servers, message buses, orchestrators) defeat transport-layer integrity against the threat case of Section 11.11; in those topologies counterparty_binding is the only defence this profile offers, and the absence of channel-binding evidence in the Audit Pack should be documented as a known residual.¶

11.13. Compromised Intermediary Between Two Honest Endpoints

This section is informative. Where an Action travels from a sending agent A to a receiving agent B through one or more intermediary processes M, and where M is compromised in such a way that M presents byte sequence X to A and a different byte sequence X' to B, neither A's nor B's cryptographic signature detects the divergence in isolation: each endpoint signs the bytes it observed, and each endpoint's per-agent hash chain per Section 5.3 remains internally valid. Absent the counterparty_binding primitive this profile introduces, the only available cross-agent primitive is action_ref as a SHA-256 join key per Section 5.1.5; both A's chain and B's chain remain valid in isolation, and divergence is only recoverable through a regulator-driven post-hoc comparison of the two chains.¶

counterparty_binding introduced in Section 5.7 closes the case where M silently swaps bytes between two honest endpoints A and B. An acknowledging receipt under this binding is required to carry an envelope_hash computed over the exact byte stream B received (SHA-256(A's envelope) under the digest-scope rule of Section 5.7.1), as specified normatively in Section 5.7.1. A verifier resolves receipt_ref to A's stored envelope, recomputes the digest, and compares; a mismatch indicates that the bytes B signed are not the bytes A signed, and the acknowledging receipt is reported non-conformant per Section 5.7.3. The binding is detective rather than preventive: it does not stop M from performing the swap in flight, but it produces signed, replay-after-the-fact evidence that the swap occurred.¶

The following residuals remain and are not closed by counterparty_binding alone. The list is intentionally honest about the audit-time, not sign-time, nature of the detective evidence: a verifier resolves receipt_ref to A's retained envelope and recomputes the digest at audit time, so any residual reasoning that depends on "A is not in the loop at sign time" is rhetorical, not load-bearing.¶

• Collusion of M and B. If M and B are jointly compromised, M swaps the bytes in flight and B issues an acknowledging receipt carrying an envelope_hash computed over the altered bytes that B signs as if they were A's. Under counterparty_binding the audit-time verifier resolves receipt_ref to A's retained envelope and recomputes the digest, so the binding is reported non-conformant when A's storage is honest and reachable; M+B collusion alone does NOT silently succeed. M+B collusion silently succeeds only when the collusion ALSO extends to corrupting A's retained envelope, suppressing A's chain segment, or making A's storage unreachable to the auditor; that is, the true residual is M+B+(A's-storage compromise or unavailability). Operator mitigation: anchor A's chain on independent witnesses (combined [RFC3161] + [OPENTIMESTAMPS] anchors per Section 5.4, and OPTIONAL deployer-operated transparency logs) so that A's anchored chain-segment digests are independently recoverable from public evidence; regulator-side comparison of A's anchored chain against B's stored chain detects the divergence even when A's local storage is impeached.¶
• Collusion of M and A. If M and A are jointly compromised, A signs a fabricated envelope at M's direction and M relays it to B; B verifies M's relay normally, B's counterparty_binding correctly digests the bytes A signed, A's per-agent chain validates, and B's per-agent chain validates. Every cryptographic invariant in this profile holds because the binding correctly attests that the bytes B received were the bytes A signed; the fraud is in A's intent, not in any byte mismatch. This residual is fundamentally outside the receipt model's threat surface: no application-layer cryptographic primitive in this profile distinguishes a fraudulent A-signed envelope from an honest A-signed envelope when M is also colluding to corroborate plausibility (relay logs, timestamping, message ordering). Operator mitigation: separation of duties between issuer (A) and intermediary (M) so that the same operator cannot control both signing keys and relay logs; anchor evidence on independent witnesses under different trust roots so that an attacker controlling A and M still cannot retroactively coordinate anchor inclusion across uncolluding timestamping authorities; out-of-band attestation by the regulator or auditor of A's operational context (provenance, code signing, runtime attestation) where the policy regime authorises it.¶
• Compromise of B itself. A B that has been compromised (private key extraction, supply-chain compromise, or insider operation) can sign any envelope_hash the attacker chooses; counterparty_binding proves only that the signing key acknowledged some bytes, not that those bytes match what an honest B would have observed.¶
• Loss of A's stored envelope. counterparty_binding requires the verifier to resolve receipt_ref to A's full signed envelope; if A's chain segment is unavailable (retention discipline failure, key rotation orphan, deliberate withholding), the binding becomes unverifiable and the receipt is reported non-conformant on liveness grounds rather than on byte-equality grounds. An adversary who can arrange A-envelope unavailability and then re-emit colluding bytes can degrade the binding from a byte-equality check to a liveness-loss flag.¶

Operators concerned about these residuals in the absence of single-point cryptographic defence should:¶

• Anchor receipts to multiple independent witnesses. Where both [RFC3161] and [OPENTIMESTAMPS] anchors are present per Section 5.4, a coordinated M-B collusion attack must also induce both timestamping authorities to anchor the colluding bytes within the operator's anchor interval, raising the conjunction-cost of the attack. Operators may add further anchors (e.g. a Deployer-operated transparency log or a witness service) without changing the wire format defined here.¶
• Use side-by-side chain comparison under regulator subpoena. The audit-trail alternative semantics established for SEC 17a-4 recordkeeping (see Section 7.6.1) and the post-market surveillance regime of EU AI Act Articles 12 and 26 (see Section 6.1 and Section 6.2) authorise the regulator to compel both A's and B's Audit Packs and to reconstruct the relay by joining on action_ref per Section 5.1.5. counterparty_binding reduces the regulator's workload from "compare both chains and detect divergence" to "verify B's bound digest against A's stored envelope"; the underlying subpoena-and-compare workflow remains the regulator's ultimate authority and remains operative when the binding is unverifiable.¶
• Document M's relay logs out-of-band. Where the intermediary M is identifiable (a named MCP server, message bus, orchestrator, or relay), the operator should require M to produce signed relay logs covering the time window of the Action and should submit those logs to the same Audit Pack production layer as A's and B's chains. Out-of-band relay logs do not require a wire-format change in this profile; they are operational evidence that complements counterparty_binding rather than replacing it.¶

The worst-case latency to detection for an M-only compromise (not M-B collusion) is bounded by the anchor interval recommended in Section 11.1: 24 hours by default, one hour for Deployers operating under [DORA] Article 17, 23 NYCRR 500.17, or [CIRCIA]. After the next anchor commits, the divergence between A's anchored chain segment and the digest carried in B's counterparty_binding is permanently recoverable from the anchored evidence alone, without trust in M.¶

11.14. What a Compliance Receipt Does Not Prove

The preceding subsections state the residual attacks case by case. This subsection consolidates the limits of the artefact itself, so that a regulator or auditor appraising a Compliance Receipt does not credit it with guarantees the format does not provide. A Compliance Receipt, even one that passes every check of Section 10.2, does not prove any of the following.¶

• That the Action was executed, completed, or produced any outcome. The receipt answers the single question of Section 4: whether the same canonicalized bytes passed through the named agent at the wall-clock time the anchors fix. It records a policy decision and the bytes that passed through; nothing about the effects of the Action.¶
• That two byte sequences are semantically equivalent under a downstream tool. The chain layer guarantees byte equality only; keyword case folding, path normalization, Unicode normalization, and numeric tolerance are out of scope per Section 4.¶
• That the policy was correct, lawful, or complete. policy_digest proves only that the named policy artefact existed and was retained (Section 5.2.2); the content of the policy is the Deployer's responsibility.¶
• That the execution environment that produced the Action was intact. This profile occupies the use-time verification position and appraises no environment evidence (the role vocabulary of Section 3); no field defined by this profile carries a remote attestation result (Section 5.10).¶
• That the issuer is the entity it claims to be, beyond the signature. issuer_id is treated as opaque on verification and identifier resolution is out of scope per Section 5.1.3; the identifier's trust rests entirely on the Audit Pack trust-anchor metadata.¶
• That the signing key remained uncompromised, or that the endpoints did not collude. Signature validity is bounded by the revocation discipline of Section 11.4, and the collusion and key-compromise residuals are stated in Section 11.11 and Section 11.13.¶
• That a declared constraint was enforced at runtime. expires_at is declared, not enforced, against the receipt itself (Section 5.8); the producer-asserted extension fields of Section 5.13, Section 5.11, and Section 5.12 prove only that the producer asserted them at issued_at; and a voluntary-tier attestation is not a capture and is not unbypassable (Section 8.5).¶
• That the Action was prevented in real time. The receipt is detective, audit-time evidence; it does not block in-flight bytes (Section 11.11).¶
• That the artefact is tamper-proof. It is tamper-evident: modification of signed bytes, removal of a chain member, or re-signing of history is detectable by the recomputation of Section 10.2 under the chain and anchor discipline of Section 11.1, but the format exposes tampering rather than preventing it; prevention is a property of key custody, anchor cadence, and the emitter's operational controls.¶
• That the receipt is neutral third-party attestation. Every field is producer-asserted and the signature is producer-side, except where a Deployer operates an unaffiliated signer - a deployment property the format supports but cannot enforce (Section 11.11). Where the producer signs its own receipt, the receipt proves what the producer committed to, not what an independent party witnessed.¶
• That the Action's underlying transaction was delivered, settled, or otherwise brought to commercial finality. The receipt records the policy decision and the bytes that passed through; delivery, settlement, and payment finality are out of scope, and where a receipt is cited in a settlement context alongside a payment-gate format such as [DRAFT-HOPLEY-X402], it contributes only the action-side evidence.¶
• That every Action produced a receipt. A chain that passes every mandatory check of Section 10.2 proves only that the receipts it contains are unaltered and correctly linked; it is silent about an Action for which no receipt was ever minted. Selective omission is therefore invisible to chain integrity: an omitted Action leaves the chain verifying exactly as it would if the Action had never occurred, and a truncated tail is itself a valid chain, because links carry no sequence number and the anchors of Section 5.4 fix the presented receipts in time without revealing that later ones were withheld. Completeness comes from deployment, not from the format. Fail-closed capture (Section 8.5) refuses the Action when no receipt can be minted, and an Acceptor (Section 2) refuses to act on an Action that arrives without a verifiable receipt. The issuer evidences the gaps it can itself observe: a signer outage through unsigned_gap (Section 5.5), and a blocked emission through the chain_emission_blocked lifecycle receipt (Section 11.3). Independent custody of later receipts, whether by a counterparty whose counterparty_binding (Section 5.7) digests them, by the Acceptor that gated on them, or by the holder of an Audit Pack (Section 9) covering them, turns a truncated tail from invisible into contradicted. [ASQAV-SDK] carries these cases as conformance vectors (asqav-14-omitted-action-chain, asqav-15-unsigned-gap, and asqav-16-chain-emission-blocked); all three verify, the first because the chain cannot see the omission and the other two because the gap travels inside a conformant receipt.¶

12.1. Compliance Receipt Extension Fields Registry

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

This registry covers both signed-payload fields and envelope-level fields (siblings of payload and signature), as well as declarations that govern signing but never appear on the wire; each entry's Scope value identifies which.¶

Each entry contains:¶

• Field Name: a JSON object key, lowercase ASCII letters, digits, and underscore.¶
• Scope: one of signed-payload, envelope-level, or signing-time declaration, disambiguating fields inside the signed payload from envelope-level fields and from declarations that are not wire members.¶
• 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.¶
• Change Controller: the party authorized to request changes to the entry; the Change Controller for all initial entries is the IETF.¶

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

Initial registry contents:¶

• risk_class - Scope: signed-payload - Risk classification term under the Deployer's risk management documentation; defined in Section 5.6 - This document - Vocabulary referenced in Audit Pack metadata.¶
• incident_class - Scope: signed-payload - Incident classification term spanning DORA Article 18(1) (with further specification in [REG-2024-1772] and the canonical reporting enumeration of Annex II field 3.23 of [REG-2025-302]), 23 NYCRR 500.1 Cybersecurity Event/Incident, [CIRCIA] Covered Cyber Incident, and HIPAA security incident under 45 CFR 164.304; defined in Section 5.6 - This document - Audit Pack metadata.¶
• counterparty_binding - Scope: signed-payload - Signed-payload object carrying a base64-encoded SHA-256 digest (envelope_hash) of a peer agent's full signed envelope including signature bytes, a resolvable opaque locator (receipt_ref), an optional expected-acknowledger identifier (expect_ack_from), and an optional operational transport_label; see Section 5.7 for the full member set and the digest-scope rule - This document - Member vocabulary defined in Section 5.7.1; digest algorithm is SHA-256 per [ACTA-RECEIPTS] with base64 encoding per [RFC4648].¶
• result_digest - Scope: signed-payload - Object of the upstream payload_digest shape (hash, size, optional preview) carrying a SHA-256 digest of the downstream Action's result body; defined in Section 5.8 - This document - Digest algorithm is SHA-256 with hex encoding under the sha256:<64 hex> form.¶
• expires_at - Scope: signed-payload - ISO 8601 timestamp with explicit timezone declaring the wall-clock time after which the producing system considers the decision result stale and not safe to replay; declared, not enforced, against the receipt itself (the receipt record never expires); defined in Section 5.8 - This document - Free-form ISO 8601 string.¶
• nonce - Scope: signed-payload - Producer-generated string unique across the producer's emission stream for the lifetime of kid; defined in Section 5.8 - This document - Any unique string; the lowercase hexadecimal encoding of 12 random bytes (24 hexadecimal characters) is the recommended form.¶
• hash_algo - Scope: signed-payload - Member of the payload recording how the receipt's context digest was produced; sha256 denotes an unkeyed SHA-256 digest and hmac-sha256 an HMAC-SHA256 keyed digest under a holder salt; the digest string keeps the sha256:<64 hex> wire form in both cases; defined in Section 10.5 - This document - Value vocabulary {sha256, hmac-sha256} per Section 10.5.¶
• tool_fingerprint - Scope: signed-payload - JSON string of 32 lowercase hex characters carrying the truncated (first 128 bits) SHA-256 digest of the JCS-canonical ([RFC8785]) serialization of the JSON object {"tool_name": <tool name>, "schema": <declared input schema>}; defined in Section 5.8 - This document - Digest algorithm is SHA-256 over [RFC8785] canonical bytes, truncated to its first 32 hexadecimal characters.¶
• config_manifest_digest - Scope: signed-payload - JSON string formatted sha256:<64 hex> over the canonical bytes of the producer's configuration manifest in effect at signing time; defined in Section 5.8 - This document - Manifest content is operator-defined; canonicalization rule is operator-declared in the Audit Pack manifest entry.¶
• cve_inventory_digest - Scope: signed-payload - JSON string formatted sha256:<64 hex> over the canonical bytes of the producer's CVE inventory at signing time; defined in Section 5.8 - This document - Inventory content lists CVE identifiers per the producer's accepted-residual rationale.¶
• executable_hash - Scope: signed-payload - JSON string formatted sha256:<64 hex> over the canonical bytes of the executable that invoked the Action (OCI image manifest digest for container producers, on-disk SHA-256 for non-container executables); defined in Section 5.9 - This document - Digest algorithm is SHA-256.¶
• sbom_digest - Scope: signed-payload - JSON string formatted sha256:<64 hex> over the canonical bytes of the CycloneDX or SPDX SBOM document covering the executing image; defined in Section 5.9 - This document - SBOM format and version declared in the Audit Pack manifest entry.¶
• slsa_provenance_pointer - Scope: signed-payload - JSON string carrying an https URL resolving to the SLSA provenance attestation envelope for the build of the executable identified by executable_hash; defined in Section 5.9 - This document - Target should be the SLSA Provenance v1.0 in-toto statement form.¶
• supply_chain_pointer - Scope: signed-payload - JSON string carrying an https URL resolving to a transparency-log entry (in-toto, Sigstore, or Rekor) covering the build of the executable identified by executable_hash; defined in Section 5.9 - This document - Verifier acceptance is recommended across the three log formats.¶
• anchors - Scope: envelope-level - Envelope-level array of timestamping anchors covering the signed envelope; entries carry a required type discriminator (rfc3161 or opentimestamps; transparency-log pointers are not anchor types) and a required value field, plus optional informational members status (anchored / pending / failed) and anchor_block_hash (string Bitcoin block hash for upgraded OpenTimestamps entries); full schema is defined in Section 5.4 - This document - Anchor type vocabulary: rfc3161 per [RFC3161], opentimestamps per [OPENTIMESTAMPS].¶
• witness_policy - Scope: signing-time declaration (not a wire member) - Declaration the producer gives the issuing platform with the signing request, declaring an N-of-M durable-anchoring quorum over the receipt's anchors array; carries a required integer required in the closed range [1, length of witnesses] and a required non-empty array witnesses whose distinct values are a subset of {rfc3161, opentimestamps} (Rekor and other transparency-log pointers are not witness types and are rejected). The receipt reaches the quorum-met state only when at least required distinct witness types each hold a verifiable inclusion proof; a producer must not assert durable anchoring unless that holds, per the false-attestation rule of Section 5.4; defined in Section 5.4 - This document - Witness type vocabulary: rfc3161 per [RFC3161], opentimestamps per [OPENTIMESTAMPS]; inclusion-proof prior art per [RFC9943] and [RFC9162].¶
• mitre_techniques - Scope: signed-payload - JSON array of MITRE ATT&CK technique identifiers (for example T1059, T1078) self-declared by the producer; not verifier-checked by the issuing platform; flips framework_mappings_self_declared to true when populated; defined in Section 5.13 - This document - Vocabulary referenced by id from the MITRE ATT&CK enterprise matrix.¶
• mitre_atlas - Scope: signed-payload - JSON array of MITRE ATLAS identifiers (for example AML.T0051) covering AI-system-specific adversary techniques; self-declared; flips framework_mappings_self_declared to true when populated; defined in Section 5.13 - This document - Vocabulary referenced by id from the MITRE ATLAS catalogue.¶
• owasp_llm_top10 - Scope: signed-payload - JSON array of OWASP Top 10 for LLM Applications identifiers (for example LLM01, LLM02); self-declared; flips framework_mappings_self_declared to true when populated; defined in Section 5.13 - This document - Vocabulary referenced by id from the OWASP Top 10 for LLM Applications publication.¶
• nist_ai_rmf - Scope: signed-payload - JSON array of NIST AI Risk Management Framework function identifiers and subcategories (for example GOVERN-1.1, MEASURE-2.7); self-declared; flips framework_mappings_self_declared to true when populated; defined in Section 5.13 - This document - Vocabulary referenced from NIST AI RMF 1.0.¶
• iso_42001 - Scope: signed-payload - JSON array of ISO/IEC 42001:2023 control identifiers (for example A.6.2.6); self-declared; flips framework_mappings_self_declared to true when populated; defined in Section 5.13 - This document - Vocabulary referenced from ISO/IEC 42001:2023.¶
• eu_ai_act_articles - Scope: signed-payload - JSON array of EU AI Act article identifiers (for example Article-12, Article-15); self-declared; flips framework_mappings_self_declared to true when populated; defined in Section 5.13 - This document - Vocabulary referenced from [EU-AI-ACT].¶
• rfc3161_timestamp - Scope: signed-payload - JSON string carrying a base64-encoded RFC 3161 TimeStampResp (DER) supplied by the producer at signing time and preserved verbatim on the receipt for offline TSA chain verification independent of any platform-issued anchors; payload entry is an opaque caller-supplied token, not the per-receipt anchor produced by the platform; defined in Section 5.13 - This document - Bytes are an RFC 3161 TimeStampResp per [RFC3161]; base64 encoding per [RFC4648].¶
• framework_mappings_self_declared - Scope: signed-payload - JSON boolean false-attestation guard set by the issuing platform to true whenever any of mitre_techniques, mitre_atlas, owasp_llm_top10, nist_ai_rmf, iso_42001, or eu_ai_act_articles is populated; a producer-supplied value of false alongside a populated taxonomy field is overridden by the issuing platform; defined in Section 5.13 - This document - Boolean.¶
• authorized_under_mandate - Scope: signed-payload - Server-built object recording a self-declared authorizing mandate the Action was signed under; carries required mandate_id, required issuer_id, a required scope_digest formatted sha256:<64 hex> over the mandate's authorized-action-types scope, and a required verified boolean whose only conformant value is true, asserting self-declared issuer authority (the same trust level as framework_mappings_self_declared, never issuing-platform-verified third-party authorization); a present-but-malformed object, including one carrying verified=false, is rejected at signing time by the false_mandate_attestation_guard; defined in Section 5.10 - This document - Member vocabulary defined in Section 5.10; scope_digest digest algorithm is SHA-256.¶
• controls_evaluated - Scope: signed-payload - Server-built object enumerating the enforcement controls that genuinely fired on this sign plus the allow result; member keys are a closed set (emergency_halt, delegation_scope, quorum, mandate, policy, content_scan, result) and an unknown key is rejected; a key is present only when its control ran (omission-over-false attestation), quorum requires fired=true plus a 64-hex attestation_hash, and a policy member asserting evaluation requires matched_count at least 1; a caller-supplied value is dropped before signing (the false_control_attestation_guard); defined in Section 5.10 - This document - Control-key vocabulary defined in Section 5.10.¶
• approver_id - Scope: signed-payload - Producer-asserted identity (bare kid or issuer_id) that authored a risk acceptance on a protectmcp:lifecycle:risk_acceptance receipt; a FIELD bound into the signed bytes with NO authority check, NO authentication, and NO identity resolution performed by the issuing platform, only the compliance_mode string-equality refusal against initiator_id (the risk_acceptance_self_approval_guard); required on the receipt type and enforced by the risk_acceptance_missing_required_field false-attestation guard; defined in Section 5.11 - This document - Bare-identifier form per Section 5.1.3.¶
• initiator_id - Scope: signed-payload - Producer-asserted identity (bare kid or issuer_id) that requested the acceptance; a FIELD bound into the signed bytes; under compliance_mode a value that string-equals approver_id is refused at signing time by the risk_acceptance_self_approval_guard (a string-incoherence check, not identity resolution; an absent field never fires it); defined in Section 5.11 - This document - Bare-identifier form per Section 5.1.3.¶
• acceptance_reason - Scope: signed-payload - Free-text producer rationale for accepting a risk; proves the rationale existed and was key-authored at issued_at, never parsed or scored; required on the risk-acceptance receipt type and enforced by the risk_acceptance_missing_required_field guard; defined in Section 5.11 - This document - Free-form string.¶
• accepted_at - Scope: signed-payload - Producer-asserted ISO 8601 authoring time of the acceptance; self-declared, distinct from the platform-attested issued_at and anchors times; defined in Section 5.11 - This document - Free-form ISO 8601 string.¶
• supersedes - Scope: signed-payload - Producer-asserted pointer (opaque receipt locator OR sha256:<64 hex>) to the prior risk-acceptance receipt this one replaces; proves the supersession claim existed at issued_at; the issuing platform NEVER invalidates the prior receipt (the chain of Section 5.3 is immutable, this is a forward pointer only); defined in Section 5.11 - This document - Opaque locator or sha256:<64 hex> digest.¶
• sarif_digest - Scope: signed-payload - JSON string formatted sha256:<64 hex> over the producer-declared canonical bytes of the SARIF scan artifact the acceptance rested on; a SHAPE-ONLY existence proof that THAT artifact existed unaltered at issued_at and nothing more; the issuing platform NEVER parses, fetches, re-runs, or validates the scan; defined in Section 5.11 - This document - Digest algorithm is SHA-256; canonicalization rule declared in the Audit Pack manifest entry.¶
• finding_ref - Scope: signed-payload - Producer-asserted opaque free-text pointer to a finding or rule id inside the SARIF artifact; proves the reference existed at issued_at, never resolved or validated; defined in Section 5.11 - This document - Free-form string.¶
• approval_ref - Scope: signed-payload - Producer-asserted opaque free-text correlation pointer to a human-in-the-loop approval id or external ticket; proves the pointer existed at issued_at, never resolved or validated; defined in Section 5.11 - This document - Free-form string.¶
• risk_snapshot - Scope: signed-payload - Object carrying a producer-asserted point-in-time snapshot of THIRD-PARTY risk signals (snapshot_at, snapshot_source, optional epss, cvss, cvss_vector, kev_listed, cve_ids); the issuing platform does NOT fetch, compute, verify, query, or vouch for these values, and the snapshot is explicitly NOT reproducible from any input the platform holds; numerics are strings (floats prohibited per Section 4) and snapshot_source is required whenever any of epss, cvss, cvss_vector, or kev_listed is populated (a populated signal without it is rejected at signing time by the risk_snapshot_numeric_requires_snapshot_source guard) so a value can never be read as a platform-derived or verified score; defined in Section 5.11 - This document - Third-party feed vocabulary named per-receipt in snapshot_source; the platform defines no controlled vocabulary for the signal values.¶
• repo_ref - Scope: signed-payload - Producer-asserted opaque pointer to the repository a change was authored against, carried on a protectmcp:lifecycle:code_authorship receipt; required on the receipt type and enforced by the code_authorship_missing_required_field false-attestation guard; free-text, proves the reference existed at issued_at, never resolved, cloned, or validated by the issuing platform; defined in Section 5.12 - This document - Free-form string.¶
• commit_sha - Scope: signed-payload - Producer-asserted commit identifier of the authored change; required on the receipt type and enforced by the code_authorship_missing_required_field false-attestation guard; bound into the signed bytes only, NEVER fetched or verified by the issuing platform, proves only that the producer asserted it at issued_at; defined in Section 5.12 - This document - Free-form string.¶
• base_sha - Scope: signed-payload - Producer-asserted base commit identifier the change was authored on top of; bound into the signed bytes only, NEVER fetched or verified by the issuing platform; defined in Section 5.12 - This document - Free-form string.¶
• change_digest - Scope: signed-payload - JSON string formatted sha256:<64 hex> over the producer-declared canonical bytes of the change; a SHAPE-ONLY existence proof that THAT change existed unaltered at issued_at and nothing more; the issuing platform NEVER fetches, re-diffs, or re-computes the change; a value outside the sha256:<64 hex> wire form is rejected at signing time by the change_digest_not_sha256_wire_form guard; defined in Section 5.12 - This document - Digest algorithm is SHA-256; canonicalization rule declared in the Audit Pack manifest entry.¶
• change_ref - Scope: signed-payload - Producer-asserted opaque free-text pointer to the change as a unit (for example a pull-request id); proves the reference existed at issued_at, never resolved or validated; defined in Section 5.12 - This document - Free-form string.¶
• change_approval_ref - Scope: signed-payload - Producer-asserted opaque free-text correlation pointer to a human-in-the-loop approval id or external review ticket for the change; proves the pointer existed at issued_at, never resolved or validated; defined in Section 5.12 - This document - Free-form string.¶
• change_class - Scope: signed-payload - Producer-asserted class of the change drawn from the closed vocabulary read, write, delete, execute, deploy; self-declared, the issuing platform records but does NOT verify the change matches the class; a value outside the closed vocabulary is rejected at signing time as an out-of-vocabulary value; defined in Section 5.12 - This document - Closed vocabulary {read, write, delete, execute, deploy}.¶
• authored_by - Scope: signed-payload - Object carrying a producer-asserted description of the authoring agent (agent_id, model_id, model_version, tool, attestation_source); the issuing platform does NOT verify the named model; attestation_source is required whenever model_id or model_version is populated (a populated model field without it is rejected at signing time by the authored_by_model_requires_attestation_source guard) so a model claim can never be read as a platform-verified attestation; defined in Section 5.12 - This document - Member vocabulary defined in Section 5.12; the platform defines no controlled vocabulary for the member values.¶
• unsigned_gap - Scope: signed-payload - Server-built object evidencing a signer outage that preceded this receipt: count (REQUIRED integer greater than or equal to 1, the number of Actions the issuer attempted to sign and could not while the signer was unavailable), from and to (REQUIRED ISO 8601 timestamps with explicit timezone bounding the outage, with from not later than to). Absent when no outage preceded the receipt. The member is populated by the issuing platform from its own signer-failure tally, never carried in the producer's signing request, and a caller-supplied value MUST be dropped before signing. It makes a gap in the Action stream evidenced rather than silent: the chain links only receipts that exist, so without this member an Action for which no receipt could be minted leaves no trace. A verifier MUST NOT read the member as an assertion that the unsigned Actions were policy-evaluated; defined in Section 5.5 - This document - count is a JSON integer; timestamps follow [ISO8601-2].¶
• key_thumbprint - Scope: signed-payload - Server-built JSON string formatted sha256:<64 hex> carrying the RFC 7638 JWK Thumbprint of the receipt's signing key, committing the receipt to the exact key material so a key substituted under the same identifier is detected at verification; a caller-supplied value is dropped before signing; verifiers recompute the thumbprint of the resolved key and report mismatch as non-conformant, while absence is the legacy case and not itself a failure; defined in Section 5.1.8 - This document - Digest algorithm is SHA-256 over the RFC 7638 canonical JWK form per [RFC7638].¶
• environment_attestation - Scope: signed-payload - Normative-optional object carrying pre-action boolean world-state claims (claims) attested under a distinct environment key (attester_kid, attested_at, detached sig over the attestation object minus sig); informs the policy gate and the Audit Pack evidence list but never replaces the gate; a stale or unverifiable attestation is reported on its own axis; defined in Section 5.14 - This document - Member vocabulary defined in Section 5.14; claim names are free-form booleans.¶

This document additionally requests that IANA register counterparty_binding as a new claim in the "CBOR Web Token (CWT) Claims" registry established by Section 9.1 of [RFC8392], with the semantics defined in Section 5.7. The requested claim key is to be allocated by IANA under the Specification Required policy of that registry, from the integer range 256 to 65535 (or equivalently from the range -65536 to -257); this document does not request a specific value, so as not to consume the Standards Action space of the -256 to 255 range. The registration template of [RFC8392] Section 9.1.1 is completed as follows.¶

Claim Name:

counterparty_binding¶

Claim Description:

Cross-agent envelope binding: an object carrying a base64-encoded SHA-256 digest of a peer agent's full signed envelope including signature bytes, a resolvable opaque locator for that envelope, and optional members, as defined in the Counterparty Binding section of the specification document below.¶

JWT Claim Name:

N/A. The claim is specific to the compliance-receipt envelope of this profile; no equivalent JWT claim exists.¶

Claim Key:

To be allocated by IANA from the Specification Required range.¶

Claim Value Type(s):

Map (CBOR major type 5).¶

Change Controller:

IETF.¶

Specification Document(s):

This document, the section titled "Counterparty Binding" (Section 5.7).¶

The JSON-form claim name is the literal string counterparty_binding as registered above in the Compliance Receipt Extension Fields Registry.¶

Nothing in the initial contents above carries a remote attestation result, and this document defines no dedicated attestation-result field; such a field is future work only. The registry does not yet exist, and a later registration proposal for one would have to satisfy the Specification Required policy of this section, whose Designated Expert must verify that the Reference is a stable, dereferenceable specification, which an expiring Internet-Draft is not.¶

12.2. Compliance Receipt Type Namespaces Registry

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

Each entry contains:¶

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

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

Sub-namespaces are delegated to this registry: a namespace of the form parent:suffix under a registered namespace (for example a further sub-namespace under protectmcp:lifecycle or protectmcp:observation) is registered by a request that names the parent entry and the suffix, under the same Specification Required policy and with the same Change Controller as the parent entry.¶

Initial registry contents:¶

• protectmcp:acknowledgment - A receipt emitted by the acknowledging party ("B") in a counterparty_binding pair under the emitter behaviour of Section 5.7.2, carrying the counterparty_binding object that digests the bound A-party envelope per Section 5.7 - This document.¶
• protectmcp:decision - A receipt recording a policy evaluation outcome (allow, deny, rate_limit) for an MCP-mediated tool call where a policy was actually evaluated; observation is reserved to protectmcp:lifecycle and protectmcp:observation per Section 5.2 - This document.¶
• protectmcp:restraint - A receipt recording the application of an enforcement restraint on an agent (e.g., quota, rate limit, sandbox tightening); emission otherwise follows the decision path of Section 5.2 - This document.¶
• protectmcp:lifecycle - A receipt recording an agent or system lifecycle event (e.g., configuration change, key rotation, oversight review, or a decision=observation record indicating an Action was signed without policy evaluation per Section 5.2) - This document.¶
• protectmcp:lifecycle:configuration_change - A receipt recording a configuration change to an agent or producing system, including changes that disable or re-enable receipt generation (see Section 6.1.1); a registered sub-namespace under protectmcp:lifecycle that the reference cloud implementation emits today; a receipt of this type that lacks a well-formed config_manifest_digest (Section 5.8) is rejected at signing time per the type-bound presence rule of Section 5.8 - This document.¶
• protectmcp:lifecycle:risk_acceptance - A receipt recording a producer's acceptance of a known risk, security finding, or policy exception; a registered sub-namespace under protectmcp:lifecycle that signs through the no-policy lifecycle path (decision=observation, no policy evaluated) and carries the risk-acceptance extension fields of Section 5.11 - This document.¶
• protectmcp:lifecycle:code_authorship - A receipt recording a producer's assertion that an agent-authored change to a code repository existed at a point in time; a registered sub-namespace under protectmcp:lifecycle that signs through the no-policy lifecycle path (decision=observation, no policy evaluated) and carries the code-authorship extension fields of Section 5.12; the receipt proves only that the change existed, was key-authored, and was chained at the receipt time, and the issuing platform never clones the repository, re-diffs the change, verifies the code, or verifies the model - This document.¶
• protectmcp:observation - A receipt recording passive telemetry about an Action that was signed without a policy evaluation, emitted under one of the capture topologies catalogued in Appendix C (typically network_proxy, browser_extension, ebpf_observer, or mcp_proxy) where the originating application could not call the receipt-emitting SDK directly; the reference cloud implementation rejects at signing time, as the false_attestation_guard, a receipt that declares the passive_telemetry capture topology but carries a type outside protectmcp:observation and its sub-namespaces - This document.¶
• protectmcp:observation:result_bound - A sub-namespace under protectmcp:observation for a follow-up observation receipt that carries a result_digest (Section 5.8) binding the byte-equality of a downstream Action's result to the originating protectmcp:decision receipt identified by action_ref; the reference cloud implementation emits this type for tool calls whose downstream result is regulator-relevant (LLM completions under EU AI Act Article 12, audit-log entries under HIPAA 164.312(b), broker-dealer communications under SEC 17a-4); a receipt of this type that lacks a well-formed result_digest is rejected at signing time per the type-bound presence rule of Section 5.8 - This document.¶

B.1. Changes in draft -08

Attestation-statement and authoritative re-derivation revision. This revision defines an attestation statement envelope emitted on top of the receipt envelope, together with the rules that make an authoritative attestation independently re-derivable. The additions are additive: a -07 receipt is a conformant -08 receipt, and an implementation that emits no attestation statements remains fully conformant. No change to the wire bytes: the receipt envelope, the canonicalization transformation (JCS), the anchor type set, the retention floors of the European Union and United States bindings, the Audit Pack manifest fields, and the verifier reporting fields are unchanged; the description of the chain-digest scope is corrected, not changed (see the chain-digest bullet below).¶

• New normative Section 8 defines an attestation statement envelope (Section 8.1) as a Dead Simple Signing Envelope (DSSE, [DSSE]) Pre-Authentication Encoding wrapping an in-toto Statement v1 ([IN-TOTO-ATTESTATION]) under the asqav predicateType namespace https://asqav.com/, signed with ML-DSA-65 ([FIPS204]). Two tiers are defined: a voluntary (observation) attestation that signs a caller-supplied digest and is explicitly not a capture and not unbypassable, and an authoritative attestation whose subject digest the issuing platform re-derives from independent evidence. The producer-asserted receipts of Section 5.12 and Section 5.11 are identified as the receipt-layer expression of the voluntary tier and are unchanged.¶
• New normative Section 8.2 (the principal -08 addition) states the canonical code-authorship re-derivation rule: the issuing platform resolves a base commit identifier, re-fetches the raw unified diff for the base-to-commit_sha range from the source host (GitHub) with HTTP Accept: application/vnd.github.diff, and signs the SHA-256 of the exact response bytes; a client-supplied digest (for example change_digest) is advisory only, is compared and flagged on mismatch, and is never the signed subject. The signed subject is reproducible by any third party that re-fetches the same range and recomputes, which is what makes the attestation unforgeable; it does not make it unbypassable (unbypassability is a deployment property under Section 8.5).¶
• New normative Section 8.3 defines the server-derived capture_layer member (github_sha_pull and network_proxy as independent evidence; in_process_sdk and passive_telemetry as observation only) and the server-enforced receipt_type member (authoritative vs observation). An in-process capture can never mint an authoritative decision receipt, and the authoritative path fails closed when independent evidence cannot be obtained.¶
• New normative Section 8.4 defines the independent verification protocol: fetch the verification key from /.well-known/jwks.json by signature kid, verify ML-DSA-65 over the DSSE PAE, then re-derive the subject digest from independent evidence and require equality. A lying client can at best produce a non-gating observation or a digest that fails re-derivation.¶
• New normative Section 8.5 states the honest tier guarantees: the SaaS-SDK tier is a voluntary cryptographic attestation (non-repudiable for what was attested; not capture; not unbypassable), and the Enterprise-proxy tier is a real capture only for routed HTTP egress to public model APIs and only when the deployer firewalls egress and sets fail-closed, with unbypassability being the deployer's network policy rather than the product. The profile does not claim eBPF-based or shell-based capture.¶
• New normative Section 8.6 defines the dedicated service identity under which attestation statements are signed (the ML-DSA-65 algorithm is mandated in Section 8.1), publishes the public key at /.well-known/jwks.json, makes revocation checkable from the published JWK Set itself under the revocation-time model of Section 8.6 (the service identity is a bare JWK, so no PKIX revocation path applies), and requires verifiers to fail closed on revoked or unknown keys, composing with the revoked-key publication rule of Section 11.4.¶
• New informative reference: [DSSE] (the Dead Simple Signing Envelope specification). The [IN-TOTO-ATTESTATION] reference, previously cited only under Section 13, is now also cited under Section 8.1 for the in-toto Statement v1 form; its informative registration is unchanged.¶
• Chain-digest and signature-scope wording revision, answering Michael Msebenzi's first technical review of the published -07. Section 5.3 states the chain digest as SHA-256(JCS(R)) over the predecessor's payload member R without attributing that scope to upstream, and states it as a deliberate override of upstream's "Chain Hash Scope" section (Section 5.7 of [ACTA-RECEIPTS], which digests the entire receipt including the signature field); the "matches Section 5.7 of ACTA-RECEIPTS" claim is deleted and the migration requirement now follows from the override. The single-linear paragraph, the mandatory checks, the extension-field coverage statements, and the chain-commitment item of Section 9 point at the same local definition; the conformance bullet of Section 3 no longer defers to upstream's "Signature Scope" section (Section 5.6); the Appendix B.5 entry is corrected; and the interoperability note cites the published vectors of [ASQAV-SDK] as the byte-level tiebreaker. The wire bytes are unchanged: the reference implementation always signed and chained at the payload-member scope.¶
• Envelope-shape revision, answering Michael Msebenzi's second technical review of the published -07, whose measurement was taken against the APS gateway receipts of the [SCOPEBLIND] corpus. Section 5.3 fixes the envelope shape {payload, signature, anchors} once, before the exclusion clause, and defines the signed bytes (the JCS of the payload member) exactly once, every other site pointing at it. Upstream's "Signature Scope" section (Section 5.6) is noted as internally inconsistent and this profile follows its first sentence, as upstream Section 4.1 and the third-party ACTA artifacts in [SCOPEBLIND] do. Section 9 warns that receipts with top-level signed fields beside the signature exist in the wild and that the scope must be selected by format. New informative reference [SCOPEBLIND].¶
• Related-work and clarification revision, answering Anton Sokolov's review and the follow-up clarifications agreed with him. Section 13 gains an entry for [DRAFT-SOKOLOV-AEP-COMPOSITION] (an individual sketch, adapted, its swtpm result kept at feasibility level) and an invitation to contribute additions by email or on the list (the draft has no public source repository); new informative references [RFC9334], [RFC9999], and [DRAFT-SOKOLOV-AEP-COMPOSITION]. Section 5.10 is retitled "Enforcement-Control Record Extensions", gains a closed-key-set clarification, and extends the omission-over-false-attestation rule to external-freshness-check limitations. Section 5.8 is retitled "Result-Bound and Validity-Window Extensions"; its lead-in and the grouping labels are corrected; the nonce definition states that the nonce is NOT a challenge-response freshness proof; and its layering note is reworded accordingly. Section 3 gains an informative role-vocabulary paragraph. Section 12.1 records a dedicated attestation-result field as future work only, and config_manifest_digest notes that an operator's manifest MAY include an attestation or appraisal digest while no dedicated field is registered. In-body section self-references are corrected to the rendered numbering (the regulatory bindings are Sections 6 and 7). None of these changes alter a normative wire requirement.¶
• Independent-review revision, answering the 55-finding independent review of the -08 draft; the fixes below were each verified against the primary sources they cite. The two blocking findings are resolved: Section 11.2 is a new Security Considerations subsection requiring a verifier to determine the chain- and signature-scope from the receipt's format before verifying, to never retry the other scope on failure, and to report scope-derived failures distinctly from integrity failures; and the CWT claim request of Section 12.1 is rewritten to the Specification Required range and the full registration template of [RFC8392] Section 9.1. Other principal changes: Section 5.4 restates witness_policy as a signing-time declaration rather than a wire member, matching platform reality; Sections 6 and 7 replace "satisfies" with "provides evidence" framing; Section 8.2 states unforgeability-not-unbypassability and its GitHub-only scope; Section 8.4 is retitled "Independent Verification Protocol" and states its online dependencies; Section 8.6 moves revocation to a JWKS revocation-time model; Section 11.8 corrects the issued-at skew claim to state that replay bounding rests on the OPTIONAL validity-window fields of Section 5.8; Section 11.5 states that the CIRCIA preservation floor of Section 7.7.2 runs forward from report submission; Section 11.14 consolidates what a Compliance Receipt does not prove; Section 12.1 declares Scope and Change Controller columns, strips BCP-14 wording from registry descriptions, aligns six descriptions with their defining sections, and moves the two type-bound presence guards into Section 5.8; Section 13 qualifies the unaffiliated-operator posture as a deployment property the format cannot enforce, reframes the x402 comparison as broader in regulatory scope and narrower in payment semantics, and gains an entry for [DRAFT-MSEBENZI-EVIDENCE-ACTION]; references are pinned ([SCOPEBLIND], [ASQAV-SDK], [OPENTIMESTAMPS]) and corrected to their datatracker-recorded authors and revisions, with [DSSE], [IN-TOTO-ATTESTATION], and [ISO8601-2] moved to normative and [NIST-GENAI-PROFILE] to informative; and the appendices become numbered. No change to the wire bytes.¶
• Keyed-digest and verdict vocabulary revision. New normative Section 10.5 fixes the verifier verdict vocabulary at exactly three values (verified, verified_keyed, unverified), documents the hash_algo label that distinguishes keyed digests (hmac-sha256 under a holder salt) from unkeyed ones, and records the decision that the non-passing verdict renders as unverified (the reference platform's historical failed token maps to it). Section 12.1 registers the hash_algo signed-payload member with the value vocabulary {sha256, hmac-sha256}, matching the shipped reference SDK and platform behaviour. A receipt carrying a keyed digest is reported as verified_keyed, never as plain verified: the digest is internally consistent but not third-party re-derivable without the holder salt.¶
• Key-binding, environment-attestation, and scope-honesty revision. New normative Section 5.1.8 adds the server-built key_thumbprint field (JWK Thumbprint per the new normative reference [RFC7638]), committing each receipt to the exact signing key so a key substituted under the same identifier is detected; Section 10.2 enforces the recomputed-thumbprint equality check when the field is present and treats absence as the legacy case. New normative-optional Section 5.14 defines the environment_attestation extension carrying pre-action boolean world-state claims under a distinct environment key, with the hard composition rule that such attestations inform but never replace the policy gate. Section 11.14 gains the three remaining consolidated non-proofs (tamper-evident not tamper-proof; not neutral third-party attestation; no delivery, settlement, or commercial-finality guarantee), unifying the scattered scope-honesty statements without weakening any of them. Section 12.1 registers both new fields. All additions are additive: a -07 receipt remains a conformant receipt.¶
• Digest-scope mapping and failure-class revision, answering the external byte-for-byte reimplementation review. Section 4 states the payload-versus-envelope mapping explicitly (all signed content lives inside the payload member, so every digest in this profile resolves to the payload member, and no digest covers the envelope including the signature member) and adds the per-format rule: Compliance Receipts chain at payload-member scope while ACTA-family receipts verified under their native format keep the whole-receipt scope their own format defines, so an implementer switches digest scope on receipt format rather than keeping separate fixture sets. Section 10.5 adds the failure_class axis (invalid: a binding check ran and failed; unverifiable: the recomputation could not be completed), normative and never collapsed, matching the reference platform's verification detail and the reference SDK verifier. No wire bytes change and no section renumbers.¶
• Verifier-independence and receiving-side revision. New normative Section 10.1 requires verification to be performable independently of the issuing platform: no account, API credential, fee, or issuer-administered authorization may gate any verification step, a verification facility reporting verdicts only to registered callers is not a Compliance Verifier, and the neutral-third-party position is always achievable whichever party operates the verifier. Section 2 defines the Counterparty and Acceptor roles - the receiving side of an Action and the verification-gated acceptance position - so the receiving-side demand for receipts is named rather than implied. Section 13 gains an entry positioning the profile against [W3C-VC-2] and [W3C-VC-DI] (a Compliance Receipt MAY be embedded as the subject of a Verifiable Credential, and a neutral verifier should verify both surfaces without either substituting for the other) and sharpens the [RFC9943] citation to state that RFC 9943's normative scope is transparency over artefacts in a software supply chain, so the application of its inclusion-proof pattern to agent actions is this profile's generalization rather than an SCITT-defined semantics. New informative references: [W3C-VC-2], [W3C-VC-DI]. No change to the wire bytes.¶
• Editorial consistency revision. The validity-window layering note now names the registered duplicate_emission_candidate reporting axis (it previously named an unregistered duplicate_emission axis); the not_rederivable display-state mapping is corrected to verified_keyed (a passing display state cannot render as the non-passing unverified verdict); and the terms context digest and holder salt, which carry MUST-level verdict semantics in Section 10.5, are now defined, including the HMAC-SHA-256 construction and the salt-handling and erasure rules. No change to the wire bytes.¶
• Signer-outage and keyed-digest-detectability revision. New normative Section 5.5 defines the server-built unsigned_gap member, which evidences a signer outage in the next successfully signed receipt and is registered in Section 12.1. Section 10.5 gains the presence rule for hash_algo: a keyed digest MUST carry the member, because both forms share the sha256:<64 hex> digest wire form and without it a conforming verifier reports the stronger verified. Section 10.2 states that null, empty, and absent are malformed chain links rather than genesis markers. Both additions are additive: a receipt emitted without unsigned_gap and with an unkeyed digest is unchanged.¶
• Privacy identifier-minimisation revision. Section 11.6 adds the rule that no signed payload or extension field may carry an IP address, hostname, hardware or machine identifier, or geolocation in cleartext; environment facts travel as keyed digests per Section 10.5 or as the boolean claims of Section 5.14, the unkeyed sha256 form is barred for low-entropy identifiers as dictionary-recoverable and cross-receipt linkable, and holder-salt destruction is named as the erasure mechanism composing with the payload-deletion rule. No change to the wire bytes.¶
• Selective-omission honesty and reference-hygiene revision. Section 11.14 gains the consolidated non-proof that a chain passing every mandatory check does not prove every Action produced a receipt: the links cover the receipts that exist, so selective omission is invisible to chain integrity and a truncated tail is itself a valid chain, with completeness located in deployment (fail-closed capture, receiving-side demand, the issuer's own gap evidence, independent custody of later receipts) rather than in the format. [ASQAV-SDK] is re-pinned to the commit carrying the three conformance vectors that exercise the omitted-action, unsigned_gap, and chain_emission_blocked cases. Related work and references are refreshed against their current revisions. The [DRAFT-SHARIF-AAT] entry is corrected: that format already carried a required prev_hash chain and an optional agent signature in its -00, so the comparison now turns on mandatory platform signing, mandatory anchoring, and policy binding by digest. The three DRAFT-SHARIF references move to their -01 revisions. [DRAFT-SOKOLOV-AEP-COMPOSITION] moves from -03 to -05 with its pointers re-checked against the renumbered revision (the freshness-placement report is now its Section 14.1 and the swtpm feasibility work its Sections 12 and 13). The citation label for [DRAFT-MSEBENZI-EVIDENCE-ACTION] is corrected to the author's surname as the datatracker records it. RFC 8446 and RFC 6962 are replaced by [RFC9846] and [RFC9162], the RFCs that obsolete them. Additive throughout: no change to the wire bytes and no section renumbers.¶

B.2. Changes in draft -07

Reference-maintenance and editorial revision. This revision refreshes three reference citations to their current canonical locations and adds one parallel Related Work citation. No change to any normative requirement, signing algorithm, canonicalization transformation (JCS), hash-chain scope, anchor type set, retention floor, Audit Pack manifest, verifier reporting field, or IANA registry content; a -06 receipt is a conformant -07 receipt.¶

• The normative [ACTA-RECEIPTS] reference is advanced from the -01 to the -02 revision of the upstream draft, which is the current revision on the IETF Datatracker; the profiled envelope and field catalogue this document overlays are unchanged across that upstream revision.¶
• The informative [PIPELOCK-ER2] reference target is updated from the retired standalone vendor page to the project's live open-source repository, where the EvidenceReceipt v2 format is documented; the citation title and framing are otherwise unchanged.¶
• The informative citation for the Supply Chain Integrity, Transparency, and Trust architecture, cited in -06 as the Internet-Draft draft-ietf-scitt-architecture, is advanced to its published form: that draft has since been published as [RFC9943], and the reference and its citation label are updated from the Internet-Draft to the RFC. The related-work framing is unchanged.¶
• Section 13 is extended with a cite of [LYRIE-ATP] (the Agent Trust Protocol, an open cryptographic trust framework for AI agent identity published outside the IETF process), framed as parallel work whose Tamper-Evident Action Log of hash-chained signed action records overlaps this profile's per-action receipt surface and whose identity and delegation primitives sit on the identity-anchoring layer beneath it. New informative reference: [LYRIE-ATP].¶

B.3. Changes in draft -06

Risk-acceptance and code-authorship revision. This revision registers the risk-acceptance and code-authorship receipt types and their extension fields, which the reference cloud implementation, the asqav-sdk Python and TypeScript halves, and the published /.well-known/governance.json already emit and accept, keeping the IETF surface in parity with deployed reality. The additions are additive: a -05 receipt is a conformant -06 receipt, and a -06 receipt that carries the new fields remains a conformant [ACTA-RECEIPTS] receipt under the upstream extension semantics of Section 4.2 (verifiers that do not implement the extension ignore it).¶

• Section 12.2 Initial registry contents are extended with protectmcp:lifecycle:risk_acceptance, a registered sub-namespace under protectmcp:lifecycle recording a producer's acceptance of a known risk, security finding, or policy exception. It signs through the no-policy lifecycle path of Section 5.2 (decision=observation, no policy evaluated), so the false-attestation honesty rule is preserved: no policy result is asserted.¶
• New normative Section 5.11 defines the OPTIONAL signed-payload extension fields carried on a risk-acceptance receipt: approver_id and acceptance_reason (REQUIRED on the type), and OPTIONAL initiator_id, accepted_at, supersedes, sarif_digest, finding_ref, approval_ref, and the risk_snapshot object (snapshot_at, snapshot_source, epss, cvss, cvss_vector, kev_listed, cve_ids). The scope-honesty labels are normative: risk_snapshot is a producer-asserted snapshot the issuing platform never computes, fetches, verifies, queries, or vouches for and that is NOT reproducible from any input the platform holds; sarif_digest is a shape-only existence proof of the scan artifact at issued_at, never a re-scan; expires_at on the type is declared, not enforced (no auto-revoke); and approver_id and initiator_id are bound fields with NO segregation-of-duties check.¶
• Section 12.1 Initial registry contents are extended with the nine new risk-acceptance fields (approver_id, initiator_id, acceptance_reason, accepted_at, supersedes, sarif_digest, finding_ref, approval_ref, risk_snapshot), each labelled Scope: signed-payload, each carrying the normative producer-asserted scope labels. The existing expires_at entry is unchanged and is reused type-agnostically on the risk-acceptance receipt. Two false-attestation guards govern the type: risk_acceptance_missing_required_field (rejects a risk-acceptance receipt lacking approver_id or acceptance_reason) and risk_snapshot_numeric_requires_snapshot_source (rejects any populated epss, cvss, cvss_vector, or kev_listed without snapshot_source).¶
• Section 5.4 adds a one-line note that an rfc3161 anchor MAY be obtained from a Time-Stamping Authority operated independently of the issuer (a public RFC 3161 TSA under a distinct trust root), in addition to or instead of an issuer-operated TSA. The independently operated TSA is the genuinely independent witness of Section 11.7 and is one of the N witnesses of witness_policy, never the sole anchor. The baseline single-anchor requirement of Section 5.4 is unchanged.¶
• Section 12.2 Initial registry contents are extended with protectmcp:lifecycle:code_authorship, a registered sub-namespace under protectmcp:lifecycle recording a producer's assertion that an agent-authored change to a code repository existed at a point in time. It signs through the no-policy lifecycle path of Section 5.2 (decision=observation, no policy evaluated), so the false-attestation honesty rule is preserved: no policy result is asserted, and the receipt proves only that the change existed, was key-authored, and was chained at the receipt time.¶
• New normative Section 5.12 defines eight signed-payload extension fields carried on a code-authorship receipt, repo_ref and commit_sha REQUIRED on the type and the rest OPTIONAL: repo_ref, commit_sha, base_sha, change_digest, change_ref, change_approval_ref, change_class, and the authored_by object (agent_id, model_id, model_version, tool, attestation_source). The scope-honesty labels are normative: the issuing platform NEVER clones the repository, re-diffs the change, verifies the code, or verifies the model; change_digest is a shape-only existence proof of the change at issued_at never re-diffed; change_class is drawn from the closed vocabulary read, write, delete, execute, deploy; and authored_by model fields (model_id, model_version) require attestation_source. Authorization reuses the server-built authorized_under_mandate field of Section 5.10; no separate authorization field is defined.¶
• Section 12.1 Initial registry contents are extended with the eight new code-authorship fields (repo_ref, commit_sha, base_sha, change_digest, change_ref, change_approval_ref, change_class, authored_by), each labelled Scope: signed-payload. The authored_by_model_requires_attestation_source guard rejects a populated model_id or model_version without attestation_source; a change_class value outside the closed vocabulary is rejected at signing time as an out-of-vocabulary value.¶
• Section 13 is extended with a cite of [IN-TOTO-ATTESTATION] (the in-toto Attestation Framework, parallel work on the build-and-provenance surface) and [DRAFT-NELSON-DELEGATION] (Agent Delegation Receipts, parallel work on the delegation-and-authorization surface), both framed as complementary to the code-authorship layer. New informative references: [IN-TOTO-ATTESTATION], [DRAFT-NELSON-DELEGATION].¶
• The abstract and the Section 5.6 overview are extended to enumerate the risk-acceptance and code-authorship groupings. No changes to the signing algorithms, the canonicalization transformation (JCS), the hash-chain scope, the anchor type set, the retention floors of Sections 6 and 7, the Audit Pack manifest fields, or the verifier reporting fields.¶
• The deployed guard tokens that the issuing platform publishes in its /.well-known/governance.json wire-vocabulary surface are now named verbatim where the body defines each behaviour, completing the parity that Section 5.11 and Section 5.12 began: witness_policy_required_exceeds_confirmed (Section 5.4), false_attestation_guard and configuration_change_missing_config_manifest_digest and result_bound_missing_result_digest (Section 12.2), false_mandate_attestation_guard and false_control_attestation_guard (Section 5.10), and the code-authorship guards code_authorship_fields_require_code_authorship_receipt, code_authorship_requires_compliance_mode, code_authorship_requires_no_policy_decision, code_authorship_missing_required_field, and change_digest_not_sha256_wire_form (Section 5.12). repo_ref and commit_sha are labelled REQUIRED on the code-authorship receipt type, matching the deployed validator that rejects a receipt of the type lacking either field.¶
• Section 5.11 names the risk_acceptance_self_approval_guard: the reference cloud implementation refuses at signing time a risk-acceptance receipt signed under compliance_mode whose initiator_id string-equals approver_id, because a receipt asserting an approval flow approved by its own initiator is incoherent on its face. The guard is a string-incoherence check (case-sensitive exact match), not identity resolution; it fires only when both fields are present, and an absent field never fires it. The approver_id and initiator_id prose and their Section 12.1 registry entries are updated to name the guard, matching the deployed validator and the published /.well-known/governance.json labels.¶
• Deployed-vocabulary parity: the OPTIONAL informational member of an anchors entry carrying the Bitcoin block hash of an upgraded OpenTimestamps commitment is renamed to anchor_block_hash in Section 5.4, in the anchors entry of Section 12.1, and in the Appendix B.5 recap; the -05 member name tied the member to the Bitcoin chain by name, and the new name matches the wire key the reference implementation emits.¶
• The tool_fingerprint wire form in Section 5.8, its Section 12.1 entry, and the Appendix B.4 recap are corrected from sha256:<64 hex> to a bare string of 32 lowercase hexadecimal characters, and the digest input is pinned to the JCS canonicalization ([RFC8785]) of the JSON object {"tool_name": <tool name>, "schema": <declared input schema>}, matching the deployed producer and the deployed validator that rejects any other form.¶
• The nonce SHOULD-form in Section 5.8 and its Section 12.1 entry are corrected to the lowercase hexadecimal encoding of 12 random bytes (24 hexadecimal characters), the form the deployed producer emits; the -05 text named base64url and UUID/ULID forms the deployed producer does not use.¶
• The informational payload-capture manifest attribute recommended by the -05 text of the Appendix C appendix (the eBPF observer and passive-telemetry entries) is struck; the deployed Audit Pack manifest builder carries no such attribute.¶
• The mcp_proxy entry of Appendix C is rewritten to name the manifest attributes the deployed Audit Pack builder carries (action_type and, where declared, capture_topology) in place of an invoked-method attribute the builder does not emit, and the entry's reference-implementation hint is dropped: the entry defines the topology vocabulary only.¶
• Normative tightening in Section 5.7.3: where expect_ack_from is present, a mismatch between the acknowledging receipt's signature.kid and the declared identifier MUST cause the acknowledging receipt to be reported non-conformant, exactly as an envelope_hash digest mismatch is. This replaces the -05 rule under which the check was a SHOULD and a mismatch was reported as an axis flag; the check now fails closed, matching the deployed verifier. The expect_ack_from field definition in Section 5.7.1 is updated to point at the tightened rule.¶
• Section 11.4 adds the JWK Set publication rule for revoked keys: where the Deployer publishes verification keys through a well-known JWK Set endpoint, a revoked key remains published and its entry carries a revoked_at timestamp, so a verifier can pass a receipt issued before that instant and fail one issued at or after it, matching the deployed endpoint.¶

B.4. Changes in draft -05

Build-provenance and result-bound extension revision. This revision registers vocabulary that the reference cloud implementation, the asqav-sdk Python and TypeScript halves, and the published /.well-known/governance.json already emit and accept, bringing the IETF surface back into parity with deployed reality.¶

• New normative Section 5.8 defines six OPTIONAL signed-payload extension fields: result_digest (object of the upstream payload_digest shape carrying the downstream Action's result-body SHA-256), expires_at (ISO 8601 staleness bound additive to the 300-second forward-skew rule of Section 5.1.2), nonce (producer-unique replay-resistance value), tool_fingerprint (truncated tool-declaration SHA-256), config_manifest_digest (operator-defined configuration manifest SHA-256), and cve_inventory_digest (CVE inventory SHA-256 in effect at signing time). The six fields are type-agnostic; result_digest typically appears on receipts of the newly registered protectmcp:observation:result_bound namespace.¶
• New normative Section 5.9 defines a four-tuple of OPTIONAL signed-payload extension fields binding the executing build to the receipt: executable_hash (OCI image manifest digest for container producers, on-disk SHA-256 for non-container executables), sbom_digest (CycloneDX or SPDX SBOM SHA-256), slsa_provenance_pointer (https URL to the SLSA Provenance v1.0 in-toto attestation envelope), and supply_chain_pointer (https URL to an in-toto, Sigstore, or Rekor transparency-log entry covering the build). The four fields form a layered subsumption set; an implementation MAY emit any subset.¶
• Section 12.1 Initial registry contents are extended with the ten new fields registered in this revision (result_digest, expires_at, nonce, tool_fingerprint, config_manifest_digest, cve_inventory_digest, executable_hash, sbom_digest, slsa_provenance_pointer, supply_chain_pointer), each labelled Scope: signed-payload. The four pre-existing entries (risk_class, incident_class, counterparty_binding, anchors) are unchanged.¶
• Section 12.2 Initial registry contents are extended with protectmcp:observation (a passive-telemetry receipt emitted under one of the capture topologies of Appendix C when the originating application could not call the SDK directly) and protectmcp:observation:result_bound (a follow-up sub-namespace under protectmcp:observation for receipts carrying result_digest bindings to an originating protectmcp:decision receipt via action_ref).¶
• The abstract and Section 1.1 overview text are rewritten to enumerate the full extension-field set in five groupings (regulatory classification; cross-agent envelope binding; per-action freshness and integrity plus build-provenance; server-built enforcement attestation; and self-declared threat-framework taxonomy) rather than the legacy "three extension fields" phrasing carried forward from -02 through -04. The wire shape, the signature scope, the canonicalization rule, the hash chain, and the anchoring rules of earlier revisions are unchanged.¶
• New informative Section 13 cites parallel proposals under the Independent Submissions and individual-draft surfaces of the IETF Datatracker: [DRAFT-SHARIF-APKI] (certificate-based PKI for autonomous AI agents), [DRAFT-SHARIF-AML] (cryptographic attestation across the AI model lifecycle), and [PIPELOCK-ER2] (the Pipelock EvidenceReceipt v2 alternative receipt-format proposal, published as a public reference outside the IETF process). The section is non-exhaustive and is informative; this profile places no normative constraint on a Compliance Receipt implementation by virtue of citing parallel work.¶
• New informative references: [DRAFT-SHARIF-APKI], [DRAFT-SHARIF-AML], [PIPELOCK-ER2].¶
• The four-tuple of build-provenance extensions in Section 5.9 is the wire-level surface of the supply-chain notary use case; Deployers under [EU-AI-ACT] Article 12 read together with [DORA] Article 17, under 45 CFR 164.312(b) of [HIPAA-SECURITY], and under [SEC-17A-4] read with [NYDFS-500] 23 NYCRR 500.6, SHOULD emit at least executable_hash on every protectmcp:decision receipt. The wording is hortatory; the underlying regime obligations remain the load-bearing requirement.¶
• No changes to the signing algorithms, the canonicalization transformation (JCS), the hash-chain scope corrected in Appendix B.5, the anchor type set, the retention floors of Sections 6 and 7, the Audit Pack manifest fields, or the verifier reporting fields. A -04 receipt that omits all ten new extensions is a conformant -05 receipt. A -05 receipt that carries any of the ten new extensions remains a conformant [ACTA-RECEIPTS] receipt under the upstream extension semantics of Section 4.2 (verifiers that do not implement the extension ignore it).¶
• Threat-framework taxonomy subsumption. New normative Section 5.13 defines, and Section 12.1 Initial registry contents are further extended with, eight additional signed-payload entries that the reference cloud implementation, both SDK halves, and the published /.well-known/governance.json emit and accept: six caller-supplied taxonomy lists (mitre_techniques, mitre_atlas, owasp_llm_top10, nist_ai_rmf, iso_42001, eu_ai_act_articles), one caller-supplied opaque token (rfc3161_timestamp, a base64-encoded TimeStampResp per [RFC3161] preserved verbatim on the receipt for offline TSA chain verification independent of any platform-issued anchors), and one platform-set false-attestation guard boolean (framework_mappings_self_declared, set to true by the issuing platform whenever any of the six taxonomy lists is populated; a producer-supplied false alongside a populated taxonomy field MUST be overridden). The taxonomy fields are not platform-verified; the guard exists so verifiers can tell self-declared classifications apart from platform-verified ones. Pre-existing entries are unchanged. The total Initial registry contents now enumerate twenty-two signed-payload-or-envelope-level fields.¶
• Durable-anchoring quorum. Section 5.4 is extended with a normative OPTIONAL envelope-level witness_policy member (a sibling of payload, signature, and anchors) that the reference cloud implementation, both SDK halves, and the published /.well-known/governance.json emit and accept. witness_policy declares an N-of-M quorum over the anchors array: required (integer in [1, length of witnesses]) and witnesses (non-empty array, distinct subset of {rfc3161, opentimestamps}; Rekor and other transparency-log pointers are rejected). The quorum-met state (reported by the reference implementation as witness_quorum_met) is reached only when at least required distinct witness types each hold a verifiable inclusion proof; a receipt MUST NOT claim durable anchoring otherwise, extending the false-attestation principle to the anchoring quorum. Section 12.1 Initial registry contents are extended with the witness_policy entry, labelled Scope: envelope-level, bringing the total to twenty-three signed-payload-or-envelope-level fields. The baseline single-anchor requirement of Section 5.4 is unchanged and continues to apply to every Compliance Receipt regardless of whether witness_policy is present.¶
• Section 13 is extended with a cite of [RFC9943] (IETF SCITT architecture) and [RFC9162] (Certificate Transparency Merkle inclusion) as the canonical inclusion-proof prior art that witness_policy generalizes; SCITT is framed as complementary (a SCITT Transparent Statement can carry a Compliance Receipt as its payload), closing the append-only-log gap deferred under Section 11.13. New informative references: [RFC9943], [RFC9162].¶
• Enforcement-attestation extensions. New normative Section 5.10 defines two OPTIONAL server-built signed-payload extension fields that the reference cloud implementation and the published /.well-known/governance.json emit: authorized_under_mandate (an object recording a self-declared authorizing mandate with mandate_id, issuer_id, a scope_digest over the mandate's authorized-action-types scope, and a verified boolean whose true value asserts self-declared issuer authority, never platform-verified third-party authorization; the binding is evaluated against the issuing platform's clock and scoped to action types, with no value cap and no counterparty restriction) and controls_evaluated (a server-built enumeration of which enforcement controls genuinely fired on the sign, drawn from the closed key set emergency_halt, delegation_scope, quorum, mandate, policy, content_scan, result, where an absent key means the control did not run rather than that it passed silently). Both fields are server-built, never request inputs; a caller-supplied value is dropped before signing. Each field carries a false-attestation guard that rejects a present-but-malformed attestation at signing time. Section 12.1 Initial registry contents are extended with the two new entries, each labelled Scope: signed-payload, bringing the total to twenty-five signed-payload-or-envelope-level fields.¶
• Section 13 is further extended with a cite of [A2A] (the Agent2Agent protocol, a Linux Foundation project with an Agent Card, an extension mechanism, and an Agent Card JSON Web Signature), [A2A-IDF] (the Agent Identity Verification and Trust Framework proposal under the A2A contribution process, framed as the identity-anchoring layer beneath this profile's per-action receipts), and [DRAFT-HOPLEY-X402] (the closest parallel receipt format: a JCS-canonicalized, SHA-256 hash-chained Compliance Receipt with an ALLOW, REFER, or DENY admission verdict bound to a payment mandate under the x402 substrate). This profile is framed as the broader superset of the x402 format: general agent-action receipts across regulatory regimes rather than payment screening alone, neutral third-party signing rather than self-signing by the screening party, organisation-wide control attestation via controls_evaluated rather than a single admission verdict, and ML-DSA-65 post-quantum signing. New informative references: [A2A], [A2A-IDF], [DRAFT-HOPLEY-X402].¶

B.5. Changes in draft -04

Cross-agent integrity revision. The threat case is a compromised intermediary that swaps payload bytes between two honest agents while both per-agent hash chains validate independently.¶

• Section 5.3 digest-scope correction. The chain-link digest scope is the canonical signing-input bytes (the JCS-canonical serialization of the predecessor's signed payload object, the same bytes the predecessor's signature covers), NOT the envelope object that additionally includes the signature or anchors top-level keys. The earlier -04 text that said the digest covers "the entire signed receipt object including the signature field" was a Security Considerations over-reach that did not match the reference implementation and would have required every deployed chain to be re-issued. The corrected scope matches the reference implementation; upstream's "Chain Hash Scope" section (Section 5.7 of [ACTA-RECEIPTS]) digests the entire signed receipt object including the signature field, so the corrected scope is a deliberate override of the upstream rule rather than a restatement of it. The security rationale is updated accordingly: the chain binds the signed-over content of the predecessor (recomputable offline from the predecessor's payload alone), and cross-agent envelope-including-signature integrity is delegated to counterparty_binding (Section 5.7), which IS at the envelope-including-signature scope precisely because the peer signature is the load-bearing artefact in that case. Section 10.2 is updated to match.¶
• New informative Section 11.3 in Security Considerations acknowledges that the single-linear per-agent chain rule of Section 5.3 creates a per-issuer serialization bottleneck: a denial-of-service against the predecessor pointer (database lock, network partition, slow IO) bounds chain throughput. Mitigation: issuers SHOULD use bounded predecessor-lookup timeouts, emit a structured protectmcp:lifecycle audit event with a stable chain_emission_blocked reason code when the timeout fires, and document a chain-head recovery procedure for crashed emitters. Parallel per-issuer throughput beyond a single linear chain remains the existing distinct-issuer_id escape hatch.¶
• Section 11.13 residual list is rewritten for honesty. The M+B collusion residual is downgraded from "M+B alone defeats counterparty_binding" to "M+B+(A's-storage compromise or unavailability) defeats counterparty_binding": the audit-time verifier resolves receipt_ref to A's retained envelope and recomputes the digest, so an honest reachable A's storage defeats M+B collusion alone. A new M+A collusion residual is added: M and A coordinating to produce a fraudulent A-signed envelope is fundamentally outside the receipt model's threat surface because every cryptographic invariant holds; mitigation is separation of duties between issuer and intermediary plus anchor evidence on independent witnesses under different trust roots.¶
• The worked-example appendix carries an explicit disclaimer that the keys are shown in human-readable order (not JCS-canonical lexicographic order), the sig/value/hash bytes are deterministic placeholders, and implementations MUST NOT replay or trust the example as a real receipt. The disclaimer states the JCS-canonical key ordering that an implementer would derive on the wire.¶
• Section 5.7.1 envelope_hash rule is tightened on three axes. First, the base64 alphabet is no longer ambiguous: standard base64 per [RFC4648] Section 4 on emission, OR base64url per Section 5 where the transport requires URL-safe encoding, and verifiers MUST accept both and normalise before comparison. Second, JSON-framed digest scope is now normative and mandatory-to-implement: the JCS-canonical UTF-8 byte sequence of A's signed envelope JSON object per [RFC8785], where the envelope is the three-key object {"payload", "signature", "anchors"} with anchors OPTIONAL and B forbidden from re-canonicalizing or stripping any of the three keys before computing the digest. Third, cross-framing equivalence is explicitly addressed: JCS-canonical JSON, COSE deterministic encoding, and JWS Compact Serialization with JCS-canonical payload produce different byte sequences from the same semantic payload-and-signature, so envelope_hash is framing-specific; a transcoding intermediary that re-frames A's envelope MUST be treated as a tampering event, and verifiers MUST NOT reframe before recomputing.¶
• Section 12.1 entries now carry an explicit Scope tag (signed-payload for risk_class, incident_class, counterparty_binding; envelope-level for anchors). The CWT claim request for counterparty_binding now proposes allocation from the IANA First Come First Served range of [RFC8392] Section 9.1 rather than the unqualified "unassigned integer range" placeholder, so as not to consume Expert Review or Standards Action space.¶
• The [CIRCIA] reference is corrected to cite the statutory authority (Public Law 117-103 Division Y, codified at 6 U.S.C. 681 et seq.) rather than CISA's general topic page; the March 15, 2022 enactment date is retained, and the pending NPRM at 89 FR 23644 (April 4, 2024) is named in the reference annotation.¶
• New normative Section 4.6 (Section 5.7) defines the counterparty_binding extension field, an in-payload object carrying a base64-encoded SHA-256 digest (envelope_hash) over the full signed envelope of a peer agent (including the peer's signature bytes), a resolvable opaque receipt_ref, an OPTIONAL expect_ack_from identifier (kid/issuer_id of the expected acknowledger), and an OPTIONAL operational transport_label. Section 4.6.3 (Section 5.7.3) defines the MUST-reject rule when the bound digest does not resolve, the storage obligation on the Audit Pack production layer, and the pairwise default for N-greater-than-2 chains.¶
• The anchors top-level array schema is now defined inline in Section 5.4: each entry MUST carry type and value (base64-encoded anchor token bytes), with OPTIONAL informational status (anchored / pending / failed) and anchor_block_hash (Bitcoin block hash for upgraded OpenTimestamps entries). The IANA Extension Fields Registry entry for anchors is updated to reflect the four-member schema.¶
• The IANA Type Namespaces Registry initial contents now include the registered sub-namespace protectmcp:lifecycle:configuration_change emitted by the reference cloud implementation for configuration-change receipts under Section 6.1.1.¶
• CIRCIA retention floor (Section 7.7.2) is rewritten to measure two years from the submission of the most recently required CIRCIA report per proposed Section 226.13(c) of the CIRCIA NPRM at 89 FR 23644 (April 4, 2024), not from the date of the underlying Action.¶
• HIPAA retention (Section 7.4.2) is rewritten to cite 45 CFR 164.316(b)(2) with the six-year floor expressed as "six years from the date of creation or the date when last in effect, whichever is later" and the analogy basis for applying that floor to audit-log content explicitly named.¶
• EU AI Act Article 26(6) retention (Section 6.1.5) is rewritten to express the six-month floor in calendar-arithmetic terms per [ISO8601-2]; the 184-day day-count figure is retained as an informative anchoring-interval floor, and the previously-endorsed 183-day pick is withdrawn.¶
• Section 5.1.3 now states explicitly that issuer_id values MUST be bare identifiers without a scheme prefix where the scheme is unambiguous (LEI: 20-character alphanumeric self-identifying form), aligning the spec with the reference cloud emitter under the cloud-wire-conformance change.¶
• New informative Section 9.11 (Section 11.13) documents the residual threat that counterparty_binding partially mitigates (M silently swaps bytes between honest A and B) and names three operational mitigations Operators SHOULD adopt: multiple independent anchor witnesses, regulator-driven side-by-side chain comparison under SEC 17a-4 audit-trail workflow, and out-of-band M relay logs.¶
• Section 7 (Section 9) records two manifest-level fields shipped in the reference Audit Pack producer: regime_mapping_disclaimer (when per-receipt regime predicates derive from a producer-side mapping the original signer did not co-sign) and stale_pending (per-entry flag set when anchor evidence remains pending after the bound of Section 5.4).¶
• Section 8.3 (Section 10.4) replaces the prior one-paragraph clause with five SHOULD-emit per-axis fields: regimes_satisfied, anchor_valid_ots, anchor_valid_rfc3161, policy_digest_resolved, duplicate_emission_candidate.¶
• New informative Section 9.9 (Section 11.11) enumerates the residuals counterparty_binding does not solve. New informative Section 9.10 (Section 11.12) records channel-level operator guidance citing [RFC9846], [RFC9266], [RFC5705], and [RFC9421] and disclaims transport-layer security as a substitute for application-layer byte equality.¶
• Section 11 (Section 12) adds counterparty_binding to the Extension Fields Registry and requests registration as a CWT claim per [RFC8392].¶
• New normative references: [RFC9052], [RFC8949], [RFC7515], [RFC8392]. New informative references for channel-level guidance only: [RFC9846], [RFC5705], [RFC9266], [RFC9421].¶
• New normative Section 4 bounds the inputs to which the inherited JCS rule of [RFC8785] is applied: IEEE-754 floating-point numbers MUST NOT appear in the digest-covered canonical form (callers SHOULD serialize numerics as JSON strings or as integer-rational pairs in the IEEE-754 safe range), and tool-version-specific semantic equivalence (SQL case folding, path normalization, locale-aware string collation, numeric tolerance, URL percent-encoding choices) is OUT OF SCOPE for the chain layer. The chain answers byte equality for one agent identity at one wall-clock time only; semantic equivalence belongs in the policy_digest artefact and the Audit Pack manifest.¶
• Section 5.3 now states explicitly that each issuer MUST maintain a single linear per-agent chain and MUST serialize concurrent in-agent emission (parallel tool calls, thread-pool fan-out) through a single predecessor pointer in emission order. Parallel sub-chains within one agent identity (a per-receipt chain_id discriminator) are NOT defined by this profile; an issuer that requires parallel sub-chains MUST express each parallel path as a distinct agent identity with its own issuer_id, signing key, and chain rooted at the all-zero genesis value.¶
• Wire tightenings introduced in this revision (additive at the message level, restrictive at the verifier level): (a) the anchors entry value member is now REQUIRED where the upstream profile leaves it OPTIONAL; (b) issuer chains are normatively single-linear per issuer (no parallel chain_id discriminator), so a -03 producer that ran parallel sub-chains under one issuer_id emits non-conformant -04 receipts; and (c) IEEE-754 floating-point numbers MUST NOT appear in the canonical form covered by SHA-256 digests. A -03 receipt with a missing anchor value, parallel sub-chains, or a digest-covered float is not a conformant -04 receipt. Implementations targeting -04 SHOULD re-emit -03 receipts under -04 emission rules. The signing algorithms, the canonicalization transformation itself (JCS), the anchor types, and the regime bindings of Sections 6 and 7 are unchanged. A -03 verifier remains conformant for receipts that do not carry counterparty_binding; -03 verifiers encountering the field will ignore it per [ACTA-RECEIPTS] Section 4.2 extension semantics.¶
• Rationale paragraph of Section 4 is rewritten to ground the IEEE-754 float ban on documented divergence between mainstream JSON serializers (Python json.dumps, Go encoding/json, Java Jackson) and the ECMA-262 Number-to-String algorithm referenced by Section 3.2.2.3 of [RFC8785], rather than on a misstated claim that JCS itself fails to specify float serialization outside the safe integer range. The Unicode-normalization bullet of Section 4 is corrected to acknowledge that Section 3.1 of [RFC8785] mandates as-is preservation of Unicode strings (no NFC default).¶
• Security Considerations Section 11.1 is corrected to reflect the tiered DORA deadlines: the four-hour initial-notice clock (with 72-hour intermediate-report and one-month final-report bounds) per DORA Article 17 and the RTS in [REG-2025-301], rather than a flat 72-hour reporting deadline. New informative reference [REG-2025-301] added.¶
• The Annex II field 3.23 (Type of the incident) citation in Section 5.6 and the incident_class initial-registry entry of Section 12.1 no longer reproduces the enumeration verbatim; verifiers MUST resolve the canonical values from [REG-2025-302] directly.¶
• Section 5.2 extends the wire decision vocabulary with observation, a fourth value reserved to type protectmcp:lifecycle for receipts emitted when an Action was signed without any policy evaluation. The new value is the regulator-honest alternative to a misleading allow on the "no policy matched" path; emitters MUST refuse to issue a protectmcp:decision receipt that carries observation, and verifiers MUST reject the combination. The vocabulary-namespace registry entry for protectmcp:decision in Section 12.2 is updated to reflect that observation is reserved to protectmcp:lifecycle.¶
• New informative appendix (Appendix C) catalogues six capture topologies an operator can use to emit conformant Compliance Receipts in environments where the originating application code cannot be modified to call the receipt-emitting SDK directly: in_process_sdk, network_proxy, browser_extension, ebpf_observer, mcp_proxy, passive_telemetry. The appendix is non-normative; the capture_topology attribute it defines is OPTIONAL at the wire layer and, where present, lives in the Audit Pack manifest entry rather than inside the signed payload object, so the topology declaration does not alter signed bytes. The six values form a closed initial vocabulary at this revision; Appendix C.7 sketches a future "Compliance Receipt Capture Topologies" IANA registry under the "Compliance Receipts" registry group with Specification Required registration policy per [RFC8126] for a follow-on revision, and names reserved-value avoidance guidance for early extenders.¶

B.6. Changes in draft -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 [DORA] with the Annex II reporting enumeration, Cybersecurity Event/Incident under [NYDFS-500], Covered Cyber Incident under [CIRCIA], and security incident under [HIPAA-SECURITY]. 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 [EU-AI-ACT] (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 Section 500.6, leaving the 2017 single-tier text in force. The 1096-day three-year audit-trail floor previously stated for NYDFS is removed.¶

B.7. Changes in draft -02

Submission-ready EU-only profile. Wire-shape alignment with upstream [ACTA-RECEIPTS] (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.¶

B.8. Changes in draft -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.¶

B.9. Changes in draft -00

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

C.1. In-Process SDK

The originating application links the receipt-emitting SDK directly and calls it inline with the action being recorded. This is the baseline pattern [ACTA-RECEIPTS] and Section 5 of this document are written against. The receipt carries a full payload_digest covering the action's request bytes; the SDK has direct access to the application's principal identity, the policy decision, and the request body. Vocabulary value: in_process_sdk. Trust boundary: the application process itself; the SDK runs inside the application's memory space and inherits its principal. Threat-model note: captures the full request and response payloads, the deciding principal, and the policy context; does NOT capture out-of-process side effects or actions taken by sibling processes that do not link the SDK. Reference implementation hint: the Asqav Python and TypeScript SDKs published under the asqav-sdk umbrella implement this pattern; an operator MAY substitute any other conformant [ACTA-RECEIPTS] implementation.¶

C.2. Network-Layer Egress Proxy

A customer-owned reverse proxy or egress gateway (Envoy, NGINX, or an equivalent forward proxy) sits in the network path between the application and the downstream LLM provider. The proxy tees the request to a co-located Compliance Signer process, which receives the request bytes, applies the policy evaluation, and emits a receipt via a signer RPC. A DNS-rewrite on-ramp (CoreDNS rewriting the LLM hostname to the proxy address) or a Server Name Indication (SNI) router (SNIProxy at Layer 4) MAY be used to force application traffic onto the proxy without per-application configuration. Vocabulary value: network_proxy. Trust boundary: the customer's network egress; the proxy and signer run under the customer's operational control, and the receipt is signed by a key the customer's signer holds. Threat-model note: captures the request and response bytes that traverse the proxy and the network-layer principal identity (source IP, mTLS client cert if present); does NOT capture traffic that bypasses the proxy (direct outbound from a non-routed host, DNS-over-HTTPS to a hard-coded resolver, or TLS connections to certificate-pinned endpoints that the customer's enterprise CA cannot inspect). The receipt's issuer_id binds the customer's signer, not the originating application; the application's identity, where captured, appears as an attribute resolved through the Audit Pack manifest. Reference implementation hint: CoreDNS for the DNS on-ramp, SNIProxy by dlundquist for the SNI router, and Envoy for the Layer-7 reverse proxy plane; none of these are normative requirements.¶

C.3. Browser Extension

A managed-browser Manifest V3 (MV3) extension installed on employee workstations via the enterprise Mobile Device Management (MDM) system intercepts fetch, XMLHttpRequest, and EventSource requests to a configured list of LLM hostnames. The extension POSTs the intercepted request and response bytes to a Compliance Signer endpoint, which emits the receipt. For LLM hosts that pin their TLS certificates, the customer's enterprise root Certificate Authority (CA) MUST be installed in the browser trust store via MDM so that the extension's content-script interception can observe decrypted bytes. Vocabulary value: browser_extension. Trust boundary: the managed browser process on the employee workstation; the extension runs under the browser's sandbox and the employee's interactive session. Threat-model note: captures the full request and response payload for LLM calls initiated from the browser by the human user, and binds the receipt to the browser's principal identity (the user's enterprise single-sign-on subject, where the extension can read it). Does NOT capture LLM calls made by native desktop applications, server-side daemons, or browsers without the extension installed; does NOT capture traffic in incognito or private-window modes unless the extension is explicitly authorised for those contexts. Reference implementation hint: the open-source Chrome MV3 extension scaffolding published by Google under the chrome-extensions-samples repository is a useful starting point; the customer's signer endpoint is the Asqav signer or any conformant [ACTA-RECEIPTS] implementation.¶

C.4. eBPF SNI Observer

A kernel-level extended Berkeley Packet Filter (eBPF) probe attached to the host's network stack observes outbound TLS ClientHello records. The probe extracts the SNI hostname, the JA3 client fingerprint, the source and destination addresses and ports, and the connection timestamp, and emits a lower-fidelity receipt that binds the employee, the device, the wall-clock time, and the LLM host without observing payload content. Vocabulary value: ebpf_observer. Trust boundary: the kernel of the host on which the probe runs; the probe operates below the application's user-space process and observes traffic regardless of application configuration. Threat-model note: captures the existence and counterparty of an LLM call (the "did the call happen" evidence class) and the device-and-employee binding; does NOT capture request or response bytes, the prompt content, the model parameters, or the decision-relevant context. Useful when payload capture is operationally infeasible (TLS certificate pinning that the enterprise CA cannot defeat, third-party SaaS that egresses outside the customer's proxy plane) but the operator still needs evidence that a regulated LLM interaction occurred. Reference implementation hint: Inspektor Gadget and Tetragon both expose SNI and connection-metadata events from eBPF probes; neither is a normative requirement.¶

C.5. MCP Transparent Proxy

A transparent proxy sits in-path between a Model Context Protocol (MCP) client and one or more downstream MCP servers, terminating the client's stdio, Server-Sent Events (SSE), or streamable-HTTP transport on one side and re-establishing the same transport to each downstream server on the other side. The proxy observes every tools/call and resources/read JSON-RPC method invocation, signs a receipt at the moment the call is forwarded, and emits a second acknowledging receipt carrying a counterparty_binding (see Section 5.7) at the moment the downstream server's response returns. Both sides of the call are therefore bound bilaterally, with the proxy's signing key serving as the integrity anchor for the pair. Vocabulary value: mcp_proxy. The Audit Pack manifest entry for a proxy-captured receipt carries the receipt's action_type and, where declared, the capture_topology attribute, so a verifier can filter proxy-captured receipts without re-parsing payload bytes. Trust boundary: the proxy process and its signing key; the upstream MCP client and the downstream MCP server are both treated as honest endpoints under the threat model of Section 11.13, with the proxy itself being the named intermediary whose tampering risk counterparty_binding mitigates. Because both receipts of the pair are signed with the same proxy key, counterparty_binding detects a tampering proxy but not a compromised one: an attacker holding the proxy's signing key can forge both sides of the pair, so under proxy-key compromise the binding provides no evidence (the collusion residual of Section 11.11 applies with the proxy occupying both endpoint roles). Threat-model note: captures the full MCP request and response payload, the method name, and the client and server principal identities visible at the transport boundary; does NOT capture MCP traffic that bypasses the proxy or that uses a transport the proxy does not implement. This entry defines the topology and its vocabulary value only; no particular proxy implementation is referenced or required.¶

C.6. Passive Telemetry Ingestion

A passive ingestion pipeline reads structured records the originating application or its runtime has already emitted (for example, OpenTelemetry spans, application access logs, vendor-managed observability exports, or batch CSV drops) and synthesises a Compliance Receipt for each record after the fact. The synthesiser holds the signing key, applies the receipt-format wire profile, and emits the receipt to the same downstream sink that the in-process SDK and network-proxy paths feed. Vocabulary value: passive_telemetry. Trust boundary: the telemetry pipeline operator's signing key plus the integrity of the upstream observability source; the receipt binds the producer of the telemetry, not the originating application's per-request principal. Threat-model note: captures whatever the upstream telemetry source preserved (typically a subset of the action's bytes and metadata, often without request or response payload) plus the wall-clock and counterparty identifiers visible in the telemetry record; does NOT capture data the upstream source dropped, sampled out, or never emitted, and inherits any tampering risk the upstream source carries between emission and ingestion. Useful when the in-process SDK, network proxy, browser extension, eBPF observer, and MCP proxy topologies are all operationally infeasible (legacy applications without instrumentation hooks, third-party SaaS with read-only export, fleet migrations where the producer has only logs to work from) but the operator still needs a signed evidence artefact tied to the historical action. Reference implementation hint: any OpenTelemetry collector exporter feeding a conformant receipt-emitting signer; the upstream telemetry source is out of scope of this profile.¶

C.7. capture_topology Vocabulary and Considerations for a Future IANA Registry

The six values defined in this appendix (in_process_sdk, network_proxy, browser_extension, ebpf_observer, mcp_proxy, passive_telemetry) form the closed initial vocabulary for the capture_topology attribute. The attribute is optional at the wire layer and, where present, appears only in the Audit Pack manifest entry for the receipt, never inside the signed payload object, so that the topology declaration is producer-side metadata that does not alter the receipt's signed bytes. A verifier must not treat the absence of a capture_topology attribute as a non-conformance condition: absence simply means the producer did not declare a topology, and neither Section 10.2 nor Section 10.3 lists the attribute among the verifier's checks.¶

This document is an Independent Submission and does not request IANA action for the capture_topology vocabulary at this revision. A future revision MAY request creation of a "Compliance Receipt Capture Topologies" registry under the same "Compliance Receipts" registry group described in Section 12, with the registration policy of Specification Required per [RFC8126] and an initial set populated from the six values above. Until such a registry exists, implementations that extend the vocabulary SHOULD document the new value in a reference specification and SHOULD avoid colliding with the six reserved values above. The Designated Expert(s) for any future registry SHOULD verify that a candidate value names a distinct topology (a different trust boundary or a materially different payload-fidelity class) rather than a variant of an existing one, and that the candidate's threat-model note states what is captured and what is not, in the form used by the six entries in this appendix.¶