AqtaAqta

Check any record yourself: the public log

  • Seal
  • Transparency
  • Verifiable AI
  • Engineering

In short

Every receipt Seal signs since 27 August 2026, and every agent action record since 4 September, refusals included, is committed to a public append-only log; here is how to check a record is in it, in the browser or with the published verifier.
Pencil sketch: a taped ledger page headed "public log", each line a truncated hash, one line ringed in cyan, and a paper tag pinned to the page reading "size 153". The note reads "anyone can check the log".

A signature answers one question well: has this record changed since it was signed? It cannot answer two others that matter just as much to anyone reviewing an AI system's decisions. Does a record exist that you were never shown? And is the history you are shown today the history you were shown last month?

Since 27 August 2026, Seal has answered those two with a public, append-only log. Every receipt and every agent action record the Seal gateway signs is committed to it, and anyone can check the log without an account and without asking us.


What is in the log

The log is a Merkle tree built to RFC 6962, the construction Certificate Transparency uses for web certificates.[1] It holds two kinds of record in one append order: the receipts Seal signs for model calls and, since 4 September 2026, the records it signs for agent actions.

Refusals are in it too. A refused model call has always produced a signed receipt, and every receipt enters the log whatever its outcome. Since 4 September, so has every agent action the boundary refused.

Each leaf is a hash of one signed record, so the log publishes the size and order of what was signed and nothing about its content: no prompt, no response, no arguments. The head of the tree, meaning its size, root hash and time, is signed with the same published Ed25519 key that signs the records, and the endpoints need no credentials.

Check it in the browser

app.aqta.ai/transparency runs three checks in your browser, against the published key:

  1. The head. It fetches the current signed head and verifies the signature.
  2. Inclusion. Paste a record's id and it fetches an inclusion proof, then rebuilds the path from that record's leaf to the signed root.
  3. Consistency. Pin today's head. Come back later, and it proves the current log extends the head you pinned without rewriting anything beneath it.

To try it on a real refusal, take the action_id from app.aqta.ai/samples/sample-action.json: an agent's attempt to push to production, refused before anything ran. It is the entry on the public refusal ledger at app.aqta.ai/refusals.

Check it without our page

The page is a convenience. The same checks run from a terminal with the published verifier, aqta-verify-receipt, which ships the same two commands on npm and PyPI:

bash
# Pin the issuer key once: the "public_key" field
curl -s https://api.aqta.ai/v1/attestation/public-key

# 1. The head
curl -s https://api.aqta.ai/v1/public/transparency/sth -o sth.json
npx -p aqta-verify-receipt aqta-verify-proof sth.json --key <pinned key>

# 2. Inclusion of one record (a receipt id or an action id)
curl -s https://api.aqta.ai/v1/public/transparency/proof/<record id> -o proof.json
npx -p aqta-verify-receipt aqta-verify-proof proof.json

# 3. The record itself
curl -s https://app.aqta.ai/samples/sample-action.json -o record.json
npx aqta-verify-receipt record.json --profile action-1 --key <pinned key>

One step is yours rather than the tool's: compare the proof's root_hash and tree_size with the head you verified in step 1. The path proves that a leaf reaches that root; the signed head is what makes the root one we committed to. Change a single hash in the proof, and the verifier answers computed root does not match root_hash.

For consistency, fetch https://api.aqta.ai/v1/public/transparency/consistency?old_size=<your pinned size>, run the same proof command on it, and check that old_root is the root you pinned and new_root is the root of today's head.

Held outside our infrastructure

A pin in your browser protects you. A public repository, Aqta-ai/seal-log-witness, does the same work on a schedule. It checks each new head's signature, proves the head extends the last one it recorded, and countersigns it into Sigstore's public log, so a record of when that head existed is held outside Aqta. Running node scripts/check.mjs in a clone re-verifies the whole recorded chain offline.[2]

The log's history is part of the log. On its first day, an ordering defect was found and fixed, and the log was anchored at size 153 at 10:40 UTC on 27 August. Heads pinned before then do not chain to the current log, and app.aqta.ai/transparency says so in a note that stays. A consistency proof from size 153 to today's head verifies with the same command as above.

What this does not prove

The log makes it harder to hide that a signed record existed. It cannot show a decision that was never signed. Leaves are hashes, so the log proves nothing about content. Inclusion shows that a record was in the log by the time of a head, not when it was signed: the refusal above was signed on 22 August and joined the log on 4 September, when action records became leaves. An inclusion proof shows that a leaf sits in the signed tree; tying that leaf to the record in your hand means hashing the record's signed bytes the way the log does, and that entry layout is not yet in the published specification. And Aqta operates the witness: its value comes from where the evidence lives, in GitHub's history and Sigstore's log, and from the fact that anyone can fork it and run it on their own schedule.

Check the public log