Keys and trust

Seal is not where you are asked to trust us

It is the mechanism that lets someone check a record without trusting us. This page states which keys sign, what gets signed, and where the guarantee stops. If any of it is wrong, that is a defect and we would like to hear about it.

Where a record comes from

1. AI or agentproposes an action
2. Sealapplies the operator’s rules, allows or refuses, signs the outcome
3. Signed recordATTESTATION-v1 for a model decision, ACTION-v1 for an agent action
4. Public log and evidence packthe record is committed, and travels
5. Independent verifierrun by whoever is asking, not by us
6. Revieweraccepts, names a gap, or refuses

The signing keys

Ed25519 over canonical JSON. A receipt names the key that signed it, so a record issued before a rotation verifies against the retired key and against nothing else. Retiring a key ends one issuer identity. It does not retire the evidence that identity signed, which is why no key is ever removed from this table.

Served as plain text at /security/issuer-keys.txt, and from the gateway at api.aqta.ai/v1/attestation/public-key. The endpoint is the authority. Do not trust a key pasted anywhere else, including here, without checking it there.

Checking without us

The record formats are open and there are two verifiers, written independently in TypeScript and Python, published as aqta-verify-receipt on npm and PyPI. They must return the same verdict on the same bytes, and a public suite of conformance vectors, valid and invalid, exists so you can test a verifier before you trust its verdict on our records. A checker that cannot reach the failing verdict has proved nothing.

The log is a Merkle tree in the style of RFC 6962. Inclusion proofs and consistency proofs are recomputed on your machine from the leaf and its audit path. Leaves are hashes: no prompt, no response and no decision content is published.

What a signature proves

Authenticity

Which key signed the record, and that the key is one we publish.

Integrity

That not one field has changed since it was signed. Alter a character and the check fails.

Inclusion

That the record is committed to the public log, and was not slipped in behind others.

Consistency

That the log grew from a head you pinned earlier without rewriting what sat behind it.

What it does not prove

Stated here rather than left to be discovered. A product that cannot say where its guarantee stops has not understood it.

Correctness

Whether the decision was the right one. A rule can be satisfied and still be the wrong rule.

Completeness

Whether a decision that never reached Seal took place. It leaves no record, and no signature scheme closes that.

Execution

That the system which received the authorisation then obeyed it. Binding a decision to its execution is a research problem, not a shipped property.

Seal issues signed evidence and audit trails. It is not a certification and we hold no accreditation to certify anything.

Try to break it

There is a standing reward for anyone who forges a receipt, alters one without detection, produces a false inclusion proof, or removes a record without the log showing it. Terms at aqta.ai/bounty. Two outside researchers found real defects in the verifier in its first two days. Both were fixed the same day and each is pinned by a regression vector that runs on every change.