]> Aqta Technologies Limited

Dublin Ireland hello@aqta.ai

Security attestation AI receipts audit Ed25519 This document specifies the on-the-wire format of an attestation receipt produced by an AI enforcement gateway at the moment it decides whether a large-language-model (LLM) call is permitted. A receipt binds that decision to a specific request under a published Ed25519 public key, so that a party who does not trust the gateway can still verify offline what was decided. The format is deliberately minimal, a fixed set of fields and a version-selected signature suite, chosen for the smallest possible independent verifier. It is intended for settings in which an operator-controlled log is not, on its own, sufficient evidence of the enforcement decision.

Introduction AI systems that take or influence consequential actions are increasingly deployed in regulated settings. When such a decision is later questioned, the party being questioned is frequently also the party that produced the record of the decision. A log an operator controls does not, on its own, let an independent reviewer confirm what a model was asked and what the enforcement layer decided. This document defines a compact receipt that an enforcement gateway signs at the moment it decides whether an LLM call proceeds. The receipt is verifiable offline by any holder of the issuer's public key, so the verifier need not trust the issuer's infrastructure at verification time. Related work exists. defines a compliance profile of signed action receipts for AI agents, and defines signed decision receipts for machine-to-machine access control. This document is narrower: it specifies a minimal, fixed twelve-field receipt for the LLM enforcement-gateway case, with a version-selected signature suite, chosen for the smallest possible verifier.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

Issuer:

The enforcement gateway that produces a receipt.

Subject:

The organisation, identified by org_id, for which enforcement is performed.

Verifier:

Any party that checks a receipt's signature against the issuer's published public key.

Receipt Structure A receipt is a single JSON object with exactly the following top-level fields. Receipts MUST NOT contain additional top-level fields in this version. Verifiers MUST reject receipts containing unknown top-level fields.

Field	Type	Description
v	integer	Format version. MUST be 1.
attestation_id	string	UUID version 4, unique per receipt.
trace_id	string	Issuer-assigned identifier for the LLM call.
org_id	string	Identifier of the subject organisation.
request_hash	string	SHA-256 hex digest of the canonicalised request body. 64 lowercase hex characters.
model	string	Provider-qualified model identifier.
outcome	string	One of the values in .
policy_applied	array	Lexicographically sorted array of ASCII policy identifiers.
cost_prevented_eur	number	Issuer estimate of spend avoided by a BLOCKED or SUPPRESSED outcome. Non-negative. MUST be 0 when not computed.
timestamp	string	RFC 3339 datetime with an explicit timezone offset.
public_key	string	base64url-encoded raw 32-byte Ed25519 public key, no padding.
signature	string	base64url-encoded 64-byte Ed25519 signature, no padding. Omitted from the canonical payload.

Outcome Values The outcome field MUST be one of:

ALLOWED:

Enforcement passed all policies; the request proceeded to the provider.

BLOCKED:

Enforcement blocked the request before invoking the provider.

SUPPRESSED:

Enforcement detected a runaway condition and suppressed the call.

PASSED:

A synonym of ALLOWED retained for backward compatibility. New issuers SHOULD emit ALLOWED.

Canonical Payload and Signing The canonical payload is produced by:

1. Removing the signature field, if present.
2. Serialising the remaining fields to JSON with all object keys sorted lexicographically and no whitespace between tokens.
3. Encoding the result as UTF-8, with non-ASCII characters emitted literally as UTF-8 and never as \uXXXX escapes (see ).
4. Serialising every integer-valued number, including a float such as 1.0, as an integer with no decimal point or trailing zero, and every other number as the shortest decimal representation that round-trips to the same value.

A number whose shortest representation requires exponential notation, meaning a magnitude below 1e-4 or at or above 1e21, is outside the range that implementations serialise identically, because they disagree on exponent formatting. An issuer MUST NOT sign such a value directly; where one would arise it MUST first be rounded to a value inside the safe range, as a cost estimate is rounded to two decimal places. This canonicalisation aligns in intent with the JSON Canonicalization Scheme but does not adopt its number serialisation; a later version may do so for full determinism across the exponential range.

Signature Suite and Algorithm Agility The version field v identifies the complete cryptographic suite, not only the field format. In version 1 the suite is Ed25519 over the canonical payload. The issuer signs the canonical payload bytes and places the base64url-encoded signature, without padding, in the signature field. A verifier MUST select the signature algorithm from v and MUST NOT infer it from the length or contents of the signature field. A future version of this format may define a post-quantum suite; a verifier that does not implement the suite named by v MUST reject the receipt rather than guess.

