Our thesis
The core claim
AI made decisions cheap. Evidence is becoming expensive.
ATTESTATION-v1 is an open protocol; Seal is the reference implementation. Three pillars follow.
The claim boundary, in its technical form: a Seal determination is reproducible wherever its inputs, rules and outputs are available to the verifier. Where a judgement depends on model reasoning the verifier cannot access, Seal records the determination and its evidence boundary, never a claim of correctness. A model-authored verdict could not be recomputed, so signing one would attest to a guess. A determination made elsewhere can still be carried: its signed output is hashed into request_hash and the issuer of that judgement is recorded, which is a different act from producing one.
A bank or hospital does not run on a single AI cloud. Receipts produced by Seal verify identically whether the model behind the agent was OpenAI, Anthropic, Google, Bedrock, or an on-prem deployment. The audit layer cannot live inside any one vendor's surface.
A regulator, customer, or auditor verifies any receipt against the Ed25519 key that was current when it was signed. The permanent key record at app.aqta.ai/security/issuer-keys.txt lists every issuer key with its validity window; keys rotate, receipts stay valid. The verifier runs offline. No call back to Aqta, no log fetched from any cloud.
ATTESTATION-v1 is dual-licensed: code Apache 2.0, spec text CC BY 4.0. Reference verifiers ship at parity on PyPI and npm. Every third-party verifier strengthens the primitive instead of deepening dependency on us.
What a verified receipt proves, and against whom. A valid signature proves the receipt was produced by the holder of the issuer key and has not been altered since, and the key record tells you which key was the issuer's when. It does not prove the computation behind the decision ran as described: today the issuer is the root of trust, and Q1 below is the research programme to shrink that assumption. Stating it is what makes the rest of the page checkable.
Verify the primitive yourself
Figures as of August 2026; vector count as of September 2026. The conformance suite grows whenever a new defect class earns a vector, which is why the count moves: it was 50 before an encoding defect found by our own differential fuzz added two, and 52 before an ordering divergence reported from outside added two more.
Verify a receipt
Four commands, no account. Once the key and the pack are on disk, nothing calls back to us:
$ pip install aqta-verify-receipt $ curl -sL https://app.aqta.ai/security/issuer-keys.txt -o keys.txt $ curl -sL https://app.aqta.ai/samples/sample-receipt.json -o receipt.json $ python <<'PY' import json from aqta_verify_receipt import verify_receipt # The pack's receipt is from 24 Jul 2026: pin the key that was current then. key = next(l.split()[1] for l in open("keys.txt") if "2026-04-21" in l) print(verify_receipt(json.load(open("receipt.json")), trusted_public_key=key)) PY VerifyResult(valid=True, reason=None, key_source='pinned', envelope='ATTESTATION-v1')
This is a receipt the production gateway emitted and signed on 24 July 2026. The key it is pinned against is fetched separately from the issuer key record at app.aqta.ai/security/issuer-keys.txt, not read out of the zip. Keys rotate; receipts do not: the record lists every signing key with its validity window, permanently, so a receipt always verifies against the key that was current when it was signed. The cryptographic work is 751 µs at the median (signing 238 µs, roughly 4,200 receipts per second per core, measured over 10,000 iterations); the CLI takes about a second because a Python interpreter starts. The benchmark script is published, so the numbers are yours to reproduce or refute. Change one character in receipt.json and the signature stops matching. To sign a receipt yourself in the browser, use aqta.ai/verify, which runs on a separate demo key rather than the production one.

