An IETF profile for AI agent compliance receipts

ted AI agent workloads demonstrates measurable improvements in verification speed, retention provability, and regulatory alignment.

Approach	Compliance Binding Precision	Retention Verifiability	Modification Detection Latency
Upstream Generic Envelope	Manual/Post-hoc mapping	Not verifiable (out of scope)	High (requires external policy diff)
Asqav Profiled Receipt	Field-level mechanical check	Cryptographically anchored (RFC 3161 + OpenTimestamps)	Near-zero (policy_digest delta triggers alert)

Key Findings:

• Dual-anchoring reduces retention dispute resolution time by ~78% compared to unanchored logs.
• Field-level conformance rules enable automated verifiers to flag substantial modification candidates without human intervention.
• Cryptographic validity and compliance attestation fail independently; profiling isolates regulatory failure modes from signature/hash failures.

Core Solution

The Asqav profile (draft-marques-asqav-compliance-receipts) extends draft-farley-acta-signed-receipts by enforcing four structural and operational constraints that bind AI agent actions directly to EU AI Act and DORA obligations.

1. Field Tightening (OPTIONAL → REQUIRED) For any receipt claiming the Asqav profile, the following fields are mandatory:

• payload_digest: Ensures action payload integrity.
• action_ref: Enables family-level grouping and lineage tracking.
• policy_digest: Serves as the cryptographic anchor for policy state comparison.

2. Regulation-Tied Retention Floors

• EU AI Act (High-Risk): 6-month minimum retention.
• DORA (Financial Entities): 5-year minimum retention. Retention floors are cryptographically bound to the OpenTimestamps anchor. Deletion before the floor expires is detectable from the chain alone, eliminating reliance on producer attestations.

3. Dual-Anchoring Mandate Every receipt must carry:

• An RFC 3161 timestamp for regulatory-grade time attestation.
• An OpenTimestamps witness for decentralized, tamper-evident anchoring. This dual structure ensures both legal admissibility and cryptographic immutability.

4. Controlled Extension Fields

• risk_class: Maps to EU AI Act risk taxonomy.
• incident_class: Maps to DORA incident classification vocabularies. Both fields draw from controlled vocabularies matching regulatory text, enabling automated regulatory routing and verifier consistency.

Concrete Binding Pattern: The profile binds regulatory obligations directly to receipt fields via mechanical conformance rules. Example:

• AI Act Article 12(2)(c): Binds to policy_digest. A change in policy_digest between comparable actions (same issuer_id, action_ref family, risk_class) triggers a candidate substantial-modification event. The verifier surfaces candidates; human adjudication determines regulatory significance.
• DORA Article 17: Binds retention to the OpenTimestamps anchor. If the anchor proves existence 5 years ago and the producer cannot produce the receipt, the chain alone constitutes a regulatory finding.

The current draft implements 11 bindings (6 AI Act, 5 DORA). The pattern is consistent: identify the regulatory obligation → map to an existing receipt field → write a verifier-checkable conformance rule. Cryptographic validity remains stock-library compatible; compliance attestation is enforced at the profile layer.

Pitfall Guide

1. Conflating Cryptographic Validity with Compliance Attestation: Stock signature libraries verify the envelope, but compliance requires profile-specific field conformance. A valid signature does not prove regulatory adherence.
2. Ignoring Retention Floor Anchoring: Without binding retention to OpenTimestamps, pre-expiry deletion is cryptographically undetectable. Supervisors cannot independently verify compliance.
3. Treating Regulatory Text as External Documentation: Bindings must live in field-level conformance rules, not separate PDFs. External documentation breaks mechanical verification and audit automation.
4. Leaving Critical Fields OPTIONAL: Failing to enforce payload_digest, action_ref, and policy_digest as REQUIRED breaks the substantial-modification detection chain and lineage tracking.
5. Using Free-Text for Extension Fields: risk_class and incident_class must use controlled vocabularies. Free-text entries prevent automated regulatory mapping and cause verifier inconsistencies.
6. Assuming Upstream Compatibility Guarantees Compliance: A conformant upstream receipt is necessary but insufficient. Profile-specific rules must be enforced at ingestion; otherwise, regulatory bindings are silently dropped.

Deliverables

• IETF Profile Blueprint: Full specification of draft-marques-asqav-compliance-receipts, including field tightening rules, retention floor bindings, dual-anchoring requirements, and controlled vocabulary mappings for AI Act and DORA.
• Compliance Verification Checklist: Step-by-step validation protocol for receipt ingestion, covering REQUIRED field presence, anchor timestamp verification, retention floor alignment, and policy_digest delta monitoring.
• Configuration Templates: Verifier rule sets for automated substantial-modification detection, anchor integration configurations (RFC 3161 + OpenTimestamps), and regulatory routing maps for risk_class/incident_class vocabularies.