Verification
Every record AGLedger writes is signed by the Server instance and hash-chained to the one before it. Verification is the act of confirming, independently, that those signatures are genuine and that the chain has not been altered. Anyone holding the instance's published verification keys can do it - offline, with no account and no connection to AGLedger. The proof outlives the vendor.
Ed25519 · COSE_Sign1 (RFC 9052) · hash-chained · offline by default
Last updated: 2026-06-10 · API v1.2.0
Who this is for
For the reader who takes no one's word
The agent that wrote a record trusts itself. The operator watching a fleet is checking its own agents. The auditor does neither - an auditor's posture is zero-trust, and a record is only evidence to them if they can confirm it themselves, without trusting the party that produced it. This page is the auditor's page. Verification is the mechanism that turns a signed record into evidence a skeptic can rely on.
What gets verified is a single primitive: a signed record spanning the whole lifecycle of a piece of automated work. The agent reports with its key; the notary - one Server instance - signs what was reported and names the accountable principal inside the signed payload. Verification confirms that what the notary signed is intact and authentic.
What it is
Cryptographic verification, not a verdict
Verification here means one specific thing: checking the cryptography. Are the Ed25519 signatures valid against the instance's published verification keys? Does each entry hash-link to the one before it? Has the visible payload drifted from what was signed? These are mathematical questions with mathematical answers, and they can be answered by anyone, anywhere, without trusting AGLedger.
It is a separate question from whether the delivered work was accepted. That accept-or-reject verdict at a delegation boundary is the Gate. The Gate produces a signed verdict; verification confirms that verdict - and every other record in the chain - is authentic and untampered.
What it checks
Three things, each independently checkable
Signatures are genuine
Each entry is a tagged COSE_Sign1 envelope (RFC 9052, tag 18) carrying an Ed25519 signature over an in-toto v1 Statement payload, deterministically CBOR-encoded per RFC 8949 §4.2.1. The signature verifies against the instance vault key's public half, published at /.well-known/agledger-vault-keys.json. A signature that does not verify means the entry was not written by the key it claims. The accountable principal is named inside the signed payload, not by a separate per-principal key.
The chain is unbroken
Each entry records the SHA-256 hash of the previous entry's bytes. Recomputing those hashes end to end confirms that no entry was inserted, removed, or reordered. A break anywhere is detectable at the exact position it occurs.
The payload has not drifted
The signed envelope is the source of truth, not the human-readable copy stored alongside it. If a privileged database operator edits the visible payload jsonb, verification catches the mismatch against the signed bytes - surfaced as chainIntegrityReason: 'payload_drift'. The database enforces the rest: UPDATE and DELETE are revoked on the vault tables, and partition-level TRUNCATE is blocked by trigger.
What a pass does not prove. Verification confirms that what was signed is intact and authentic. It does not confirm that the claim inside a record was true, or that the work behind it was good. The chain proves what was said, signed, and recorded - not whether the statement was correct. That distinction is the same one the Gate draws: the principal judges the work; the chain holds the proof.
How to verify
Export the chain, then verify it anywhere
Export a record's chain as a self-contained, signed bundle, then verify it on a machine that never talks to AGLedger. Air-gapped is the default path, not an afterthought: the bundle carries everything a verifier needs, and the instance's published verification keys are the only external input.
GET /v1/records/{id}/audit-export → the signed chain bundle
GET /v1/verification-keys → the instance's public verification keys
GET /.well-known/agledger-vault-keys.json → the same keys, served for offline / discovery use
Verification runs in several places, all against the same exported bytes: a standalone offline verifier for air-gapped audits, the CLI for operators, and the TypeScript and Python SDKs and the MCP server for programmatic and agent-driven checks. Each reports the same result - pass, or the specific reason and the chain position where it failed. Step-by-step commands are in the offline verification guide.
No AGLedger code required
Verifiable with standard crypto libraries
The strongest form of independent verification is the one that uses none of our software. Because every entry is a standard COSE_Sign1 envelope carrying an Ed25519 signature over deterministically CBOR-encoded bytes, an auditor can confirm a chain with off-the-shelf cryptography libraries alone - no AGLedger tooling on the path. Our verifier is a convenience, not a dependency.
Signed Statements. The native form: each entry is a tagged COSE_Sign1 envelope over an in-toto v1 Statement. This is what the offline verifier and SDKs check directly, and what a stock COSE library can check on its own.
DSSE export. The chain exports as DSSE v1.0.2 envelopes, and the bundle form wraps DSSE in the Sigstore Bundle Format - so the same evidence verifies with cosign and interoperates with Rekor, no AGLedger tooling required.
SCITT receipts. When the Transparency Service is in play, an audit export can include SCITT receipts - RFC 9162 Merkle inclusion proofs in COSE - opt-in via ?receipts=true. A receipt proves an entry was admitted to the transparency log at a known position, independent of the chain itself.
Why it matters
The proof does not depend on us being around
A record is only evidence if someone other than its author can confirm it. Because verification needs nothing but the bytes and the instance's published keys, an auditor, a counterparty, a regulator, or a court can check an AGLedger chain years later - with the Server long since shut down, the license lapsed, or the vendor gone. There is no service to call, no key escrow to trust, no account to hold.
This is also what makes federation between organizations work without institutional trust: each peer verifies the other's signed bytes against that instance's published key, per record. Trust is per-signature, not per-relationship.
Related capabilities
The accept-or-reject verdict at a delegation boundary. Verification confirms that verdict is authentic; the Gate is where it is rendered.
COSE_Sign1 envelopes, deterministic CBOR, the instance vault key model, and append-only enforcement that verification rests on.
Per-signature trust across organizational boundaries. Each peer verifies inbound bytes against a published key.
Why an unsigned record is not evidence, and how detached signatures prevent post-hoc revision.