ATTESTATION-v1.md · Apache 2.0 / CC BY 4.0 · Aqta-ai/attestation-spectest-vectorsapi.aqta.ai · key record issuer-keys.txtapp.aqta.ai/demo · sign, chain-check, verify offlineSelective disclosure preview. BN254 Schnorr verification is live; a Groth16 verifier runs over a fixed demo circuit. Early research, not a shipped feature.
Prove a property of a receipt without revealing its contents. The button below verifies a Groth16 zero-knowledge proof (BN254, depth-10 Merkle membership) over a fixed demo circuit. Per-request proving for production receipts is in preview.
Verifier live over a demo circuit. Per-request proving is in preview. Roadmap on the research page, section 8.
Where this sits
Neighbouring work
This is a crowded, fast-moving neighbourhood, and the honest map matters more than a category claim. IETF SCITT (RFC 9943, June 2026) defines receipts as proof of registration on a transparency log; ATTESTATION-v1 is a payload-level format for the decision itself, and the repository documents the relationship. C2PA signs provenance for media; sigstore signs artefacts, and since model-signing v1.0, ML model files. Hardware-attested inference has shipped commercially: TEE-based serving now issues per-response attestations, and the hyperscaler trajectory points the same way. Those systems attest the serving environment, and they relocate trust to the hardware vendor's attestation chain rather than removing it. Zero-knowledge proofs of full LLM inference exist in production at small-model scale, and the Hollow-LLM result (arXiv:2607.28884) shows why the binding problem stays open even there: proof of correct inference is not proof of which model did the work. Replication-based verification (TOPLOC, DiFR) binds computation but needs a re-executing verifier. At the IETF, other individual drafts describe signed receipts for machine decisions from different angles.
Our position on this map is deliberately narrow: an open payload format for the decision record, signed in-path before the action, with two separately written offline verifiers that agree on every published conformance vector, checked on every change rather than at release, running in production since April 2026. Q1 below is where this map's hardest open problem lives, and it is ours too.
Corrections
Claims we retired
In September 2026 we ran a prior-art sweep against our own physical-authority work, looking for the systems that would contradict it. They exist, several are decades old, and the honest record of what we stopped claiming is more useful to a reader than the claim would have been. Each line below is a sentence we removed, and the work that removed it.
Cryptographic gating of an actuator is new
Retired. ESA PSS-04-151 (Issue 1, September 1993) specifies per-command authentication bound to the individual telecommand segment, verified inside the command decoder by a hardware block named the Final Authorisation Function, upstream of the onboard computer, with a strictly single-use counter that refuses replay. It reached flight silicon in the MA28140 in 2000.Independent downstream enforcement does not exist
Retired. Functional safety builds exactly that: a safety-related control system at a required Performance Level, architecturally separable, able to force a safe state the ordinary controller cannot override. The hardware to refuse already exists and is already certified. What it evaluates is speed, position, presence and torque, never who authorised the action.Industrial control never had per-action authorisation
Retired, and the correction cuts both ways. DNP3 Secure Authentication v5 required outstations to treat every output operation as critical and to refuse it on authentication failure, and it was formally verified sound at ESORICS 2017. IEC 62351-5:2023 then removed the challenge-reply procedure and user management in favour of per-association security. The industry specified it, proved it, and standardised back to channel authentication.No standard requires approval for a consequential action
Retired. IEC 62443-4-2:2019 CR 2.1 RE(4) requires components to support dual approval where an action can result in serious impact on the industrial process. It is role-based rather than bound to a described action, carries no artefact, and binds only at security level 4, but the requirement is normative and has been published since 2019.Machinery standards do not address unauthorised commands
Retired. IEC 62745:2017, now a normative reference of ISO 10218-1:2025, carries clauses titled Prevention of unauthorised operation and Prevention of unintended commands. Read in full, the first names a key-operated switch or access code on the remote station and the second is addressing and error detection, with a Hamming distance requirement against radio noise. It is command integrity, and it is prior art for that.Pre-execution authorisation for AI actions is unexplored
Retired. Recent work sets out pre-effect authorisation and authorization-bound execution for AI agent tool calls, with signed authorisation, replay blocking and a receiver-signed effect receipt, reproduced by its author on edge hardware. It is a single-author preprint that disclaims independent reproduction and physical-actuation safety, and it is dated before this note.What survives is narrower, and we state it as a research position rather than a novelty claim. Four properties are absent from every deployed system we examined, and none of them is a new mechanism: an authorisation bound to the semantic content of an action generated by an open-ended system rather than chosen from a fixed command table; a signature from a party that is not the one commanding; an asymmetric signature, so a third party can check it later without holding the issuer's secret; and a refusal that is signed as a first-class record rather than expressed as an action that simply did not happen. Remove any one and the prior art above reappears at scale.
The question we are actually working on is therefore not whether a machine can be made to refuse. It can, and it has been able to for decades. It is what evidence survives when an action generated by an autonomous system is challenged by someone who was not operating it.
Proof
The dated public artefact
- AqtaBio commits W19.jsonDR Congo Ebola, rank 4public commit timestamp
- WHO declares PHEICBundibugyo EbolaDR Congo + Uganda
Aqta-ai/aqtabio-research commits commitments/2026-W19.json: DR Congo Ebola at rank 4 of the Congo Basin tiles.2026-W19.json commit history against the WHO declaration date.The same signing pipeline that produces Seal receipts demonstrates the mechanism on a dated prediction. The primitive does not care whether the decision is a policy call or a forecast.
The ladder
Five questions, in order of difficulty
Evidence about an AI decision is not one property but five, and they stack: each question is only worth asking once the one beneath it holds. Naming where we actually stand on the ladder is more useful than a claim to have solved evidence, so here it is.
The order is difficulty, not a schedule. We are not trying to solve trust in AI in one leap, and we say out loud which questions are still open rather than which we intend to answer next.
Open questions
Open research questions
Four of the seven rungs of evidence independence are held today and three are open: omission-detectable, counterparty-attested and physically enforced. The ladder, with what each rung would take, is at aqta.ai/independence.
If any of these resonate, email hello@aqta.ai with subject prefix [research].
Q1ProvenanceBinding the record to the computation.
A receipt records what the issuer asserted. Can it establish something meaningful about the computation that actually ran, without paying enclave overhead on every inference?
Q2SufficiencyMinimum sufficient evidence.
What is the smallest set of independently verifiable objects a third party needs to reach a defensible conclusion about a consequential AI decision? Receipt, reviewer credential and countersigned verdict is our current candidate answer.
Q3ProtocolCross-provider aggregation.
When agents run on three model clouds, how are receipts under different regimes aggregated and queried as one evidence corpus without breaking offline verifiability?
Q4ProtocolPost-quantum migration.
The minimum-disruption path from a classical signature to a post-quantum one such that classical-regime receipts remain verifiable indefinitely. The signature is already a tagged field, not the format.
Q5PrivacyZK receipts for sensitive prompts.
Extend BN254 Schnorr + Groth16 so a receipt proves policy was evaluated over the committed prompt, without revealing prompt or output, while staying offline-verifiable. Proving which model ran is Q1's territory, and Q5 inherits that limit.
Q6ApplicationRegulator-readable export.
The right export format for a multi-month receipt chain so a central-bank examiner can ingest, query and verify with off-the-shelf tools.
Q7ApplicationAudit-cost economics.
The real cost of producing, storing and querying signed receipts at bank scale, and where signed receipts pay for themselves against one contested decision.
Q8PrivacyReceipts and differential privacy.
When receipts aggregate across organisations under a DP budget, how do per-receipt guarantees and privacy guarantees compose without one eroding the other?
Q10IntegrityDetecting what was never written down.
A dishonest issuer does not need to forge anything: it holds the key, so anything it signs verifies. We enumerate the six classes where that happens in the issuer-as-adversary model, and five of them have mechanisms in the gateway. The sixth, omission, is open and we do not claim it: a decision that was never recorded leaves no artefact to check, and the party that would have recorded it is the party under review. What would an outside observer have to hold, or have seen, to put a bound on how much history is missing?
Q9ApplicationEvidence for a resource constraint.
A policy can refuse a call whose modelled energy cost exceeds a declared ceiling, and Seal signs that refusal: shipped 18 August 2026 as the carbon_budget rule, documented at doc.aqta.ai. The receipt establishes that a declared constraint governed the decision. It does not establish a measured reduction, because the estimate is derived from a static model-energy profile and a regional intensity figure, neither of which is metered. The open question is what an avoided-compute figure would have to look like to survive recomputation by someone who did not produce it, which is a methodology problem rather than a signing one.
Support
Infrastructure
Auth0 is the identity vendor for enterprise SSO (SAML/OIDC). Selected for WeBuild Cohort 2 under the Shared Island Enterprise Scheme (programme selection, not institutional backing).