]> Aqta Technologies Limited

Dublin Ireland hello@aqta.ai

Security attestation AI receipts audit Ed25519 This document specifies a compact JSON attestation receipt for an AI inference decision. A receipt binds an outcome to a request hash under a published Ed25519 public key, so a party that does not trust the issuer's infrastructure can still verify offline what the issuer's signing key attested was decided. The format is intentionally small and version-selected, so independent verifiers stay easy to implement and audit. It is intended for settings where an operator-controlled log is not, on its own, sufficient evidence of the 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 was asked or what was decided. This document defines a compact receipt that an issuer signs for an LLM inference decision. The receipt is verifiable offline by any holder of the issuer's public key. The verifier need not contact the issuer at verification time.

The figure is informative. The normative processing rules are in and . Note that the verifier obtains the public key out of band; the key carried in the receipt establishes integrity, not the identity of the issuer.

Relationship to Other Work Related Internet-Drafts address neighbouring problems. profiles signed action receipts for AI agents. defines signed decision receipts for machine-to-machine access control, using RFC 8785 for canonicalisation. profiles COSE and CWT to bind model identity, input and output hashes and platform attestation evidence into one signed artefact for inference inside a trusted execution environment. It answers a question this document explicitly does not, namely what a TEE-resident workload can assert about the environment that executed a particular inference. These documents address adjacent or overlapping receipt problems, and AIR in particular solves a different one: it binds a receipt to a confidential workload and requires a verifier to appraise platform attestation before execution provenance is established. This document instead specifies one deliberately smaller application-layer receipt shape for the LLM inference decision case, with an explicit verification algorithm, a version-selected signature suite, and published conformance vectors. Implementations MAY also implement the related drafts; this document does not redefine them.

Key Lifecycle This document assumes the verifier already holds a public key it has reason to trust, and does not define how that key is distributed, rotated, revoked, or evaluated for validity at a past point in time. For evidence retained over years these are load-bearing: a key compromised in a later year casts doubt on receipts nominally issued before it, and this format alone provides no way to distinguish them. Addressing that requires mechanisms outside this document, such as key transparency, an append-only log of issuance, or third-party witnesses. A later version may profile one.

Non-Goals This document does not: Claim that a decision was correct, safe, lawful, or free of model error. Define policy language, agent tool protocols, or model evaluation methods. Require a Trusted Execution Environment, hardware root of trust, or qualified timestamp authority. Define deployment topology, commercial packaging, or product features beyond the receipt bytes. Replace platform attestation documents (for example TEE quotes). A receipt is application-layer evidence of a decision, not hardware evidence of the runtime. A receipt that verifies proves only what states.

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 system that produces and signs a receipt.

Subject:

The organisation, identified by org_id, for which the decision was made.

Verifier:

Any party that checks a receipt's signature against a public key it trusts for the issuer.

Trusted public key:

The Ed25519 public key the verifier has obtained out of band for the issuer. It is not sufficient to trust only the public_key field embedded in a receipt.

Receipt Structure A receipt is a single JSON object . Version 1 defines the required fields in and the optional fields in . Unless a field is listed in this document for version 1, it MUST NOT appear at the top level. Verifiers MUST reject receipts that contain unknown top-level fields. This closed set keeps independent verifiers simple and prevents silent semantic drift.

Required Fields Field Type Description v integer Format and suite version. MUST be 1 for this document. attestation_id string UUID string, unique per receipt. Production issuers SHOULD use UUID version 4. trace_id string Issuer-assigned identifier for the LLM call. org_id string Identifier of the subject organisation. request_hash string SHA-256 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 UTF-8 string policy identifiers. MAY be empty. cost_prevented_eur number Non-negative number. MUST be 0 when not computed. See . 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.

Optional Fields The following fields MAY appear. If present, they MUST match the types below. They are ignored by signature verification except that they participate in the canonical payload when present (see ). Field Type Description prev_attestation_id string attestation_id of a prior receipt in an issuer-defined chain. prev_attestation_hash string SHA-256 hex digest binding this receipt to prior receipt bytes, as defined by the issuer. spec_version string If present, MUST be the ASCII string "ATTESTATION-v1". If prev_attestation_id is present, prev_attestation_hash MUST also be present. Verifiers that do not implement chaining MUST still accept well-formed receipts that include these fields, and MUST still enforce the signature and required field checks. Because these fields are optional and issuer-populated, they make a sequence tamper-evident to a party that follows the whole sequence. They do not make an individual receipt tamper-proof, and they do not constrain an issuer that emits unchained receipts or that omits a decision from the chain entirely. Detecting omission requires evidence outside this format.

