Back to blog

An IETF profile for AI agent compliance receipts

4 May 2026

We published an IETF Internet-Draft, draft-marques-asqav-compliance-receipts-08, that profiles the upstream draft-farley-acta-signed-receipts envelope with regulatory bindings. This post explains what the profile does, why each piece is there, and how the authoritative attestation and verification protocol fits in.

What the profile does

The upstream draft specifies a generic signed receipt envelope for AI agent actions: a wire format, a canonicalization rule, a signature suite, and an optional hash chain. It is intentionally regulation-agnostic. The Asqav profile takes that envelope as-is and adds four things on top of it.

  • It tightens fields that the upstream draft marks OPTIONAL into REQUIRED for any receipt that claims the profile, including payload_digest, action_ref, and policy_digest.
  • It sets a retention floor tied to the underlying regulation: 184 days (six months) for high-risk AI Act receipts, five years for DORA receipts under the sectoral instruments (MiFID II Art 16(7), AMLD Art 40).
  • It recommends timestamp anchoring on every receipt (SHOULD). Asqav-issued receipts carry an OpenTimestamps witness on all plans; Pro and Enterprise receipts also carry an RFC 3161 timestamp.
  • It adds two extension fields, risk_class and incident_class, drawn from controlled vocabularies that match the regulatory text.

A receipt that conforms to the Asqav profile is, by construction, a conformant upstream receipt. The signature validates with stock libraries. The chain validates with stock verifiers. A verifier that does not know about EU AI Act can still walk the receipt and confirm cryptographic facts. It just cannot attest the compliance bindings. Cryptographic validity and compliance attestation are different claims, and they fail independently.

A concrete binding

Article 12(2)(c) of the EU AI Act says the logging capabilities of a high-risk system must enable the recording of events relevant for "monitoring the operation of high-risk AI systems referred to in Article 26(5)", which is the deployer's monitoring duty. The profile's rule for this item uses the policy_digest field: when the policy changes, later receipts are bound to the policy version used for them. Substantial modification is a separate item, Article 12(2)(a), and the draft notes that it is not a 12(2)(c) obligation. A change in policy_digest between two otherwise-comparable Actions, same issuer_id, same action_ref family, same risk_class, can be examined as a candidate substantial-modification event under that item. The verifier surfaces those candidates. A human decides whether the change was substantial in the regulatory sense. The receipt log is the evidence trail. The binding lives in the field-level conformance rule, not in a separate PDF.

DORA Article 17 works the same way. The upstream draft says retention is out of scope. The profile sets a five-year floor for any receipt whose issuer_id is bound to a Financial Entity scope, sourced from the sectoral instruments (MiFID II Art 16(7), AMLD Art 40), and ties that floor to the OpenTimestamps anchor so deletion before the floor expires is detectable from the chain alone. If a receipt's anchor proves it existed five years ago and the producer cannot show it now, that is a finding. The supervisor does not have to take anyone's word for it.

The draft now maps the receipt format onto nine regulatory regimes across the EU and US: EU AI Act, DORA, NYDFS Part 500, NIST AI RMF, Colorado AI Act, Texas TRAIGA, CIRCIA, the HIPAA Security Rule, and SEC 17a-4. The pattern is the same in every case: pick the regulatory obligation, identify the receipt field that already carries the relevant fact, write a conformance rule that a verifier can mechanically check.

Authoritative attestation and verification

The draft registers code-authorship extensions and a verifier-behaviour protocol, and Asqav ships both. The authoritative attestation path, POST /code-authorship, re-fetches a commit from GitHub, re-derives the changed-files diff server-side, and signs the digest it computed. The signed subject is the server value, never a client-supplied one, so the producer cannot forge or backdate the record. The receipt carries the receipt type authoritative and the server-derived capture layer github_sha_pull.

The verification protocol is issuer-free. A third party resolves the signing key at /.well-known/jwks.json, recomputes the DSSE Pre-Authentication Encoding over the in-toto statement, and checks the ML-DSA-65 signature with no callback to Asqav. The same verifier walks the per-agent hash chain and checks the anchor. Because the authoritative digest is re-derived from a public commit, any third party that re-fetches the commit_sha reproduces it and confirms the subject independently.

Read the draft on the IETF Datatracker.

References