Regulatory and Standards Alignment

Three documents from 2025-2026 - a European implementing regulation, a NIST concept paper, and the OWASP agentic applications list - independently name the same properties for trustworthy AI agent records: chronological ordering, tamper-evidence, and verifiable origin from an operator outside the recording party. This page maps where Asqav signed receipts share those properties, with a source for each claim.

One thing to state clearly before the mapping. Asqav is not a qualified trust service provider (QTSP), does not issue qualified electronic ledgers under eIDAS 2.0, and does not claim legal equivalence with any qualified service. The overlap here is structural. The properties the regulations treat as requirements - sequential ordering, immediate detectability of alteration, independently verifiable origin - are properties Asqav receipts provide by design, signed by an operator unaffiliated with the agent's operator.

eIDAS 2.0: Qualified Electronic Ledger Properties (CIR 2025/2531)

Commission Implementing Regulation (EU) 2025/2531, published 17 December 2025 and in force from 6 January 2026, lays down reference standards and specifications for qualified electronic ledgers under Regulation (EU) No 910/2014 as amended. The full text is at EUR-Lex.

The regulation defines properties that a qualified electronic ledger must satisfy. It does not require a blockchain or distributed ledger: DLT is one implementation option, and the core requirements hold either way. The three structural properties are:

How Asqav receipts align with these properties

Disclaimer. Asqav is not a QTSP and Asqav receipts are not qualified electronic ledgers. Asqav provides an unaffiliated, explicitly non-qualified notary service for AI agent activity. The mapping below describes structural alignment with properties that CIR 2025/2531 codifies, not equivalence to any qualified service.

CIR 2025/2531 property Asqav receipt field How receipts align
Sequential chronological ordering previousReceiptHash, issued_at Each receipt commits a SHA-256 hash of its predecessor's canonical bytes. A removed or reordered record breaks every subsequent link, making the reordering detectable. The server-attested issued_at timestamp is bound into the signed envelope.
Immediate detectability of alteration ML-DSA-65 (FIPS 204) signature over canonical bytes The signature covers every field in the receipt. A field altered after signing produces a verifiable signature failure. The signing key is held by Asqav as a party unaffiliated with the agent's operator, so the recording party cannot alter a signed record without the key holder detecting it.
Data origin agent_id, issuer_id, authorized_under_mandate The agent_id and issuer_id fields bind the identity of the agent and its operator into the signed envelope. The authorized_under_mandate block records the delegation chain. Together these fields provide verifiable evidence of the origin of each record.

The regulation's DLT-not-required stance is worth noting for teams evaluating infrastructure. CIR 2025/2531 specifies additional standards for ledgers that choose to use distributed ledger systems (ISO 23257:2022 and ISO/TS 23635:2022), but the core properties above do not require a blockchain or distributed log. Asqav achieves the same properties through cryptographic linking and out-of-process signing, without a distributed ledger.

Verification

The tamper-evidence properties described here can be checked independently using the open verifier, no Asqav account needed:

curl https://api.asqav.com/.well-known/governance.json | jq '.capabilities'

Look for sign, audit_trail_replay, and the hash_chain property. The Verify Without Asqav page covers offline chain verification.

NIST AI Agent Standards: Auditing and Non-Repudiation (February 2026)

The NIST National Cybersecurity Center of Excellence published a concept paper in February 2026 titled "Accelerating the Adoption of Software and AI Agent Identity and Authorization" (available at CSRC). The paper was open for public comment through 2 April 2026. It is a concept paper seeking stakeholder input, not a finalized standard.

Among the questions the paper poses to stakeholders, Section 5 addresses auditing and non-repudiation directly:

"How can we ensure that agents log their actions and intent in a tamper-proof and verifiable manner?"

"How do we ensure non-repudiation for agent actions and binding back to human authorization?"

NIST NCCoE Concept Paper, February 2026, Section 5: Auditing and non-repudiation

These are open questions, not finalized requirements. The paper frames them as areas where existing identity standards and best practices need to be worked out for AI agent architectures.

How Asqav receipts align with these guidance questions

Asqav signed receipts provide verifiable evidence that directly addresses the two questions the NIST paper poses:

Tamper-evident and verifiable logging. Each receipt is signed server-side with ML-DSA-65 (FIPS 204) by Asqav's keys, which are held outside the agent's environment. The signature covers the action type, timestamp, agent identity, and policy decision. The per-agent previousReceiptHash chain makes deletion or reordering detectable. An open verifier allows any party to check a receipt's integrity without trusting Asqav's infrastructure.

Non-repudiation binding back to human authorization. The authorized_under_mandate block records the mandate identifier, the issuer who granted authority, the scope digest, and whether the mandate was verified at signing time. This creates a signed link between the agent action and the human or organizational authority that authorized it, preserved in a form the authorizing party cannot later edit.

The NIST paper's non-repudiation question is specifically about "binding back to human authorization." The Mandate Binding receipt type addresses this directly: it records the delegated scope, the issuer, and the policy in a signed receipt that neither the agent nor its operator can alter retroactively.

OWASP Top 10 for Agentic Applications 2026: Signed Receipts and Immutable Audit Logs

The OWASP Top 10 for Agentic Applications 2026 (OWASP GenAI Security Project) identifies the ten highest-impact security risks for autonomous AI systems and recommends mitigations. Multiple items recommend signed receipts and immutable audit logs as mitigations. These are third-party security recommendations, not regulatory requirements.

The relevant mitigations, quoted from the framework:

"Maintain comprehensive signed audit logs of agent actions and communication."

OWASP Top 10 for Agentic Applications 2026, ASI10 (Rogue Agents)

"Maintain detailed tamper-evident logs and lineage metadata for forensic analysis."

OWASP Top 10 for Agentic Applications 2026, ASI08 (Cascading Failures)

"Sign and attest manifests, models, prompts, and tool descriptors."

OWASP Top 10 for Agentic Applications 2026, ASI04 (Agentic Supply Chain Vulnerabilities)

"Sign messages and embed nonces/timestamps to prevent replay."

OWASP Top 10 for Agentic Applications 2026, ASI07 (Insecure Inter-Agent Communication)

How Asqav receipts align with these recommendations

OWASP Agentic item Mitigation recommended Asqav receipt capability
ASI04 - Agentic Supply Chain Sign and attest manifests, models, prompts, tool descriptors tool_fingerprint (SHA-256 over tool name, schema, module path); executable_hash and sbom_digest on build-provenance receipts provide verifiable evidence of tool and model identity at the time of action.
ASI07 - Inter-Agent Communication Sign messages and embed nonces/timestamps to prevent replay The counterparty_binding field (SHA-256 digest of canonical request bytes) and server-attested issued_at timestamp together provide verifiable evidence against replay for inter-agent calls. The bilateral acknowledgment receipt type records both sides of a communication.
ASI08 - Cascading Failures Tamper-evident logs and lineage metadata The previousReceiptHash chain provides lineage metadata across the full sequence of agent actions. The chain supports forensic reconstruction of the sequence that preceded a cascading failure, because each link is signed and the chain breaks on any removal or reorder.
ASI09 - Human-Agent Trust Exploitation Immutable logs of agent suggestions and rationales The result_digest field (SHA-256 of the canonical response body) binds the exact output of each action into the signed receipt. Combined with previousReceiptHash, this provides an immutable record of what the agent produced and in what sequence.
ASI10 - Rogue Agents Comprehensive signed audit logs The combination of controls_evaluated (server-built, records which controls ran), authorized_under_mandate (what the agent was authorized to do), and risk_class (deployer-assigned classification) provides three signed signals of whether the agent operated within its intended scope.

The full field-by-field mapping of Asqav receipt fields to NIST SP 800-53 AU controls, NIST AI RMF GOVERN subcategories, and the complete OWASP Agentic top ten is in the NIST/OWASP Agentic Mapping page.

What Asqav is and is not

Asqav is not a QTSP, does not issue qualified electronic ledgers under eIDAS 2.0, and does not make legal compliance claims for any organization. Determining whether a given AI system is high-risk under the EU AI Act, or whether a given deployment satisfies any legal obligation, is the responsibility of the provider and its legal counsel.

Asqav signs each agent action record server-side with keys held outside the agent's operator's environment. The recording party cannot alter or backdate its own signed records without Asqav detecting it.

Related pages