cost_prevented_eur cost_prevented_eur is retained for wire compatibility with existing version-1 issuers. It is an issuer estimate only. It is not part of the security claim of the receipt. New issuers SHOULD emit 0. Verifiers MUST NOT treat a non-zero value as proof of savings, risk reduction, or policy quality.

Outcome Values The outcome field MUST be one of:

ALLOWED:

The request was permitted to proceed to the model provider.

BLOCKED:

The request was not sent to the model provider.

SUPPRESSED:

The request was not sent because the issuer detected a runaway or loop condition.

PASSED:

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

What a Verified Receipt Proves A receipt that verifies under a trusted public key proves that the holder of the corresponding private key attested to the included fields, including outcome, request_hash and the stated timestamp value. It does not prove that the underlying model output was correct, that the policy identifiers were appropriate, or that the issuer's process was fair. The request_hash is a commitment, not a disclosure. It does not reveal the request, and it does not on its own establish that any particular request was the one presented to the issuer. It lets a verifier that already holds a candidate request test whether that candidate matches the commitment. What was decided is established by the signed outcome field, not by the hash. See for the case where the request is low-entropy enough to be recovered by hashing candidates. The receipt does not independently establish when the attestation was made. The timestamp is a field chosen by the issuer and covered by the signature, so a verifying receipt shows that the issuer signed that value, not that signing occurred at that time. Establishing when a receipt existed requires evidence outside this format, such as inclusion in an append-only log observed by a third party, or a timestamp from an authority this document does not define.

Canonical Payload and Signing The canonical payload is produced by: Rejecting the receipt if the JSON object contains duplicate member names at any level, or if any string is not well-formed UTF-8. notes that implementations disagree over which value wins when names repeat, so a receipt containing them has no single canonical payload and MUST NOT be treated as verifiable. Removing the signature field, if present. Serialising the remaining fields to JSON with all object keys sorted lexicographically and no whitespace between tokens. Encoding the result as UTF-8, with non-ASCII characters emitted literally as UTF-8 and never as \uXXXX escapes (see ). 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 IEEE 754 binary64 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 common implementations serialise identically. An issuer MUST NOT sign such a value directly; where one would arise it MUST first be rounded into the safe range (for cost_prevented_eur, to two decimal places). This canonicalisation aligns in intent with the JSON Canonicalization Scheme but does not adopt its number serialisation. A later version of this format MAY adopt RFC 8785 fully; such a change requires a new v value.

Signature Suite and Algorithm Agility The version field v identifies the complete cryptographic suite, not only the field layout. 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 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 applying the same canonicalisation algorithm defined in to the request JSON, including its number rule. The algorithm is identical; only the input differs. Request bodies often carry non-integer sampling parameters such as temperature or top_p, so an issuer whose requests can contain numbers in the exponential range 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. 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. Mainstream JSON serialisers disagree by default on this point. Issuers and verifiers MUST both emit literal UTF-8.

Verification A verifier that holds a trusted public key for the issuer: Confirms all required fields are present and well-typed for , including: request_hash is 64 lowercase hex characters; public_key and signature decode as unpadded base64url to 32 and 64 bytes respectively; cost_prevented_eur is a non-negative number; timestamp is an RFC 3339 datetime with an explicit timezone offset; and policy_applied is an array of strings in lexicographic order. Confirms no unknown top-level fields exist. Confirms optional fields, if present, satisfy . Confirms outcome is one of the values in . Confirms the embedded public_key equals the trusted public key. Reconstructs the canonical payload per . Verifies the signature over the canonical bytes using the suite named by v and the trusted public key. Verifying only against the embedded public_key, without an out-of-band trust decision, proves integrity of the object but not issuer identity.

Conformance An implementation claiming conformance to this document MUST: Produce or accept receipts matching . Implement canonicalisation and verification as specified in and . Reject the invalid cases described by the published conformance vectors referenced in . Informative interoperability artefacts, including valid and invalid receipts and a fixed test public key, are published with the ATTESTATION-v1 specification repository. Those vectors are not normative text of this document; if a vector and this document disagree, this document prevails, and the vector set SHOULD be corrected.

Security Considerations The trust boundary this format establishes, and the questions it leaves open, are summarised below. The figure is informative; the normative rules are in and .

