Ask a vendor how you can verify their claims, and the common answer is "call our API." You send a request, their service returns a green checkmark, and you file it. But look at what that arrangement asserts: the thing being verified and the thing doing the verifying are the same party. If the vendor is wrong, compromised, or gone, your evidence goes with them. That is a dependency wearing assurance's clothes.
Athena is built so that an auditor, a regulator, or an insurer can check the record themselves, offline, with no network call and no trust in us. The verification is a computation anyone can run. This post walks through what that means and where it stops.
Three failure modes are baked into vendor-hosted verification, and none of them are exotic.
An audit trail whose only reader is the auditee has it backwards.
Athena seals each unit of evidence into a record. Verifying that record is a fixed sequence of steps, and every one of them runs on the verifier's own machine.
First, read the sealed record. It is a self-contained file: the evidence payload plus the cryptographic material needed to check it. No lookup required.
Second, recompute the canonical digest. JSON can serialize the same data many ways, so a raw hash is fragile. Athena uses RFC-8785, JSON Canonicalization Scheme, to put the payload into one deterministic byte-for-byte form, then hashes that. The verifier does this computation itself against the payload in front of it.
Third, check the signature. The record is signed with ML-DSA-65, the post-quantum signature scheme standardized in FIPS-204. The verifier checks the signature over the recomputed digest using the published public key. If the signature is valid, the record was produced by the holder of the signing key and has not changed since.
Change a single byte of the payload and the recomputed digest no longer matches what was signed. The check returns REJECTED. There is no partial credit and no way to nudge it green from the payload side.
$ aegis-attest verify evidence.mtac --offline reading sealed record ......... ok recomputing canonical digest (RFC-8785) ... ok checking signature (ML-DSA-65, FIPS-204) .. ok VERIFIED OK $ aegis-attest verify tampered.mtac --offline reading sealed record ......... ok recomputing canonical digest (RFC-8785) ... ok checking signature (ML-DSA-65, FIPS-204) .. FAIL REJECTED: digest does not match signature
No network, no account, no call home. The verdict comes from the maths on the file, and the maths has never once been acquired.
The shift is what you are trusting. With a vendor API you trust our word, delivered through our infrastructure, on our schedule. With offline verification you trust the math: a published canonicalization standard, a published signature standard, and an open verifier you can read, reimplement, or run against your own copy of the record.
The verifier does not ask us anything. It reads a file and a public key and computes an answer. We could disappear tomorrow, which is not the plan, and every record already sealed would stay checkable. This is a single-record proof: each record stands on its own cryptography, independent of any live service we run.
Two things. The sealed record, which the party under review can hand over directly, and the open verifier plus the public key, which are not secret. From those, an auditor supporting an ISO 27001 or SOC 2 engagement, a risk function mapping evidence to DORA or NIS2 obligations, or an insurer pricing a policy can confirm integrity and authorship without asking us to participate. OSCAL-shaped control evidence fits the same flow.
Offline verification establishes that the sealed record is intact and was signed by the stated key. That is tamper-evident: any change to the payload is detectable, and a valid signature ties the record to its author. It is candidate evidence for a control, produced so an independent party can check it.
It does not prove the underlying decision was correct or wise. A faithfully sealed record of a bad call is still a bad call, faithfully recorded. We do not issue legal opinions and we do not grant certification. Athena verifies the integrity and authorship of the record; the judgment about what the record means stays with the auditor, the regulator, and you.
One question is worth asking any vendor selling assurance: can I verify this when you are not in the room? If the honest answer needs their servers, their uptime, and their good faith, it is a dependency. If it needs a file, a public key, and a few lines of open math, it is verification.
