]> 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 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 and 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.

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. Those documents are broader profiles. This document specifies one fixed 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.

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.

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 the included fields, including outcome and request_hash, at the stated timestamp. 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.

Canonical Payload and Signing The canonical payload is produced by: 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 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 the canonicalisation of , including its number rule. 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

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.

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. Federal Information Processing Standard, FIPS 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.

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.