| creates the receipt | | chooses the timestamp | | holds the signing key | +------------+------------+ | signed receipt | v +-------------------------+ | Verifier | | holds a trusted key | | recomputes the payload | | checks the signature | +------------+------------+ | v the signed fields are authentic and have not been altered NOT ESTABLISHED BY THIS FORMAT ALONE +-------------------------------------------------------+ | when the receipt existed -> append-only log, | | witness, or a | | timestamp authority | | that the claimed model ran -> platform attestation| | that no decision was omitted -> reconciliation | | against a record | | the issuer does not | | produce | | that the decision was correct -> outside any | | evidence format | | that a later key compromise -> key transparency, | | does not undermine old -> revocation, or | | receipts -> historical status | +-------------------------------------------------------+ ]]>

Note that the issuer controls both the signing key and the timestamp, so a verifier that trusts the key learns what the issuer asserted and that nobody altered it afterwards. Every item in the lower box requires a mechanism this document does not define.

Issuer Identity A receipt proves that the holder of a private key signed the stated fields. It does not, on its own, prove which organisation that key represents. Verifiers MUST pin the issuer's public key out of band (for example via a published key URL, an enterprise configuration, or a trust list).

Confidentiality of Requests Receipts contain no plaintext prompt or response, only a request hash. For a high-entropy request body the hash reveals nothing useful by inversion. Where the request body is low-entropy or guessable, an attacker can hash candidates and match. Deployments MUST treat request_hash as potentially personal data and apply their own data-protection controls. Issuers that require pseudonymity SHOULD hash with a key kept secret from verifiers, at the cost of offline reproducibility by third parties.

Integrity Versus Correctness Signature verification establishes integrity and issuer attribution under a pinned key. It does not establish that the decision was the right decision.

Post-Quantum Considerations 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 long audit retention intersects that horizon. SHA-256 request binding remains useful as a tamper-detection commitment for detecting alteration of past receipt bytes under known attacks on hashes. Because v selects the whole suite (), a later version can introduce a post-quantum signature suite without changing the field names. 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.

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. Federal Information Processing Standard, FIPS 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. 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. Cyntrisec This document defines the Attested Inference Receipt (AIR), an application-layer COSE_Sign1 envelope carrying CWT claims profiled per the Entity Attestation Token (EAT) framework. An AIR receipt binds model identity, input/output hashes, attestation-linked metadata, and operational telemetry into a single signed artifact suitable for independent third-party verification of a confidential AI inference. An AIR receipt is Attester-signed Evidence, not an appraisal verdict: a RATS Verifier must appraise the referenced platform attestation before the receipt establishes TEE provenance. AIR v1 targets single-inference receipts emitted by workloads running inside hardware-isolated Trusted Execution Environments (TEEs). AIR is attestation-linked: it carries measurements and a hash reference to the platform attestation evidence associated with the inference, but it does not replace platform-specific attestation verification. This version defines AWS Nitro Enclaves and Intel TDX measurement profiles only, and assumes a single platform attestation document per receipt. Pipeline chaining, multi-inference receipts, composite attesters, multi-verifier orchestration, accelerator / GPU confidential-compute attestation integration, and extensibility mechanisms for additional claim or platform profiles are out of scope.

Example Receipt The following informative example is vector valid/001-allowed.json from the conformance set in . A verifier that pins the test public key in MUST accept it. The author regenerated and re-checked this object against that key before publishing this revision; if verification fails, the vector set or this figure is wrong and MUST be corrected before relying on either. Field order in this figure is for readability; canonical signing order is defined in . The signature value is shown on two lines for document formatting only; in the vector file it is a single base64url string with no whitespace.

Pinned test public key for this example and the vector set:

Conformance Vectors Informative conformance vectors (valid receipts, invalid receipts, and the fixed test public key) are published at: https://github.com/Aqta-ai/attestation-spec/tree/main/test-vectors A conformant verifier that pins that test public key MUST accept every receipt in the valid set and MUST reject every receipt in the invalid set. Those vectors are generated from a fixed seed documented in that repository so third parties can reproduce the signatures.

Reference Implementations Open-source reference verifiers implementing this format are published as aqta-verify-receipt on the Python Package Index and on the npm package registry. Those packages are informative aids. Conformance is defined by this document and the vector set in , not by any single implementation.

Changes From draft-chueayen-attestation-receipts-00 Added explicit non-goals and a "what a verified receipt proves" section. Clarified relationship to related Internet-Drafts without requiring them. Documented optional chain fields and spec_version for wire clarity. Clarified that cost_prevented_eur is non-security and SHOULD be 0 for new issuers. Added conformance language, an example receipt, and a pointer to published test vectors. Normative reference to SHA-256 via RFC 6234. Tightened verification steps for issuer identity pinning. Softened attestation_id to UUID string with version-4 SHOULD, matching the published conformance vectors. Clarified policy_applied as UTF-8 strings (matches the non-ASCII valid vector) and tightened verification type checks.