Request Hash The request_hash field is the SHA-256 digest, encoded as 64 lowercase hexadecimal characters, of the request body serialised by the canonicalisation of , including its number rule. This matters here in particular: a request body routinely carries non-integer sampling parameters such as temperature or top_p, so an issuer whose requests can contain numbers in the exponential range (see ) SHOULD round them before hashing. The digest is computed over the request body as received from the caller, before any redaction, so that a verifier holding the original request can reproduce it independently. A verifier that does not hold the original request treats request_hash as an opaque commitment.

String Canonicalisation Strings MUST be serialised as literal UTF-8. Escaping non-ASCII characters as \uXXXX produces different canonical bytes and MUST NOT be done; only the escapes required by are permitted. This rule exists because mainstream JSON serialisers disagree by default: some escape non-ASCII, some do not, and a receipt signed under one convention fails verification under the other while appearing valid within the issuer's own runtime. Issuers and verifiers MUST both emit literal UTF-8.

Verification A verifier holding the issuer's trusted public key:

1. Confirms all required fields are present and no unknown fields exist.
2. Reconstructs the canonical payload per .
3. Verifies the signature over the canonical bytes using the suite named by v and the trusted public key.

A verifier MUST reject a receipt whose embedded public_key does not match the public key it independently trusts for the issuer. Verifying only against the embedded key proves integrity, not issuer identity.

Security Considerations A receipt proves that the holder of the issuer's private key signed the stated enforcement decision over the stated request hash at the stated time. It does not, on its own, prove issuer identity; that requires the verifier to pin the issuer's public key out of band. A verifier that checks a receipt only against the public_key embedded in that receipt proves internal integrity but not that the receipt came from the expected issuer. Receipts contain no plaintext prompt or response, only a SHA-256 request hash, so a receipt discloses no request content. A verifier cannot recover the request from a receipt, and a leaked receipt therefore does not expose prompt or response data. Ed25519 is not post-quantum secure. An adversary with a cryptographically relevant quantum computer could forge signatures under an issuer key that was active before migration, which matters where audit retention, for example five to ten years, intersects that horizon. Two properties bound this. First, the SHA-256 request binding, and any receipt chain built on SHA-256, remain quantum-resilient tamper anchors, so a verifier can still detect alteration of past receipts. Second, because the version field selects the whole suite (see ), a later version can introduce a post-quantum signature suite without changing the receipt structure, and receipts signed under different suites remain distinguishable by version. This document does not define such a suite.

IANA Considerations This document has no IANA actions. A future revision may request registration of a media type for the receipt object.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Informative References Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. Asqav This document defines a multi-jurisdiction compliance profile of the signed action receipt format used by AI agents to record machine- readable evidence of access-control decisions. The profile binds receipt fields to two regulatory surfaces: on the European Union side, Articles 12 and 26 of the EU AI Act (Regulation (EU) 2024/1689) and Article 17 of DORA (Regulation (EU) 2022/2554); on the United States side, the NIST AI Risk Management Framework, the Colorado AI Act, the Texas Responsible AI Governance Act, the New York Department of Financial Services Cybersecurity Regulation (23 NYCRR Part 500), the HIPAA Security Rule, SEC Rule 17a-4, and the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA). Working entirely within the existing wire format, canonicalization transformation, and signing algorithms of the underlying receipt format, the profile tightens a subset of the OPTIONAL fields to REQUIRED, imposes a retention floor, and requires at least one timestamping anchor (RFC 3161 or OpenTimestamps). It registers OPTIONAL extension fields for risk and incident classification, cross-agent envelope binding, per-action freshness and integrity, build provenance, threat-framework taxonomy, server-built enforcement attestation, producer-asserted risk acceptance, and producer-asserted code authorship, each subject to false-attestation guards where applicable, and registers receipt type namespaces for passive- telemetry, result-bound observation, risk-acceptance, and code- authorship receipts. The full field set and its normative requirements are defined in the body of this document. ScopeBlind (Veritas Acta) This document defines a portable, cryptographically signed receipt format for recording machine-to-machine access control decisions. Each receipt captures the identity of the decision maker, the tool or resource being accessed, the policy evaluation result, and a timestamp — all signed with Ed25519 [RFC8032] and serialized using deterministic JSON canonicalization [RFC8785]. The format is designed for environments where AI agents invoke tools on behalf of human operators, particularly the Model Context Protocol (MCP) ecosystem. Receipts are independently verifiable without contacting the issuer, enabling offline audit, regulatory compliance, and cross-organizational trust federation.

Reference Implementations Open-source reference verifiers implementing this format are published as "aqta-verify-receipt" on PyPI and npm.